Re: Network TCP Handler: stale socket disposal

[John Mills <johnmills at speakeasy dot net>]

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.

John

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
> 
> 

-- 
 - John Mills
   john.m.mills@alum.mit.edu