Messages in this thread | | | From | (Alan Cox) | Subject | Re: Bug in Linux networking code | Date | Thu, 22 Jan 1998 11:00:29 +0000 (GMT) |
| |
> it seems like a have found a bug in the linux networking code: > occasionally, it will set the DF (don't fragment) bit instead of the > MF (more fragments) bit in the first fragment of a TCP segment (looks > like a typo somewhere). I'm not sure under which circumstances this > bug shows up.
I think you've found a bug in your IP filtering and understanding of IP unless I've missed something you are meaning to point out
> First packet dump, which shows the bug (captured with IP Filter on a > NetBSD 1.3 machine. I added some comments next to the hexdump, and > marked the byte in question as *40* (DF=1, MF=0). Sorry for the huge > lines). The fragment following the buggy one would normally be caught > and blocked by IP Filter, because the first fragment does not indicate > that more fragments will follow (this is how I noticed the problem).
Firstly DF=1 MF=0 is completely legal. Its path mtu discovery as invented in the early 1990's and used by SGI, Solaris, Linux and I believe NT boxes as standard. Its probably in FreeBSD too.
All TCP frames are sent DF=1 MF=0 (unless they are fragmented), that allows the TCP's to work out the optimum packet size for transmission across the link by recovering the "fragmentation failed" host unreachable messages. The great thing about this is its backward compatible with prehistoric products too.
The only possibly invalid case is DF=1 MF!=0 which would mean dont fragment but already fragmented. The RFC doesnt actually prohibit an end host generating such frames however and even they could have uses
If its causing you problems I'd say your firewall rules and/or system have the problem. If its not causing you problems then everything is working fine.
Alan
| |