Network TCP Handler: stale socket disposal

[John Mills]

On Wed, 29 Aug 2007, Gary Thomas wrote:

> John Mills wrote:

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

> This is useful; what sort of eCos application were you running?

Our product is a network monitor primarily controlled by a remote server
using our custom data protocol. Some management functions can also be done 
through a web server embedded in our product. The target hardware is quite 
limited in RAM and FLASH; naturally we're pushing both limits. Processor 
varies by model.

The current FreeBSD code looks very different than eCos port, and I 
suspect a piecemeal porting of individual files would be a lot of work, 
and probably less compact than bringing in a current version of the stack.

Do you have any order-of-magnitude guess on the work for a competent crew 
to port current FreeBSD code to the eCos stack? (Boy, _there's_ an 
open-ended question!) based on a sample of one file, it looks like several 
months' labor to me.

John Mills
AirDefense, Inc
Alpharetta, GA