IP Fragments - Worth doing, testing strategies?
bqt at softjar.se
Wed Oct 13 09:50:16 CDT 2010
On 09/30/10 06:42, "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
> 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
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.
More information about the cctalk