VLAN test cases in 2.6.38.7

I wrote a simple bridge that uses packet sockets to read/write from network devices. I'll upload this code somewhere when I get it a bit more presentable.

Machine info:

Linux lf0300-demo 2.6.38.7+ #14 SMP Mon May 23 10:31:45 PDT 2011 i686 i686 i386 GNU/Linux

Interface A: eth1
driver: igb
version: 3.0.19
firmware-version: 1.2-1
bus-info: 0000:01:00.0

Interface B: eth3:
driver: igb
version: 3.0.19
firmware-version: 1.2-1
bus-info: 0000:01:00.1

If no vlans are on eth1 and eth3, then it bridges fine, with vlan headers inline. But, if you add a VLAN to eth1, it stops working, probably because pkt tag is then un-stripped. I was generating on vlan 7, and created vlan 9, btw.

I'll see if I can figure out how to use aux-data next...

Thanks,
Ben

Quoted 28 lines · Ben Greear

I wrote a simple bridge that uses packet sockets to read/write from network devices. I'll upload this code somewhere when I get it a bit more presentable.

Machine info:

Linux lf0300-demo 2.6.38.7+ #14 SMP Mon May 23 10:31:45 PDT 2011 i686 i686 i386 GNU/Linux

Interface A: eth1
driver: igb
version: 3.0.19
firmware-version: 1.2-1
bus-info: 0000:01:00.0

Interface B: eth3:
driver: igb
version: 3.0.19
firmware-version: 1.2-1
bus-info: 0000:01:00.1

If no vlans are on eth1 and eth3, then it bridges fine, with vlan headers inline. But, if you add a VLAN to eth1, it stops working, probably because pkt tag is then un-stripped. I was generating on vlan 7, and created vlan 9, btw.

Quoted 1 line

I'll see if I can figure out how to use aux-data next...

Why does the aux-data mask out the CFI bit? Shouldn't we just pass the 16-bit VLAN tag un-modified to user-space?

Quoted 29 lines · Ben Greear

Quoted 28 lines · Ben Greear

I wrote a simple bridge that uses packet sockets to read/write from network devices. I'll upload this code somewhere when I get it a bit more presentable.

Machine info:

Linux lf0300-demo 2.6.38.7+ #14 SMP Mon May 23 10:31:45 PDT 2011 i686 i686 i386 GNU/Linux

Interface A: eth1
driver: igb
version: 3.0.19
firmware-version: 1.2-1
bus-info: 0000:01:00.0

Interface B: eth3:
driver: igb
version: 3.0.19
firmware-version: 1.2-1
bus-info: 0000:01:00.1

If no vlans are on eth1 and eth3, then it bridges fine, with vlan headers inline. But, if you add a VLAN to eth1, it stops working, probably because pkt tag is then un-stripped. I was generating on vlan 7, and created vlan 9, btw.

Quoted 4 lines

Quoted 1 line

I'll see if I can figure out how to use aux-data next...

Why does the aux-data mask out the CFI bit? Shouldn't we just pass the 16-bit VLAN tag un-modified to user-space?

Either my ubridge code is broken, or 2.6.38.7+ doesn't send tp_vlan_tci properly. All I ever see is zero for that field.

Test case is:

set up VLAN traffic generator on VLAN 7 on separate machine. udp traffic, 56kbps, 1024 byte udp payload.

Set up ubridge on test machine:
ifconfig eth1 promisc
ifconfig eth3 promisc
# Make NIC go into stripping mode.
ip link add link eth1 up name eth1.9 type vlan id 9 ./do_test.pl eth1 eth3

Expect that at least tci is != 0.

The ubridge code is here:
http://www.candelatech.com/~greearb/misc/ubridge.tar.gz

Thanks,
Ben

Either my ubridge code is broken, or 2.6.38.7+ doesn't send tp_vlan_tci
properly. All I ever see is zero for that field.

From: Ben Greear<[email protected]>
Date: Tue, 24 May 2011 15:52:52 -0700

Quoted 3 lines

Either my ubridge code is broken, or 2.6.38.7+ doesn't send tp_vlan_tci
properly. All I ever see is zero for that field.

You need to put the af_packet socket into TPACKET_V2 format.

Quoted 8 lines · David Miller

From: Ben Greear<[email protected]>
Date: Tue, 24 May 2011 15:52:52 -0700

Quoted 3 lines

Either my ubridge code is broken, or 2.6.38.7+ doesn't send tp_vlan_tci
properly. All I ever see is zero for that field.

You need to put the af_packet socket into TPACKET_V2 format.

Actually, that doesn't seem needed. I just needed to give more space to the cmsg buffer to account for the cmsg struct overhead. (And I had a bunch of other bugs, but that was the only one that directly affected the tci field.)

I think that TPACKET_V2 stuff might be only for reading memmapped messages or something like that?

It looks like for any flexible user-space code, we are just going to have to use recvmesg instead of recvfrom, and add the extra checks for cmesg data. I'll post code when I get it working better so the next person to try this might have an easier time :P

I think we will need to add the has-vlan-tci flag to the cmesg data, and probably also remove that masking of the CFI bit.

I've no idea about socket filters, but maybe someone else can deal with that :)

Thanks,
Ben