From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 19:31:00 2011 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 A4CEF106564A for ; Wed, 19 Oct 2011 19:31:00 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECE18FC08 for ; Wed, 19 Oct 2011 19:30:59 +0000 (UTC) Received: by wyi40 with SMTP id 40so2715628wyi.13 for ; Wed, 19 Oct 2011 12:30:59 -0700 (PDT) Received: by 10.227.6.223 with SMTP id a31mr2905928wba.112.1319052659169; Wed, 19 Oct 2011 12:30:59 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.199.140 with HTTP; Wed, 19 Oct 2011 12:30:39 -0700 (PDT) In-Reply-To: References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> From: Juli Mallett Date: Wed, 19 Oct 2011 12:30:39 -0700 X-Google-Sender-Auth: 5zc-ZJ6OJhdiRKGfqI85qja1p0Y Message-ID: To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , Rozhuk.IM@gmail.com Subject: Re: ether_demux does not handle frames with embedded vlan tags 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, 19 Oct 2011 19:31:00 -0000 On Wed, Oct 19, 2011 at 07:36, Ryan Stone wrote: > 2011/10/19 =C2=A0: >> This may be a wrong configuration or QinQ: packet may have M_VLAN tag is >> set and still vlan-tagged (ether_type =3D VLAN) > > It is not QinQ in my case. =C2=A0The interface that the upper hook export= s > is that you send it a valid ethernet frame and it passes that frame up > the stack. =C2=A0A vlan-tagged frame is a valid frame so I don't see why = it > should not be handled correctly. Why should the requirements for the Netgraph path be any different to the non-Netgraph path? If drivers must ensure that frames that reach ether_demux have had their VLAN tags stripped, so should Netgraph things that act like drivers. So why don't you move that logic into ether_demux from the ether_input path, or have Netgraph use the ether_input path?