Date: Mon, 16 Jul 2007 17:56:06 +0200 From: Sten Daniel Soersdal <netslists@gmail.com> To: Stephen.Clark@seclark.us Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <469B9516.2090904@gmail.com> In-Reply-To: <46992021.8090603@seclark.us> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com> <46992021.8090603@seclark.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Clark wrote: > 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. You make compelling argument about this. I was under the assumption that you were YANN (Yet Another Network Newbie). Please excuse my assumption and the reiteration of my first arguments. I guess it wouldn't hurt for the operating system to accept larger frames, as long as only the correctly sized frames are transmitted. There are alot of people, including myself, that assume a host can't receive a frame that is larger than MTU. Perhaps it should be noted in the man pages about this behavior in addition? -- Sten Daniel Soersdal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469B9516.2090904>