Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 12 Jan 2023 16:27:35 +0100
From:   =?unknown-8bit?B?SGVydsOp?= Boisse <admin@netgeek.ovh>
To:     Paolo Abeni <pabeni@redhat.com>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>, admin@netgeek.ovh,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 2/2] net/af_packet: fix tx skb network header on
 SOCK_RAW sockets over VLAN device
Message-ID: <Y8Am5wAxC48N12PE@quaddy.sgn>
References: <20230110191725.22675-1-admin@netgeek.ovh>
 <20230110191725.22675-2-admin@netgeek.ovh>
 <fa5895ae62e0f9c1eb8f662295ca920d1da7e88f.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fa5895ae62e0f9c1eb8f662295ca920d1da7e88f.camel@redhat.com>
Precedence: bulk


Hello,

On Thu, Jan 12, 2023 at 01:48:51PM +0100, Paolo Abeni wrote:
> I'm unsure I read correctly the use case: teh user-space application is
> providing an L2 header and is expecting the Linux stack to add a vlan
> tag? Or the linux application is sending packets on top of a vlan
> device and desire no tag on the egress packet? or something else?

The userland app does not care about the device being a VLAN one or not. Just a regular Ethernet device on which to send raw frames.
This means the app provides a standard 14 byte Ethernet header on the socket and does not matter about any VLAN tag.

Then, the goal is to be able to alter those packets at the qdisc level with tc filters.
But, when such packets are sent on top of a VLAN device whose real device does not support VLAN tx offloading, the bad position of the skb network header makes this task impossible.

To give a concrete example, here are few commands to show the problem easily:

# modprobe dummy
# ip link add link dummy0 dummy0.832 type vlan id 832
# tc qdisc replace dev dummy0.832 root handle 1: prio
# tc filter del dev dummy0.832
# tc filter add dev dummy0.832 parent 1: prio 1 protocol ip u32 match u8 0 0 action pedit pedit munge ip tos set 0xc0
# ip link set dummy0 up
# ip link set dummy0.832 up

Then start an application that uses AF_PACKET+SOCK_RAW sockets over the VLAN device:

# dhclient -v dummy0.832

If you look at the emitted packets on dummy0, you will see that the 0xc0 byte of the IPv4 TOS/DSCP field is not set.
Instead, the 0xc0 tos byte is written 4 bytes too far, in the last byte of the IPv4 Identification field.


Hervé