[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53CE69A4.4040601@ng4t.com>
Date: Tue, 22 Jul 2014 15:39:48 +0200
From: Mihail Dakov <mihail.dakov@...t.com>
To: Willem de Bruijn <willemb@...gle.com>
CC: Daniel Borkmann <dborkman@...hat.com>, netdev@...r.kernel.org
Subject: Re: AF_PACKET: tx_ring mirrored in rx_ring?
On 07/22/2014 12:35 AM, Willem de Bruijn wrote:
>>>> What'd you mean by local traffic? The packets which are replicated are
>>>> destined to remote machine(s).
>>>
>>> Sure, but you are sending them out via your packet socket.
>>
>> Well yes. It's just that I interpreted local as if they were not going out
>> of the machine. But in fact they do.
> That is a semantic issue. The technical point is that packet
> sockets read not only incoming packets, but also outgoing
> ones. The tap in the egress path (dev_queue_xmit_nit) is taken
> for almost all transmitted packets, included those transmitted
> by a packet socket.
>
> There is logic to avoid looping outgoing packets back into the
> originating socket (and fanout group) by detecting the source
> socket (skb_loop_sk). Other packet sockets will receive the
> outgoing packets, however. This is correct behavior, as it is
> how tcpdump can log all traffic, among others.
>
> You can use PACKET_QDISC_BYPASS on your transmit
> packet socket, as Daniel mentions, or attach a BPF filter to
> your receive socket that filters on !PACKET_OUTGOING, e.g.,:
>
> struct sock_filter bpf_filter[] = {
> {BPF_LD | BPF_B | BPF_ABS, 0, 0, (uint32_t) (SKF_AD_OFF + SKF_AD_PKTTYPE)},
> {BPF_JMP | BPF_JEQ, 1, 0, PACKET_OUTGOING},
> {BPF_RET, 0, 0, 0x00000000},
> {BPF_RET, 0, 0, 0x0000ffff},
> };
> struct sock_fprog bpf_prog;
>
> bpf_prog.filter = bpf_filter;
> bpf_prog.len = sizeof(bpf_filter) / sizeof(struct sock_filter);
> if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &bpf_prog,
> sizeof(bpf_prog))) {
> error(1, errno, "setsockopt filter");
> }
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists