Sean Conner wrote:
While I'm familiar wih IP, I haven't tried
implementing it, but, what if
you were to set an MTU size of around 50 bytes? The IP header (sans
options) is 20 bytes, and the TCP header is another 20. I would think
setting the MTU to just above 40 might cause some fragmentation (I thought
of suggesting an MTU of just above 20, but then you're testing for IP
fragmentation, and not TCP fragmentation.
I tend to do stupid stuff like that, but then again, I *was* hired to
write testing code at my current job ...
-spc (In thoery, IP should work with an MTU of 30 bytes, right?)
The IP header is 20 bytes without any IP header options, and the TCP
header is another 20 bytes without any TCP header options.
My implementation has room for 10 fragments per packet (configurable
with a #define), which is great for a 'normal' MTU size. If I tested
with a ridiculously small MTU it would wind up throwing a lot of things
away, but many implementations do the same thing.
My fragment problem is mostly on the source side - the source machines
are too clever about trying to probe and eliminate fragments.
Linux has also been 'interesting' as a gateway. Some kernel versions
allow TCP fragments through even though they have bad checksums. I
throw away any packet with a bad checksum. Mixing NAT (Network Address
Translation) and fragments was problematic in my setup too - I think
that Linux was completely screwing up the payload checksums for TCP.
Mike