Date: Fri, 13 Jul 2007 13:12:37 -0400 From: Stephen Clark <Stephen.Clark@seclark.us> To: Bill Moran <wmoran@collaborativefusion.com>, freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <4697B285.9050602@seclark.us> In-Reply-To: <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Moran wrote: >In response to Stephen Clark <Stephen.Clark@seclark.us>: > > > >>Bill Moran wrote: >> >> >> >>>In response to Stephen Clark <Stephen.Clark@seclark.us>: >>> >>> >>> >>>>Sten Daniel Soersdal wrote: >>>> >>>> >>>> >>>>>Stephen Clark wrote: >>>>> >>>>> >>>>> >>>>>>Hello, >>>>>> >>>>>>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>>>>>accept a larger incomming packet. >>>>>> >>>>>>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max >>>>>>1294) >>>>>> >>>>>> >>>>>That is what to be expected. >>>>>Incoming interface must have mtu set to the same mtu as all other hosts >>>>>on the same L2 network. If mtu is set to the same as all other hosts, >>>>>then it is impossible to receive a frame that is too large (assuming >>>>>everything works). >>>>> >>>>> >>>>> >>>>>>I don't think it worked this way in the past. >>>>>> >>>>>>Won't this affect pmtud? >>>>>> >>>>>> >>>>>Incoming interface must have its mtu set to large enough to receive the >>>>>frame. Outgoing interface, on the other hand, can be lower. >>>>> >>>>>For pmtud to work you need to be able to receive packets on an interface >>>>>with sufficiently set mtu, but the exitting interface can have a lower >>>>>mtu configured. Thus the router can accept the incoming packet but may >>>>>drop and notify on a frame that is too large to exit the outgoing >>>>>interface (assuming DF is set). >>>>> >>>>> >>>>> >>>>>>man page for ifconfig says mtu limits size of "transmission" not reception. >>>>>> >>>>>> "mtu n Set the maximum transmission unit of the interface to n, >>>>>>default >>>>>> is interface specific." >>>>>> >>>>>> >>>>>> >>>>>Perhaps the man author considered reception to be implied? >>>>> >>>>>In any case, enforcing this on incoming packets is correct behavior. >>>>> >>>>> >>>>But shouldn't an icmp be generated back to the system sending the packet >>>>that is >>>>being dropped? This is not happening. So the connection stalls. >>>> >>>> >>>No. You're thinking of PMTU, which involves the don't fragment bit and >>>intermediate routers. >>> >>>A packet that exceeds the network maximum MTU is an invalid packet, and >>>thus should be dropped silently or it could cause a DoS. >>> >>> >>This is not the behavior FreeBSD 4.9 exhibits. I just tested it. I had a >>mtu of 1280 on the >>rl1 interface and it glady accepted packets of 1460. >> >> > >I don't see that as relevant. I'm sure earlier versions of many parts of >FreeBSD had bugs. Take also into account the fact that best practices are >still evolving. > >Let's flip the question around a bit: why would you _want_ the TCP stack >to accept frames larger than the stated MTU? > > > I guess because thats the way it used to work ;-) , and it caused me confusion in testing our updated security appliance that used to be based on 4.9 and now will be based on 6.x. As I am gaining a better understanding of things I don't see it as a real problem. Thanks for you input. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4697B285.9050602>