Re: Bug in Linux networking code

Alan Cox (alan@lxorguk.ukuu.org.uk)
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