Date: Tue, 30 Mar 2004 11:09:27 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: David Gilbert <dgilbert@dclg.ca> Subject: Re: Disabling VLAN_HWTAGGING Message-ID: <20040330080927.GB91501@ip.net.ua> In-Reply-To: <Pine.BSF.4.21.0403291314001.29660-100000@InterJet.elischer.org> References: <16488.33020.907107.289101@canoe.dclg.ca> <Pine.BSF.4.21.0403291314001.29660-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 29, 2004 at 01:14:46PM -0800, Julian Elischer wrote: >=20 >=20 > On Mon, 29 Mar 2004, David Gilbert wrote: >=20 > > >>>>> "Julian" =3D=3D Julian Elischer <julian@elischer.org> writes: > >=20 > > >> itself. No matter how it's set, in both Linux and FreeBSD, many > > >> nge chipsets will not show vlan packets from the driver with a > > >> tcpdump. > >=20 > > Julian> netgraph interception? > >=20 > > I don't understand the question. If you have a vlan on nge0, and you > > tcpdump the vlan interface, you get what you expect. If you tcpdump > > the nge0 interface, you get all the packets from all the vlans without > > vlan tags to differentiate. The FreeBSD and Linux drivers share this > > behaviour. >=20 > I was just pointing out that if tcpdump seems to not catch some things > you can also try netgraph interception.. > But apparently from what you say it's not needed. >=20 This is more convoluted than it seems. In 4.x, if the interface supports VLAN stripping in firmware, the driver calls if_vlan.c:vlan_input_tag() which "fakes up" a normal VLAN header and passes it to BPF for inspection. OTOH, vlan_input_tag() also searches through the list of all vlan(4) interfaces attempting to find an interface with the matching VLAN tag, so ng_vlan(4) doesn't have a chance of working in RELENG_4 for NIC drivers that support stripping VLAN tags in firmware. In 5.x, drivers always call ether_input() which has proper hooks into Netgraph (so ng_vlan(4) always works), but it doesn't "fake up" the VLAN header as vlan_input_tag() does in RELENG_4, so you cannot see the original VLAN packet -- you see the VLAN-stripped packet on the parent interface (I will look into fixing it later)! In any case, you cannot see the "normal" VLAN packet with tcpdump(1) on originating host that does the VLAN insertion in firmware. (You need to set the IFF_LINK0 flag on the vlan(4) interface in RELENG_4 to tell it that the parent device supports VLAN insertion in firmware.) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaSs3Ukv4P6juNwoRAiXwAJ9glne98xMY/qdQ9lrqjDojOPVcdACcCy8u x7gK5ids5We1d4VjIq0cYhg= =htu0 -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040330080927.GB91501>