From: "Hervé 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
Date: Thu, 12 Jan 2023 17:22:34 +0100 [thread overview]
Message-ID: <Y8AzypbpgDOSzhz6@quaddy.sgn> (raw)
In-Reply-To: <47d9b00c664dbaabd8921a47257ffc3b7c5a1325.camel@redhat.com>
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 frame.
For devices that do not support VLAN offloading (such as dummy but also the network card I am using), the kernel adds the tag itself in software before transmitting the packet to the real device.
You can verify this with a capture using tcpdump/wireshark on dummy0 versus dummy0.832.
That's why dhclient has to send its packets over dummy0.832 and not dummy0.
The same will happen on a real device. I checked on real hardware, with two 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 second box receives a properly tagged frame.
Hervé
next prev parent reply other threads:[~2023-01-12 16:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 19:17 [PATCH net 1/2] net/af_packet: fix tx skb protocol on SOCK_PACKET sockets Hervé Boisse
2023-01-10 19:17 ` [PATCH net 2/2] net/af_packet: fix tx skb network header on SOCK_RAW sockets over VLAN device Hervé Boisse
2023-01-12 12:48 ` Paolo Abeni
2023-01-12 15:27 ` =?unknown-8bit?B?SGVydsOp?= Boisse
2023-01-12 15:47 ` Paolo Abeni
2023-01-12 16:22 ` Hervé Boisse [this message]
2023-01-12 18:38 ` Willem de Bruijn
2023-01-12 16:04 ` Willem de Bruijn
2023-01-12 15:48 ` [PATCH net 1/2] net/af_packet: fix tx skb protocol on SOCK_PACKET sockets Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8AzypbpgDOSzhz6@quaddy.sgn \
--to=admin@netgeek.ovh \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).