From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 17:04:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CC9616A403 for ; Fri, 13 Jul 2007 17:04:04 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id D45C213C48D for ; Fri, 13 Jul 2007 17:04:03 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 13 Jul 2007 13:04:03 -0400 id 00056424.4697B083.00010E0A Date: Fri, 13 Jul 2007 13:04:02 -0400 From: Bill Moran To: Stephen.Clark@seclark.us Message-Id: <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> In-Reply-To: <4697A60C.4090409@seclark.us> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 17:04:04 -0000 In response to Stephen Clark : > Bill Moran wrote: > > >In response to Stephen Clark : > > > >>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? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023