[NNagain] upgrading old routers to modern, secure FOSS

[rjmcmahon]

I get the nostalgia for old tools and old routers but the industry is 
providing better tools for testing TCP and much better hw & network 
stacks. One such tool is iperf 2, and it's actively maintained and 
released as open source. https://sourceforge.net/projects/iperf2/

TCP is not static either. There is lot of development including new 
socket options, CCAs, etc that need testing. Also, single flows are no 
longer enough. Each end device likely has dozens, if not more, TCP state 
machines active at any one moment in time and are multicore so testing 
really needs to be multithreaded and multiflow.

The analytics side needs to support statistical & multivariate analysis. 
Libraries like python scikit learn need to be considered in the design. 
That's why the flows code based upon python3 is also released as open 
source with examples on how to do things like kolmogorov-smirnov CDF 
distances.

I see a shortage in network expertise, including staying current with 
current transistor designs and silicon, vs a tools issue. Networking 
keeps progressing and staying current requires continuous efforts.

Home networks today are embarrassing to me. Our industry is woefully 
behind here.

Not trying to be rude, just calling it as I see it.

Bob
> On 10/23/23 11:53 AM, Jack Haverty via Nnagain wrote:
>> On 10/23/23 10:58, Dave Taht via Nnagain wrote:
>>> I wish that the city-dwellers of BEAD so in love with fiber would 
>>> insert 70ms of rural delay into all their testing.
>> FYI, in case someone wants to pursue such real-world testing....
>> 
>> When we were testing TCP/IP software about 40 years ago there was a 
>> similar problem of how to do tests in a lab which realistically 
>> simulated real-world conditions.   We created a software tool called 
>> "Flakeway" which enable traffic flows to be delayed, duplicated, 
>> re-ordered, deleted or mangled.   That enabled realistic testing even 
>> when the machines being tested were all in a lab connected to the same 
>> LAN.
> 
> When we were doing TCP "bakeoffs" at the FTP Software facility we
> dreamed of having such a device.
> 
> When Steve Casner and I were doing entertainment grade audio/video
> back in the late 1990s we discovered that we were in great need of
> something like Postel's Flakeway.  (Receiving RTP code and codecs,
> especially when dealing with multiple lip-synched streams, can be very
> sensitive to inter-packet timing and packet reception order - it was
> very hard for us to reliably test all the code paths.)
> 
> So a few years later  I implemented Jon's Flakeway idea, but at layer
> 2 rather than 3.  (It was far from a weekend hack.)  I've now gone
> through multiple generations of the idea and sell it as a (reasonably
> successful) testing product.  I'll attach a screen shot so that one
> can get an idea of what it does. (Hopefully the mail handler for this
> list doesn't get upset with the attachment.)
> 
> (We've also got versions that do some protocol tracking and rewrite
> packets in "interesting" ways on the fly.  We've had some
> less-than-fun [for the customer] experiences such as when a phone
> vendor wanted us to exercise their IPv6 code but only had their
> firmware based IPv4 ready [and 200, 000+ units already in customer
> hands].  Within a couple of minutes we had found issues with their TCP
> stack - it seems that far too much IP and TCP code was written in C
> and used the default signed integer data type rather than unsigned and
> thus has troubles when the high order bit in a packet field changes. 
> Perhaps the must vulnerable protocol on the net is SIP - I sometimes
> believe that it should have as its icon a target with an over-large
> bullseye with a bunch of arrows in that bullseye.)
> 
>         --karl--
> 
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain