Date: Fri, 13 Jul 2007 12:19:24 -0400 From: Stephen Clark <Stephen.Clark@seclark.us> To: Bill Moran <wmoran@collaborativefusion.com> Cc: freebsd-net@freebsd.org, Sten Daniel Soersdal <netslists@gmail.com> Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <4697A60C.4090409@seclark.us> In-Reply-To: <20070713093408.b8a92c23.wmoran@collaborativefusion.com> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.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>: > > > >>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. Steve >>client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> some >>host on internet >>client sends syn saying i can do mss=1460 >>host sends syn saying i can do mss=1460 >>host tries to send packet of 1460 it get silently dropped. connection >>stalls. >> >>-- >> >>"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) >> >> >> >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> >> >> >> >> > > > > -- "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?4697A60C.4090409>