13 Oct
2010
13 Oct
'10
7:50 a.m.
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