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;
Message-ID: <47d9b00c664dbaabd8921a47257ffc3b7c5a1325.camel@redhat.com>
Subject: Re: [PATCH net 2/2] net/af_packet: fix tx skb network header on
 SOCK_RAW sockets over VLAN device
From:   Paolo Abeni <pabeni@redhat.com>
To:     =?ISO-8859-1?Q?Herv=E9?= Boisse <admin@netgeek.ovh>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Thu, 12 Jan 2023 16:47:38 +0100
In-Reply-To: <Y8Am5wAxC48N12PE@quaddy.sgn>
References: <20230110191725.22675-1-admin@netgeek.ovh>
         <20230110191725.22675-2-admin@netgeek.ovh>
         <fa5895ae62e0f9c1eb8f662295ca920d1da7e88f.camel@redhat.com>
         <Y8Am5wAxC48N12PE@quaddy.sgn>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 2023-01-12 at 16:27 +0100, Hervé Boisse wrote:
> 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.

I understand, thanks. Still is not clear why the user-space application
would attach to dummy0.832 instead of dummy0.

With your patch the filter will match, but the dhcp packet will reach
the wire untagged, so the app will behave exactly as it would do
if/when attached to dummy0.

To me it looks like the dhcp client has a bad configuration (wrong
interface) and these patches address the issue in the wrong place
(inside the kernel).

Cheers,

Paolo