tcpdump mailing list archives
Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value
From: Daniel Borkmann <dborkman () redhat com>
Date: Fri, 11 Jan 2013 09:46:19 +0100
On 01/11/2013 03:37 AM, Paul Pearce wrote:
My opinion as a kernel developer is that the network tap is here to have a copy of the exact frame given to the _device_.
Agreed.
Good: as someone who spends lots of time with tcpdump doing both network and protocol diagnostics, it's really important to see exactly there. If that means turning off some hardware offload in order to get the intact 1p header, then that may be fine for many situations. (At 10G, on a live router... well...)I agree as well. But I think Ani's point was that for RX packets, as of commit bcc6d47903612c3861201cc3a866fb604f26b8b2, the filters are not getting exactly what's "on the wire." Independent of hardware acceleration the vlan headers are being stripped off and skb->vlan_tci is being set. That's was the origin of this whole mess. The msg from that commit reads in part:Vlan untagging happens early in __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers) see the skb like it was untagged by hw.His confusion (which I share) is why it's acceptable to have this behavior of removing headers and setting skb->vlan_tci (regardless of hardware acceleration) on the RX path but not also set skb->vlan_tci on the TX path. Indepdent of proposed userspace or PACKET_AUXDATA solutions, clarification on the RX skb->vlan_tci behavior would be appreciated. My knowledge of this code is quite limited so it's entirely possible I'm off base here. If so please tell me.
While we're at the topic, though it's slightly unrelated this particular problem, but related to capturing VLANs and ``what's seen on the wire'', since it was mentioned. For different NICs/drivers you might get different default behaviours, and mostly it's the case (I assume, correct me if I'm wrong) that libpcap has to ``un-untag'' the VLAN headers in user space, doing a memmove(3) for each stripped VLAN packet in order to ``fix'' this. Because of this hack, I even got a report of a user recently, that in Wireshark, he saw a QinQ header, although it should just have been one VLAN encapsulation (AR8131 driver with ethtool -K eth0 rxvlan off) as he saw with netsniff-ng (no memmove(3) done there). (I didn't further follow or verify this report though.) _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Ani Sinha (Jan 08)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Ani Sinha (Jan 09)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Eric Dumazet (Jan 09)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Ani Sinha (Jan 09)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Ani Sinha (Jan 09)
- Message not available
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Paul Pearce (Jan 10)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Daniel Borkmann (Jan 11)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Eric W. Biederman (Feb 15)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Eric Dumazet (Jan 09)
- Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value Ani Sinha (Jan 09)