Re: Network TCP Handler: stale socket disposal

[Gary Thomas <gary at mlbassoc dot com>]

John Mills wrote:
> 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.

It took me about 4 months to do it the last time (100% effort)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------