netdev - How do I receive vlan tags on an AF

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-next>] [day] [month] [year] [list]

Message-ID: <CAMJ=MEe4cvp7-fwbCnq7SLM=44Zy8Jrz35FwRoWG-ytahdPRQA@mail.gmail.com>
Date:	Tue, 30 Jul 2013 15:07:20 +0200
From:	Ronny Meeus <ronny.meeus@...il.com>
To:	netdev <netdev@...r.kernel.org>
Subject: How do I receive vlan tags on an AF_PACKET socket in 3.4 kernel?

Hello

I have ported a legacy application that is processing several packet
streams based on protocol and vlan.
Internally in the application a dispatching is done based on the
VLAN/Protocol field in the Ethernet packets.

To receive the packets I use a AF_PACKET socket on a pure Ethernet
interface (not vlan aware).
A BPF filter is attached to the socket to drop packets I'm not
interested in as soon as possible in the processing path.

This setup worked well until I switched to a 3.4 kernel (I was using
2.6.32 before).
In the 3.4 kernel I see that the vlan information is stripped from the
packets I receive from the socket.

After some searches on Google and browsing the Linux code I found that
the Vlan is stripped from the packet very early in the receive path.
This is the info of the commit:

commit bcc6d47903612c3861201cc3a866fb604f26b8b2
Author: Jiri Pirko <jpirko@...hat.com>
Date:   Thu Apr 7 19:48:33 2011 +0000

    net: vlan: make non-hw-accel rx path similar to hw-accel

    Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
    enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
    vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.

    For non-rx-vlan-hw-accel however, tagged skb goes thru whole
    __netif_receive_skb, it's untagged in ptype_base hander and reinjected

    This incosistency is fixed by this patch. Vlan untagging happens early in
    __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
    see the skb like it was untagged by hw.

Now the question is: What is the correct solution to handle this?

One option I found is using the pcap library since this uses the
auxillary data received from the recvmsg call to reconstruct the vlan
headers, but this would mean that first of all I have to adapt my
application(s) and more importantly that I loose the BPF filter
feature since this is implemented in the kernel.
Another disadvantage is that this requires more processing since the
mac header needs to be moved the packet to make room to store the VLAN
tags.
So first cycles are lost in the kernel to strip the info and a bit
later, the packet to be reconstructed again.

Is there any other way to proceed?

A side question: If I would switch to the libpcap approach, I assume
the application can work on both the 2.6 and 3.4 version of the
kernel, but is there a guarantee that this will also work on future
versions?

Best regards,
Ronny
--
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