netdev - Re: [PATCH] filter: introduce SKF_AD_VLAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <96C60242-C380-4B97-9BA5-6E88ABFB18EC@alum.mit.edu>
Date:	Thu, 5 Mar 2015 00:35:01 -0800
From:	Guy Harris <guy@...m.mit.edu>
To:	Michal Kubecek <mkubecek@...e.cz>
Cc:	Jiri Pirko <jpirko@...hat.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Michal Sekletar <msekleta@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] filter: introduce SKF_AD_VLAN_PROTO BPF extension

On Mar 4, 2015, at 11:24 PM, Michal Kubecek <mkubecek@...e.cz> wrote:

> To be more precise, it does not need it now as there is no syntax for
> pcap filter on TPID,

In the current version of libpcap (and the commit dates back to November 2011), the filter "vlan" checks both for 0x8100 and 0x9100 (it should perhaps also check for other TPID values), in userland and in the kernel on platforms other than Linux, as the generated code checks for both values.

If there is a way that an in-kernel BPF program can check for all VLAN TPID values, that would be helpful; that would be sufficient to implement the filter "vlan" in a fashion that works the same in the Linux kernel and in other contexts.  (I presume that one can, from the data delivered to a PF_PACKET SOCK_RAW socket, reconstruct the packet as received, with all the VLAN tags in place in the packet just as they were when the packet hit the adapter's transceiver from the network.  If not, that's a *separate* deficiency.)

I'm not currently worried about Backbone Service Instance Tag Control Information right now, as libpcap currently doesn't handle that, so there's no need to, for the generated code for "vlan", actually test what particular TPID value is in the packet, as long as we can test whether there's a VLAN header or not.  In the future, that might be useful.

(BTW, why did the IEEE remove 802.1Q from the IEEE Get program for IEEE 802 standards?

	http://standards.ieee.org/about/get/802/802.1.html

Are they waiting for 802.1Q-2014 to be published?

	http://www.ieee802.org/1/pages/802.1Q-2014.html

And what's the current status of 802.1ad?  Is QinQ deprecated or something?)--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html