New subject: Phoenix Amiga 1000 - interesting/boring/rare/common...?

13 Oct 2010

On 09/30/10 06:42, "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>

wrote:
...
  I have been working on my TCP/IP stack for DOS, adding
IP fragmentation
 support.  There are not too many more features that I want to add to
 make it 'complete' before I open source the code and IP fragment support
 was a big one.

 I am having a terrible time testing it though.  It seems that IP
 fragments out in the wild are pretty rare.  I tried connecting to a slew
 of remote FTP sites hoping to find one that was behind a really bad
 network, and thus would have fragments coming from it.  No joy.

 It seems that there are a lot of tricks out there to prevent fragments
 from being created, especially when using TCP.  The only way I can test
 the code is to send myself oversized UDP packets.  If it works for UDP
 then it should work for TCP too, but I'd really like to test the TCP
 path explicitly.  Combine the tricks with modern broadband and getting
 fragments is really difficult.

Why? Are you handling UDP and TCP differently at the IP level???
I've written my own TCP/IP (for a PDP-11), and the fragment reassembly 
code I mostly tested using ICMP, since that was so easy. The IP code is 
totally protocol-agnostic, so if it works for one protocol, it will work 
for any. If you haven't done your code this way, then maybe you should 
rethink that part.

TCP is, as you noted, explicitly trying to avoid  fragmentation. So it's 
not an easy protocol to use to test this.

...
  Even on the home network I am having a hard time
getting fragments.  I
 put a Linux box between the DOS PC and a Windows machine, and set one of
 the Ethernet MTUs to 576.  Well, that didn't force fragments because the
 Windows box is too clever.  I could start turning everything off in the
 registry, but I really don't want to get that involved.

 Off the top of my head I think I am going to have to get another Linux
 box and dumb that down, if it is possible.  Dumbing Linux down to turn
 off the features and then restoring it to a good state is probably
 safer/easier than doing it with Windows.
     I doubt that would help you either. If you read through the TCP specs, 
you'll find how the path MTU, and thus MSS is determined. And I doubt 
you can turn those knobs off.

...
  Does anybody have a good technique for setting up a
simple network that
 will result in IP fragments of TCP?

     Nope. And I don't really think that it should be neccesary.

...
  On a related note, is this even worth it?  I don't
know of anything that
 needs to send fragments except for NFS over UDP.  There might be other
 applications that send big packets over UDP but those would be the only
 class of applications that absolutely require fragment support.  With
 TCP it is nice, but a user should be able to get around any problem by
 setting the local MTU to 576.

     Yes, I think it is worth it.
Not only can packets be fragmented along the way, but you are not even 
guaranteed that 576 byte packets will not get fragmented. IP requires 
that you should always be able to pass through 576 byte packets, but it 
don't actually say anything about fragmentation in this case.
If you dig really deep, you'll find that the guaranteed minimum packet 
size that IP needs to handle without fragmentation is 65 bytes. All 
above that could get fragmented, so fragment reassembly is a good thing 
to have.
I think, for instance, SLIP interfaces usually run with an MTU of 296, 
or something like that.

But, with all that said, several IP implementations do take a short cut 
with regards to fragmentation and either totally skip it, or just 
implement reassembly, and not fragmentation. You can get away with that 
most of the time, even though it is breaking the requirements.

     Johnny

IP Fragments - Worth doing, testing strategies?