netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* packet_mmap, 802.1Q and bridges
@ 2013-07-29 16:53 Phil Sutter
  2013-07-31 17:27 ` Parse ethernet headers in af_packet.c Phil Sutter
  0 siblings, 1 reply; 14+ messages in thread
From: Phil Sutter @ 2013-07-29 16:53 UTC (permalink / raw)
  To: netdev; +Cc: Ben Greear, Stephen Hemminger, bridge, David S. Miller

Hello everyone,

I have found a situation where sending of VLAN tagged packets via
packet_mmap over a bridge creates MTU problems.

The setup is as follows:
- physical interface eth0 (mv643xx)
- bridge interface br0 contains just eth0
- packet_mmap sender bound to br0, socket() called with SOCK_RAW and
  ETH_P_ALL as arguments, PACKET_VERSION set to TPACKET_V2
- MTU is 1500 on all involved interfaces

When userspace sends a full frame, it will pass tpacket_snd which will
reject it unless there is a small patch of mine applied (for patch and
related discussion, see: http://patchwork.ozlabs.org/patch/67422/).
Tpacket_snd creates an SKB around the passed data, with 'protocol' field
set to whatever was specified at socket() stage (in this case,
ETH_P_ALL). Eventually, dev_queue_xmit() is called.

The SKB created in af_packet.c is passed to the bridge code, while the
interesting part is the function br_dev_queue_push_xmit() in
net/bridge/br_forward.c. This function checks the frame's length against
the device's MTU, therefore calling packet_length() which in turn does
look at the SKB's protocol field for whether to account for an
additional VLAN header or not. In this case, br_dev_queue_push_xmit()
will drop the frame since ETH_P_ALL != ETH_P_8021Q.

Using tcpdump, I could observe the packet occurs on br0, but not eth0.
Changing packet_length() to also subtract VLAN_HLEN if skb->protocol is
htons(ETH_P_ALL) fixed the problem.

While preparing this email, I read again the discussion referenced above
and found it surprisingly adequate for the problem described here. If I
am not mistaken, the consensus was whether we should parse the given
buffer in order to extract the real ethernet protocol or just account
for four extra bytes, regardless of the actual packet.

IMHO the problem described above is a strong argument for the first
option. There is code which depends on skb->protocol's content to be
correct, so af_packet should stick to it.

Comments are highly appreciated. In the meantime, I will have a look at
how to parse the packet_mmap buffer. If you got anything in that
direction already, please feel free to come forward.

Best wishes, Phil

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-08-02 21:59 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-29 16:53 packet_mmap, 802.1Q and bridges Phil Sutter
2013-07-31 17:27 ` Parse ethernet headers in af_packet.c Phil Sutter
2013-07-31 17:27   ` [PATCH 1/3] af_packet: when sending ethernet frames, parse header for skb->protocol Phil Sutter
2013-07-31 17:27     ` [PATCH 2/3] af_packet: fix for sending VLAN frames via packet_mmap Phil Sutter
2013-07-31 17:27       ` [PATCH 3/3] af_packet: simplify VLAN frame check in packet_snd Phil Sutter
2013-08-01  0:30     ` [PATCH 1/3] af_packet: when sending ethernet frames, parse header for skb->protocol David Miller
2013-08-01 10:35       ` Phil Sutter
2013-08-02  1:12         ` David Miller
2013-08-02  9:37           ` [PATCH v2 " Phil Sutter
2013-08-02  9:37             ` [PATCH v2 2/3] af_packet: fix for sending VLAN frames via packet_mmap Phil Sutter
2013-08-02  9:37               ` [PATCH v2 3/3] af_packet: simplify VLAN frame check in packet_snd Phil Sutter
2013-08-02 21:59                 ` David Miller
2013-08-02 21:58               ` [PATCH v2 2/3] af_packet: fix for sending VLAN frames via packet_mmap David Miller
2013-08-02 21:58             ` [PATCH v2 1/3] af_packet: when sending ethernet frames, parse header for skb->protocol David Miller

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).