On 10/01/10 00:22, "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
wrote:
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.
The minimum allowed MTU is actually 68. (I wrote 65 erronously in a
previous mail.) See RFC 791, page 24.
In addition to the 68 bytes for a single fragment, an IP stack must be
able to handle 576 byte packets, but there is no requirement that this
isn't sent in fragments. The receiver must, however, always be able to
handle atleast 576 byte packets.
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.
You should allocate that stuff dynamically.
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.
What are you talking about? IP fragments for TCP don't have checksums of
the TCP payload. There is only a checksum for the IP header.
Only the final destination reassembles the packet, and can do a checksum
of the TCP packet.
Johnny