From owner-freebsd-net@FreeBSD.ORG Fri Mar 13 23:17:51 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C8A1065672; Fri, 13 Mar 2009 23:17:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 564A28FC12; Fri, 13 Mar 2009 23:17:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id B768C2EF6E0; Fri, 13 Mar 2009 19:17:50 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 13 Mar 2009 19:17:50 -0400 X-Sasl-enc: PFAd0XA7PR3Jw1twCICfvvsfkh9rCLmbm+RYHYTpI7fG 1236986270 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CF97313985; Fri, 13 Mar 2009 19:17:49 -0400 (EDT) Message-ID: <49BAE99B.2030508@incunabulum.net> Date: Fri, 13 Mar 2009 23:17:47 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Sean C. Farley" References: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Rui Paulo Subject: Re: tap(4) SIOCSIFMTU patch 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 Mar 2009 23:17:51 -0000 Sean C. Farley wrote: > > Yes, this fixes my issue with bridging a tap device to an interface > with an MTU higher than 1500. > I will probably commit this patch this weekend. I can't think of any reason why not, other than you might want to ensure that tap's MTU is bounded within reasonable limits, 'cause yoi don't want to exhaust the jumbo cluster pool if say mtu is more than 9000. I think ifconfig already performs such a check but you might want to double check. cheers BMS