netdev - Re: Correct tc-vlan usage

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

Message-ID: <20200421195147.GI6581@nanopsycho.orion>
Date:   Tue, 21 Apr 2020 21:51:47 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: Correct tc-vlan usage

Tue, Apr 21, 2020 at 08:26:42PM CEST, olteanv@...il.com wrote:
>Hi Jiri,
>
>On Mon, 20 Apr 2020 at 17:37, Jiri Pirko <jiri@...nulli.us> wrote:
>>
>> Wed, Apr 15, 2020 at 07:59:06PM CEST, olteanv@...il.com wrote:
>> >Hi,
>> >
>> >I am trying to use tc-vlan to create a set of asymmetric tagging
>> >rules: push VID X on egress, and pop VID Y on ingress. I am using
>> >tc-vlan specifically because regular VLAN interfaces are unfit for
>> >this purpose - the VID that gets pushed by the 8021q driver is the
>> >same as the one that gets popped.
>> >The rules look like this:
>> >
>> ># tc filter show dev eno2 ingress
>> >filter protocol 802.1Q pref 49150 flower chain 0
>> >filter protocol 802.1Q pref 49150 flower chain 0 handle 0x1
>> >  vlan_id 103
>> >  dst_mac 00:04:9f:63:35:eb
>> >  not_in_hw
>> >        action order 1: vlan  pop pipe
>> >         index 6 ref 1 bind 1
>> >
>> >filter protocol 802.1Q pref 49151 flower chain 0
>> >filter protocol 802.1Q pref 49151 flower chain 0 handle 0x1
>> >  vlan_id 102
>> >  dst_mac 00:04:9f:63:35:eb
>> >  not_in_hw
>> >        action order 1: vlan  pop pipe
>> >         index 5 ref 1 bind 1
>> >
>> >filter protocol 802.1Q pref 49152 flower chain 0
>> >filter protocol 802.1Q pref 49152 flower chain 0 handle 0x1
>> >  vlan_id 101
>> >  dst_mac 00:04:9f:63:35:eb
>> >  not_in_hw
>> >        action order 1: vlan  pop pipe
>> >         index 4 ref 1 bind 1
>> >
>> ># tc filter show dev eno2 egress
>> >filter protocol all pref 49150 flower chain 0
>> >filter protocol all pref 49150 flower chain 0 handle 0x1
>> >  dst_mac 00:04:9f:63:35:ec
>> >  not_in_hw
>> >        action order 1: vlan  push id 102 protocol 802.1Q priority 0 pipe
>> >         index 3 ref 1 bind 1
>> >
>> >filter protocol all pref 49151 flower chain 0
>> >filter protocol all pref 49151 flower chain 0 handle 0x1
>> >  dst_mac 00:04:9f:63:35:eb
>> >  not_in_hw
>> >        action order 1: vlan  push id 102 protocol 802.1Q priority 0 pipe
>> >         index 2 ref 1 bind 1
>> >
>> >filter protocol all pref 49152 flower chain 0
>> >filter protocol all pref 49152 flower chain 0 handle 0x1
>> >  dst_mac 00:04:9f:63:35:ea
>> >  not_in_hw
>> >        action order 1: vlan  push id 102 protocol 802.1Q priority 0 pipe
>> >         index 1 ref 1 bind 1
>> >
>> >My problem is that the VLAN tags are discarded by the network
>> >interface's RX filter:
>> >
>> ># ethtool -S eno2
>> >     SI VLAN nomatch u-cast discards: 1280
>> >
>> >and this is because nobody calls .ndo_vlan_rx_add_vid for these VLANs
>> >(only the 8021q driver does). This makes me think that I am using the
>> >tc-vlan driver incorrectly. What step am I missing?
>>
>> Hmm, that is a good point. Someone should add the vid to the filter. I
>> believe that "someone" should be the driver in case of flow_offload.
>>
>>
>>
>> >
>> >Thanks,
>> >-Vladimir
>
>This is not with flow_offload, this is a simple software filter.
>Somebody needs to add the VLAN of the _key_ to the RX filter of the
>interface.

Hmm, right. So the TC wants to manipulate with VLAN, it would make sense
for it to add the vlan to the filter.


>
>Thanks,
>-Vladimir