Hi Ran,
Alex,
I don't see rx-vlan-offload option in my ethtool. strange, maybe it is
not available in all ethtool versions ?
According to my manpage for ethtool v4.5, the relevant -K option is
"rxvlan".
Hi Peter,
Yes, I'm using AF_PACKET (I can't validate it now for 100%, but I
quite sure about it).
Okay - but I assume that you are writing a userspace application, not a
kernelspace driver or module, right?
I'm accessing the ethernet header, and it always gives me non extended
ethernet header (without vlan information).
It seems that this behavior has been around for a long time, and is
intentional. See the following thread for more information:
http://www.spinics.net/lists/netdev/msg244668.html
The only legit way of accessing VLAN tag info on an AF_PACKET socket I
know about is by setting the PACKET_AUXDATA socket option, and reading
the auxiliary data as a struct tpacket_auxdata using recvmsg().
In addition, however, there seems to be a bug in the kernel in that the
tp_vlan_tci member of the struct tpacket_auxdata is filled in only if
the AF_PACKET socket is bound to htons(ETH_P_ALL). If the socket is
bound to any other specific protocol, the tp_vlan_tci is set to 0. I
have raised this issue recently in the following thread(s) but have not
received a response yet:
http://www.spinics.net/lists/netdev/msg372830.html
http://www.spinics.net/lists/netdev/msg373112.html
I can see the vlan tag in vlan_tci field in sk_buff, but this is not
exactly what I need, I need the header AS-IS with the original
(extended) ethernet header.
How are you accessing the vlan_tci field from your software?
In any case, with AF_PACKET sockets, I am afraid you don't have much
choice. Even libpcap reconstructs VLAN-tagged frames by reading the VLAN
tag from an auxiliary structure and then re-inserting it into the frame,
because the frame delivered through an AF_PACKET socket does not have
the VLAN tag present anymore.
Best regards,
Peter
