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