public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: John Mills <johnmills@speakeasy.net>
To: eCos Users <ecos-discuss@ecos.sourceware.org>
Cc: Alok Singh <alok.singh@broadcom.com>
Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
Date: Fri, 28 Sep 2007 13:31:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0709280813570.19643-100000@otter.localdomain> (raw)
In-Reply-To: <E06E3B7BBC07864CADE892DAF1EB0FBD01254EE4@NT-SJCA-0752.brcm.ad.broadcom.com>

Alok -

Thanks for your feedback. That makes the success rate 50:50 (2 of 4 
respondents) for the patch.

The web server in our product is a somewhat secondary administrative 
function and we serve simple content that we control 100%. That allows me 
to summarily close many browser inquiries. I have added and fixed the POST 
code so it handles our binary firmware images. Either of these may have 
closed some vulnerabilities that may be affecting you - I don't know.

Operationally our problem was triggered by vulnerability scanners used by
our customers' SysAdmins. These locked up our product in the course of
their overall test scenarios. In principle that meant we were also
vlunerable to the corresponding hacker exploits. That's what I meant in an
earlier post about a specific, observed functional problem.

The lock-up is broader than just web service. When the socket-descriptor
pool ('zone') is depleted, no new net sockets can be allocated. This
affected other, primary functions in our product, making it a critical 
issue.

I traced the problem by putting 'diag_printf' lines at points where
sockets were created and deallocated, working down to find "what didn't
happen" when a socket was lost. Sounds like you have the same road ahead 
of you.

Thanks again for your reaponse.

 - John Mills

On Fri, 28 Sep 2007, Alok Singh wrote:

> Hi John/everybody,
> The patch didn't work for me.  I still had all the sockets exhausted, and so the web server hangs, and doesn't accept any new connection.  The number of sockets I'm creating while configuring ECOS is 32.  Please see the dump of " cyg_kmem_print_stats()" below when the problem comes.
> 
> Test case: I've a script that opens and closes connection to web server every second. It takes around 2 hours to exhaust the SOCKETS zone of sockets. The TCP zone of sockets also comes down. Even if I stop the script, the sockets never recover. I'm currently debugging it(trying to understand  TCP by reading Comer and stevens).
> 
> Any ideas are welcome.
> 
> ***************
> cyg_kmem_print_stats() -
> Network stack mbuf stats:
>    mbufs 32, clusters 6, free clusters 6
>    Failed to get 0 times
>    Waited to get 0 times
>    Drained queues to get 0 times
> VM zone 'ripcb':
>   Total: 32, Free: 32, Allocs: 0, Frees: 0, Fails: 0
> VM zone 'tcpcb':
>   Total: 32, Free: 1, Allocs: 3989, Frees: 3958, Fails: 0
> VM zone 'udpcb':
>   Total: 32, Free: 31, Allocs: 14, Frees: 13, Fails: 0
> VM zone 'socket':
>   Total: 32, Free: 0, Allocs: 10319, Frees: 3971, Fails: 6316
> Misc mpool: total  131056, free   79008, max free block 77972
> Mbufs pool: total  130944, free  128768, blocksize  128
> Clust pool: total  262144, free  247808, blocksize 2048
> *********************************************************** 
> 
> -Alok


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2007-09-28 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 12:20 Alok Singh
     [not found] ` <6F6F9AF887E54B47961CA0F5D1C228D102129720@shake.airdefense.net>
2007-09-25 13:41   ` Alok Singh
2007-09-25 14:56     ` John Mills
2007-09-28 12:06       ` Alok Singh
2007-09-28 13:31         ` John Mills [this message]
2007-10-02  9:15           ` Lars Povlsen
2015-05-11 16:39 Weili Yao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0709280813570.19643-100000@otter.localdomain \
    --to=johnmills@speakeasy.net \
    --cc=alok.singh@broadcom.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=john.m.mills@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).