This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: Network TCP Handler: stale socket disposal
- From: Gary Thomas <gary at mlbassoc dot com>
- To: John Mills <john dot m dot mills at alum dot mit dot edu>
- Cc: eCos RTOS Patches <ecos-patches at ecos dot sourceware dot org>
- Date: Wed, 29 Aug 2007 14:01:58 -0600
- Subject: Re: Network TCP Handler: stale socket disposal
- References: <Pine.LNX.4.44.0708291436550.16221-100000@otter.localdomain>
John Mills wrote:
> Gary -
>
> Thanks for the reply. First, in the future I'll attach patches rather than
> cutting them in.
>
> I can force the error with the ISS Internet Scanner if I set up a profile
> including only the two tests: 'NtpdRemoteBo' and 'PdgSoftChangepwBo'.
> Other combinations will work, and a broad-spectrum vulnerability scan will
> generally lock-up our socket supply.
>
> You can download the scanner and its numerous[!] updates from:
> [http://www.iss.net/products/Internet_Scanner/product_main_page.html]
>
> Neither 'Nessus' nor 'nmap' triggered the problem in my tests.
>
> I monitored the situation by adding an opened/closed sockets counter to
> 'uipc_socket.c'. I incremented the counter in 'soalloc()' and decremented
> it in 'sodealloc()'. A 'diag_printf' was issued on each allocation and
> deallocation. Sorry, I don't have a patch for that instrumentation but
> could probably make one up.
>
> Sorry not to have better support.
This is useful; what sort of eCos application were you running?
> On Wed, 29 Aug 2007, Gary Thomas wrote:
>
>> John Mills wrote:
>>> Hello -
>>>
>>> This is my first post to this group; please correct me on netiquette and
>>> appropriate usage as necessary. (For starters, should I have attached the
>>> patch instead of cutting it into my text?)
>>>
>>> I have been dealing with a situation in which certain TCP transactions
>>> depleted the stock of network sockets allowed in our eCos configuration,
>>> eventually disabling the product from opening either incoming or outgoing
>>> network sockets. I believe the problem was due to the function 'sofree()'
>>> in 'sys/kern/uipc_socket.c' preserving any socket flagged as SS_COMP,
>>> whether or not it had also been flagged for reset. Adding a test of
>>> so->so_error for the flags set by tcp_input() has resolved the issue.
>>> Please examine and test the following patch and let me know if you see any
>>> potentially troublesome side effects. Please apply the patch to eCos
>>> sources if it seems to be appropriate.
>> Normally, patches are better sent as attachments. This avoids
>> email clients causing inappropriate line breaks.
>>
>> As for this particular change, do you have a test case or
>> some way to force the error so we can verify that it has
>> the desired effect? Also, it may be the case that this
>> issue has been solved in the FreeBSD sources (I imported
>> the "current" code into eCos more than 5 years ago!). Have
>> you checked into that at all?
>>
>> Thanks
>>
>>
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------