Subject: Re: fragmentation by NetBSD routers vs. reassembly on other systems....
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-net
Date: 09/02/2000 01:31:54
[ On Saturday, September 2, 2000 at 13:17:02 (+0900), wrote: ]
> Subject: Re: fragmentation by NetBSD routers vs. reassembly on other systems....
> 	router 1 was broken from DF bit manipulation.  it behaved like this:
> 	- if DF bit is raised on a packet, it worked fine.  it transmits
> 	  icmp "too big" as necessary toward source, if the source node sends
> 	  1500byte-packets.
> 	- if DF bit is off, it behaved wrong.  if the source node sends
> 	  1500byte-packets, it drops the packet onto the floor.  router 1
> 	  should have fragmented the packet on its own and relay it to router 2
> 	  (VLAN side), but it did not.

My "router 1" is my 486/66 NetBSD-1.4V machine with a GIF tunnel, and it
does appear to successfully send fragmented packets, and most remote
systems do recieve those fragmented packets sucessfully and they
apparently reassemble them without problems.

Other than that though your observations do appear to match my own.

> 	i guess there is some broken device, somewhere between you and the
> 	destination.

This has been my assumption too, but unfortunately I've been unable to
identify the device and indeed the only scenarios I can imagine which
don't involve the remote server itself are so far fectched I can't quite
believe they are possible.

However with the current wide deployment of 1500-byte MTUs most
everywhere but on dial-up PPP end systems, and with increasing numbers
of hosts using Path-MTU-discovery, I can easily imagine that some TCP
stacks have not recently (ever?) had their reassembly code exercised
very well, and indeed that some may not even have had their
fragmentation code thoroughly tested.  The result may just be
interoperabilty problems with some specific combinations of
implementations while all others continue to "be liberal in what they

>  i'm not sure if turning path MTU discovery on
> 	always helps, as there are stupid admins who filters out all icmp
> 	packets at their firewall (and preventing path MTU discovery from
> 	working).

In this case I'm the only admin who can accidentally filter my own ICMP
packets, so I think I'm OK with using mtudisc in this situation!  :-)

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>