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: John Mills <johnmills at speakeasy dot net>
- To: eCos RTOS Patches <ecos-patches at ecos dot sourceware dot org>
- Cc: Gary Thomas <gary at mlbassoc dot com>, Andrew Lunn <andrew at lunn dot ch>
- Date: Wed, 29 Aug 2007 15:42:01 -0500 (EST)
- Subject: Re: Network TCP Handler: stale socket disposal
- Reply-to: John Mills <john dot m dot mills at alum dot mit dot edu>
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