[Click] Problem sending VLAN tagged packets

[Mike Wilson]

I think I know what's happening here.

First, the change in the ethernet header length from plain old ethernet to 
VLANs is in 802.1ac, not 802.1q.  Don't ask me, I don't write the 
standards!

One point to note: in the linux kernel's model, the MTU does *not* change. 
The header length changes.  This means that the underlying device still 
has MTU of 1500.  If you add a VLAN device on top of the raw ethernet 
device, it keeps the underlying MTU (from dev->mtu) and then grabs the 
underlying header length (dev->hard_header_len) and adds 4 to a local 
copy.  For the underlying ethernet device (eth5, in the example), this is 
14.  (Lengths are reported without the FCS, since it's just the header.) 
For a VLAN device, it's 18.

Now, as for the actual problem, here's how it's happening.  I assume 
you're using userlevel ToDevice.  This opens a raw packet socket with 
protocol ETH_P_ALL.  That opens a raw socket in the kernel to the device 
you specify (eth5).  When a packet hits ToDevice, it eventually reaches 
the raw socket interface in the linux kernel at net/packet/af_packet.c, 
function packet_sendmsg().  That function checks the length of the 
datagram against *this* device's dev->mtu and dev->hard_header_len, along 
with a "reserve" which is set to 0 in this case.

There's the problem.  How to work around it?  The easy solution is to 
create a vint with vconfig (you may need to change your kernel config and 
recompile), then instantiate ToDevice(vint_foo).  That will correctly 
check that you're sending 802.1Q packets and pass them unchanged (or 
encapsulate if you don't do it yourself).  It'll also compare to the 
correct length (1500 + 18).  That may not meet your needs, but it'll work.

Beyond that, I haven't a clue what a "right" solution would be.  Raw 
packet sockets aren't really *totally* raw.  I think that this represents 
a subtle bug in the linux kernel.  It would be well if the raw packet 
socket checked to see if the frame were 802.1Q, checked to see if the 
device supports VLANs, and then altered the "reserve" to allow for VLAN 
frames.  Unfortunately, this would also require the raw sockets to know 
about 802.1Q frames, which is a bad thing from an abstraction / isolation 
point of view.

-Mike Wilson

PS- Not everything we do at 1AM is correct.  Take my rambling with a grain 
of salt!

On Wed, 14 Feb 2007, Jens Mueller wrote:

> Hi,
>
>> OK, I'm trying to add a VLAN tag on all packets.  Of course, for MTU
>> packets, this adds 4 bytes.
>>
>> So I'm getting a bunch of
>> ToDevice(eth5) send: Message too long
>> errors from these now "overlength" packets.
>> However, these are NOT overlength, as MTU for ethernet is +4 bytes for
>> VLAN tagged packets.  Suggestions?
>
> I can confirm this behaviour. My device's MTU is 1500:
>
> 1514 | 02020202 02020002 b3327519 08001111 11111111 11111111
> 1518 | 02020202 02020002 b3327519 81000000 08001111 11111111
> ToDevice(eth1) send: Message too long
>
> I suppose my tagged packet above is correct according to 802.1Q and
> rejected by the kernel. Can you point me to the spec, where it says that
> MTU is increased by 4 for VLAN packets? I haved looked at the 802.1Q spec
> (http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf), but
> could not find it myself.
>
> Kind regards,
> Jens
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>