netdev - Linux 802.1ad VLAN unexpected beaviour

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: <2537748.74g6mjFNSk@vaio-gio>
Date:	Mon, 26 May 2014 21:39:12 +0200
From:	Gioacchino Mazzurco <gmazzurco89@...il.com>
To:	netdev@...r.kernel.org
Cc:	Patrick McHardy <kaber@...sh.net>
Subject: Linux 802.1ad VLAN unexpected beaviour

Hi All!

As part of my GSoC project I am implementing 802.1ad support for netifd, while 
testing this new code I encountered a very strange behavior on linux kernel, 
the netifd tests just made me notice the unexpected behavior, but are not 
involved in the problem and doesn't are needed to reproduce it.

Interfaces created as 802.1ad VLAN appear to the system as 802.1ad but seems 
they are injecting on the cable 802.1q frames instead of 802.1ad ones.

I have tested various version of linux kernel from 3.10 (the one in wich this 
feature was introtuced) to 3.12.13 and everyone were affected, so it doesn't 
seems to me a regression or something fixed in newer release.

Following how to reproduce the unexpected behavior and some output from my 
commandline.

My setup have two linux host connected by ethernet cable.

#### On host A 

# first configure the vlan interface

ip link add link eth0 test1 type vlan proto 802.1ad id 1000
ip link set up dev test1

# then send some traffic on that new device with
ping6 ff02::3%test1

# on another window on the same device sniff what seems is going out from eth0

tcpdump -n -e -vv -ttt -i eth0 not tcp port 23 and not arp

# the output will be something like that:
OUTPUT<<

tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
bytes
00:00:00.000000 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q-QinQ 
(0x88a8), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 1
00:00:01.005251 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q-QinQ 
(0x88a8), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 2
00:00:00.999914 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q-QinQ 
(0x88a8), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 3

OUTPUT

# as you can see the ethertype is the expected one 802.1Q-QinQ (0x88a8) == 
802.1ad


# on host B

# at the same time run tcpdump on host B with similar parameters

tcpdump -n -e -vv -ttt -i ethernet0 not tcp port 23 and not arp

# you will see something like that:

OUTPUT<<

tcpdump: listening on ethernet0, link-type EN10MB (Ethernet), capture size 
65535 bytes
00:00:00.000000 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q 
(0x8100), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 1
00:00:01.005301 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q 
(0x8100), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 2
00:00:01.000044 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q 
(0x8100), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 3
00:00:01.000014 00:15:6d:9f:48:72 > 33:33:00:00:00:03, ethertype 802.1Q 
(0x8100), length 122: vlan 1000, p 0, ethertype IPv6, (hlim 1, next-header 
ICMPv6 (58) payload length: 64) fe80::215:6dff:fe9f:4872 > ff02::3: [icmp6 sum 
ok] ICMP6, echo request, seq 4
 
OUTPUT

# as you can see the ethertype is not the expected one 802.1Q (0x8100) != 
802.1ad

# Inverting Host A and B give same behavior

Thanks for help and attention :)
--
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