From owner-freebsd-net@FreeBSD.ORG Wed Feb 14 22:18:52 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 57F0D16A406 for ; Wed, 14 Feb 2007 22:18:52 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 31EBE13C48D for ; Wed, 14 Feb 2007 22:18:52 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C80221AE8B0 for ; Wed, 14 Feb 2007 17:18:49 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 14 Feb 2007 17:18:49 -0500 X-Sasl-enc: cmlPXq8fW1HO4Le3yUFViKvynBKfcI5o7CKucKQtSsvf 1171491529 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 ESMTP id 31852181C for ; Wed, 14 Feb 2007 17:18:48 -0500 (EST) Message-ID: <45D38AC9.50107@incunabulum.net> Date: Wed, 14 Feb 2007 22:18:49 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PATCH] Updated 802.1p/q 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: Wed, 14 Feb 2007 22:18:52 -0000 Hi, I have tested my 802.1p input patch with vlans configured. So far so good. It is now available from: http://people.FreeBSD.org/~bms/dump/latest-8021p.diff This updated patch moves the 802.1q encapsulation into if_ethersubr.c, allowing M_VLANTAG to be passed up and down the stack for 802.1p priority. I would greatly appreciate wider testing before it is committed. I've noticed that vlan(4) will not put a parent interface into PROMISC if the vlanhwtag capability exists but is disabled. If the main non-vlan input path receives datagrams destined for a layer 3 address configured on a vlan interface, the netinet stack will quite reasonably try to reply on the vlan interface unless net.inet.ip.check_interface is set to 1; something to be aware of. If vlan(4) gets an mbuf which has already been tagged with M_VLANTAG from higher up in the stack, it *should* ignore the vlan id by overwriting it, and using the priority field already assigned to it, so that ALTQ or PF can do its magic. This new patch should do this. The Ethernet code will not use 802.1p by default unless it came from higher up (by way of M_VLANTAG passed to a driver); we should insert the 802.1p tag in the situation where we got an M_VLANTAG from further up without a vlan(4) instance being involved. The new patch should do this. We should also make sure the CFI bit is always cleared in bridging situations as it has special meaning for token ring and FDDI. What has not been tested or considered is the situation where we have nested VLANs. At least one individual has asked about this feature. At the moment, I'd suggest that only Netgraph potentially deals with this rather than the main network stack. Regards, BMS