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 [EMAIL PROTECTED]
