* Linux 802.1ad VLAN unexpected beaviour
@ 2014-05-26 19:39 Gioacchino Mazzurco
2014-05-26 19:55 ` Daniel Borkmann
0 siblings, 1 reply; 3+ messages in thread
From: Gioacchino Mazzurco @ 2014-05-26 19:39 UTC (permalink / raw)
To: netdev; +Cc: Patrick McHardy
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 :)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux 802.1ad VLAN unexpected beaviour
2014-05-26 19:39 Linux 802.1ad VLAN unexpected beaviour Gioacchino Mazzurco
@ 2014-05-26 19:55 ` Daniel Borkmann
2014-05-26 20:13 ` Gioacchino Mazzurco
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Borkmann @ 2014-05-26 19:55 UTC (permalink / raw)
To: Gioacchino Mazzurco; +Cc: netdev, Patrick McHardy
On 05/26/2014 09:39 PM, Gioacchino Mazzurco wrote:
> 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
I think, as we already had a similar discussion on this topic on netdev, it's
a libpcap problem, not a kernel one. See also the thread:
http://lists.openwall.net/netdev/2014/04/14/19
Perhaps the given patch there works for you.
> # 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux 802.1ad VLAN unexpected beaviour
2014-05-26 19:55 ` Daniel Borkmann
@ 2014-05-26 20:13 ` Gioacchino Mazzurco
0 siblings, 0 replies; 3+ messages in thread
From: Gioacchino Mazzurco @ 2014-05-26 20:13 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, Patrick McHardy
On Monday 26 May 2014 21:55:57 Daniel Borkmann wrote:
> I think, as we already had a similar discussion on this topic on netdev,
> it's a libpcap problem, not a kernel one. See also the thread:
>
> http://lists.openwall.net/netdev/2014/04/14/19
After doing some more tests trying to verify your suggestion seems you are
right :)
Many Thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-05-26 20:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-26 19:39 Linux 802.1ad VLAN unexpected beaviour Gioacchino Mazzurco
2014-05-26 19:55 ` Daniel Borkmann
2014-05-26 20:13 ` Gioacchino Mazzurco
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).