Date: Sat, 14 Jul 2007 15:12:33 -0400 From: Stephen Clark <Stephen.Clark@seclark.us> To: Sten Daniel Soersdal <netslists@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <46992021.8090603@seclark.us> In-Reply-To: <4698D290.5080004@gmail.com> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sten Daniel Soersdal wrote: >Stephen Clark wrote: > > >>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. >> >>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. >> >> >> > >You are trying to lower the mtu on the wrong end. >As i said, all hosts on the same L2 needs to share the same mtu. >The router that forwarded you that packet is obviously not using the >same mtu (otherwise it would not be able to forward it to you). >Either you need to lower that routers local interface mtu or you need to >raise your hosts mtu to match that of the router. >Because ALL hosts on the same L2 network need to have the same mtu. > > > I don't disagree - my issue is that this is new behavior in FreeBSD 6.x that did not exist in FreeBSD 4.x. However as many have said in thread : >From RFC-1122, and memorialized on the working group coffee cup on my bookshelf: Be liberal in what you accept, and conservative in what you send (attributed to RFC-791, but paraphrased; also in RFC-793; for those who don't recognize them, these are the original IP and TCP specs.) >> The ability to receive packets larger than mtu was not accidental. >> This should be fixed, if it is, as is suggested, a deliberate change. > > I'd be happy to see the change undone as well. I (well, our test group) found this change in a similar way, and it didn't agree with our previous usage. -- "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?46992021.8090603>