netdev - Re: Problem with queuing vlan tagged packets after migration from 3.16.0 to 4.9.0

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: <0498cc65-fd90-034a-2a23-9b2fdc3ef3c0@gmail.com>
Date:   Thu, 3 Jan 2019 16:25:58 +0100
From:   Bartek Kois <bartek.kois@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Problem with queuing vlan tagged packets after migration from
 3.16.0 to 4.9.0

Hi
1. What exactly caused this change in the kernel?
2. I don`t understand why adding VLAN tag, which is just 4  additional 
bytes to the passing packet make it impossible to classify.
3. This whole thing makes the QoS under Linux routers hard to configure 
in scenarios with more than one VLAN which is pretty much every slightly 
bigger router nowadays especially if we use IFB and hashing filters. Is 
there any walkaround for that problem?

Best regards
Bartek Kois

W dniu 03.01.2019 o 04:30, Cong Wang pisze:
> On Tue, Jan 1, 2019 at 11:46 AM Bartek Kois <bartek.kois@...il.com> wrote:
>> Hi
>> Yes it did work since I remember (like around 2.4.x) and it changed
>> since I moved from Debian 8 to 9. I would appreciate fixing that in the
>> future beacuse it is essential for queueing traffic on the routers, but
>> the question is why these filters don`t work in that case:
>>
>>       tc filter add dev $LAN_ETH parent 1:0 protocol ip prio 4 u32 match
>> u32 0x0a000c08 0xffffffff at 20 classid 1:2001      # for 10.0.12.8 ip
>> address
>>       tc filter add dev $LAN_ETH parent 1:0 protocol ip prio 4 u32 match
>> u32 0x0a000c09 0xffffffff at 20 classid 1:2002      # for 10.0.12.9 ip
>> address
>>       tc filter add dev $LAN_ETH parent 1:0 protocol ip prio 4 u32 match
>> u32 0x0a000c10 0xffffffff at 20 classid 1:2003      # for 10.0.12.10 ip
>> address
>>
>> I`ve changed "at 16" which works without vlan tags to "at 20" to take
>> vlan tag into account.
> Yeah, this confirms my speculation.
>
> The problem is essentially a design flaw of u32 filter, the IP header
> and TCP header offsets are never fixed, for example VLAN tagging and
> IP options. What's more, it is not easy for user-space to learn the offset
> for different packets as it requires to parse into each packets.
>
> I don't know whether we can fix this either, VLAN call path probably
> already makes assumptions on the current skb->data position, if
> we "fix" it for u32, it would probably break other things.