IP Fragments - Worth doing, testing strategies?

Michael B. Brutman wrote: Interpose a router with two interfaces, one configured with a smaller MTU. I expect that's what you're using the Linux box to do. It's either that or fiddle with the sending IP stack so that IP knows the network has a small MTU but TCP doesn't find out. If the sending host is setting the DF bit expecting to get ICMP messages back for path MTU discovery, hmm, that will make this tricky: you could get your router to drop those ICMP messages before they go out, but then your router will give the appearance of silently dropping those DF'd datagrams, and the sending host's path MTU discovery may discover the path MTU slowly through timeouts and backoff, or it may not discover it at all, with the result that the send just fails. What you really want to do in that case is have your router clear the DF bit, adjust the IP header checksum, and then go on to fragment the datagram before sending it out the smaller-MTU interface. This isn't RFC-compliant behavior, but you're wanting to test stuff, right? And since you're wanting to test stuff, the next things will be to check that you're assembling the datagram correctly when you've got all the fragments, and to check that you give up when you don't get all the fragments after some time, and to check that you don't leak memory or packet buffers either when you assemble the datagram or when you give up on the datagram. I wouldn't use Linux for this, but that's because I've done things like this before, using FreeBSD, ipfw, dummynet, netgraph, and a small C program to do the DF-clearing stuff. They're the tools I'm comfortable with for this sort of thing. You may have a learning experience either way, and you've already got a penguin handy, you probably know how to work it better than I do. It's not that things send fragments, it's that a network link in the middle has a smaller MTU than the networks on the ends and that routers having more knowledge of this than the hosts on the ends fragment large packets as they pass through. The user first has to recognize the problem as one that can be got around in this way. That's a learned response, and I'm not sure how people learn it these days. And yeah, you may be doing this for a PCjr and not supporting a web browser or NFS, but FTP can trip over this pretty easily, and Telnet can too if the phase of the moon is just right. What I'm really saying here is, if you should decide that fragment reassembly isn't worth doing, think instead about having your TCP stack figure out that it's going to be sending to a non-local host, and adjust its MSS downward for those connections. And giving the user a way to turn that behavior off if he's sure it's safe and he finds the switch. -Frank McConnell