linux-kernel - Re: [PATCH v3 2/2] net: dsa: ocelot: Add support for QinQ Operation

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200722125352.qbllow6pm6za5pq4@skbuf>
Date:   Wed, 22 Jul 2020 15:53:52 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     hongbo.wang@....com
Cc:     xiaoliang.yang_1@....com, allan.nielsen@...rochip.com,
        po.liu@....com, claudiu.manoil@....com,
        alexandru.marginean@....com, vladimir.oltean@....com,
        leoyang.li@....com, mingkai.hu@....com, andrew@...n.ch,
        f.fainelli@...il.com, vivien.didelot@...il.com,
        davem@...emloft.net, jiri@...nulli.us, idosch@...sch.org,
        kuba@...nel.org, vinicius.gomes@...el.com,
        nikolay@...ulusnetworks.com, roopa@...ulusnetworks.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        horatiu.vultur@...rochip.com, alexandre.belloni@...tlin.com,
        UNGLinuxDriver@...rochip.com, ivecera@...hat.com
Subject: Re: [PATCH v3 2/2] net: dsa: ocelot: Add support for QinQ Operation

On Wed, Jul 22, 2020 at 06:32:00PM +0800, hongbo.wang@....com wrote:
> From: "hongbo.wang" <hongbo.wang@....com>
> 
> This featue can be test using network test tools
>     TX-tool -----> swp0  -----> swp1 -----> RX-tool
> 
> TX-tool simulates Customer that will send and receive packets with single
> VLAN tag(CTAG), RX-tool simulates Service-Provider that will send and
> receive packets with double VLAN tag(STAG and CTAG). This refers to
> "4.3.3 Provider Bridges and Q-in-Q Operation" in VSC99599_1_00_TS.pdf.
> 
> The related test commands:
> 1.
> ip link add dev br0 type bridge
> ip link set dev swp0 master br0
> ip link set dev swp1 master br0
> 2.
> ip link add link swp0 name swp0.111 type vlan id 111
> ip link add link swp1 name swp1.111 type vlan protocol 802.1ad id 111
> 3.
> bridge vlan add dev swp0 vid 100 pvid
> bridge vlan add dev swp1 vid 100
> bridge vlan del dev swp1 vid 1 pvid
> bridge vlan add dev swp1 vid 200 pvid untagged
> Result:
> Customer(tpid:8100 vid:111) -> swp0 -> swp1 -> Service-Provider(STAG \
>                     tpid:88A8 vid:100, CTAG tpid:8100 vid:111)
> 
> Signed-off-by: hongbo.wang <hongbo.wang@....com>
> ---

Instead of writing a long email, let me just say this.
I ran your commands on 2 random network cards (not ocelot/felix ports).
They don't produce the same results as you. In fact, no frame with VLAN
111 C-TAG is forwarded (or received) at all by the bridge, not to
mention that no VLAN 1000 S-TAG is pushed on egress.


Have you tried playing with these commands?

ip link add dev br0 type bridge vlan_filtering 1 vlan_protocol 802.1ad
ip link set eth0 master br0
ip link set eth1 master br0
bridge vlan add dev eth0 vid 100 pvid
bridge vlan add dev eth1 vid 100

They produce the same output as yours, but have the benefit of using
the network stack's abstractions and not glue between the 802.1q and the
bridge module, hidden in the network driver.

I am sending the following packet towards eth0:

00:04:9f:05:f4:ad > 00:01:02:03:04:05, ethertype 802.1Q (0x8100), length 102: \
	vlan 111, p 0, ethertype IPv4, 10.0.111.1 > 10.0.111.3: \
	ICMP echo request, id 63493, seq 991, length 64

and collecting it on the partner of eth1 as follows:

00:04:9f:05:f4:ad > 00:01:02:03:04:05, ethertype 802.1Q-QinQ (0x88a8), length 106: \
	vlan 100, p 0, ethertype 802.1Q, vlan 111, p 0, ethertype IPv4, \
	10.0.111.1 > 10.0.111.3: ICMP echo request, id 63493, seq 991, length 64

Thanks,
-Vladimir