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;
MIME-Version: 1.0
References: <20230110191725.22675-1-admin@netgeek.ovh> <20230110191725.22675-2-admin@netgeek.ovh>
 <fa5895ae62e0f9c1eb8f662295ca920d1da7e88f.camel@redhat.com>
 <Y8Am5wAxC48N12PE@quaddy.sgn> <47d9b00c664dbaabd8921a47257ffc3b7c5a1325.camel@redhat.com>
 <Y8AzypbpgDOSzhz6@quaddy.sgn>
In-Reply-To: <Y8AzypbpgDOSzhz6@quaddy.sgn>
From:   Willem de Bruijn <willemb@google.com>
Date:   Thu, 12 Jan 2023 13:38:46 -0500
Message-ID: <CA+FuTSezPJijavANb8879T4eDAP4_53eCUgULhsC2ArW4+Xn0w@mail.gmail.com>
Subject: Re: [PATCH net 2/2] net/af_packet: fix tx skb network header on
 SOCK_RAW sockets over VLAN device
To:     =?UTF-8?Q?Herv=C3=A9_Boisse?= <admin@netgeek.ovh>
Cc:     Paolo Abeni <pabeni@redhat.com>,
        "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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Jan 12, 2023 at 11:25 AM Herv=C3=A9 Boisse <admin@netgeek.ovh> wrot=
e:
>
> On Thu, Jan 12, 2023 at 04:47:38PM +0100, Paolo Abeni wrote:
> > 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).
>
> No, the packet will actually reach the wire as a properly tagged 802.1Q f=
rame.
> For devices that do not support VLAN offloading (such as dummy but also t=
he network card I am using), the kernel adds the tag itself in software bef=
ore transmitting the packet to the real device.
>
> You can verify this with a capture using tcpdump/wireshark on dummy0 vers=
us dummy0.832.
> That's why dhclient has to send its packets over dummy0.832 and not dummy=
0.
>
> The same will happen on a real device. I checked on real hardware, with t=
wo boxes and their network cards connected through a cable.
> If dhclient is started directly on the first box real device (eth0), the =
frame is received untagged by the second box, as intended.
> But, if dhclient is started on top of the VLAN device (eth0.832), the sec=
ond box receives a properly tagged frame.

SOCK_DGRAM writing the tag and SOCK_RAW not writing it is inconsistent.

The driver clearly anticipates SOCK_RAW writers that write only
Ethernet, and fixes up the difference in its ndo_start_xmit:

    /* Handle non-VLAN frames if they are sent to us, for example by DHCP.

That workaround only comes too late for code between dev_queue_xmit
and ndo_start_xmit: tc filters.

Strictly, dhclient is just not writing the right link layer, as
advertised by this device in dev->hard_header_len and
vlan_dev_hard_header. But being pedantic won't make the application
work (I assume it never has).

Perhaps the device can have an optional mode where it does present as
a pure Ethernet device, and handles all the VLAN insertion purely in
the driver code in ndo_start_xmit?