--- Begin Message ---
On Oct 23, 2019, at 1:43 AM, Anders Broman <anders.bro...@ericsson.com> wrote:

> On Oct 23, 2019, at 12:26 AM, Anders Broman <anders.bro...@ericsson.com> 
> wrote:
> 
>>> El mar., 22 oct. 2019 a las 15:08, Guy Harris (<ghar...@sonic.net>) 
>>> escribió:
>>>> 
>>>>> Does it allow receiving copies of packets that are also handed either to 
>>>>> the kernel networking stack or to other AF_XDP sockets for regular input 
>>>>> processing? That would be needed to allow it to be used for packet 
>>>>> sniffing.
>>>> 
>>>> I haven't looked into it yet, but I'll keep that in mind when I do.
>>> 
>>> Is that needed for an interface used ONLY for sniffing? E.g connected to a 
>>> span/mirror port or a tap? One of the interesting features here is packet 
>>> filtering on the NIC.
>> 
>> No, but there's no API in libpcap to indicate that the code is using it for 
>> passive sniffing on an interface used only for sniffing rather than for 
>> active sniffing of the traffic on a live interface, so if AF_XDP works only 
>> for passive sniffing >there's no way to know whether it can be used or not.
> 
> Isn't this very similar to WiFi monitor mode?

Wi-Fi monitor mode isn't necessarily passive sniffing on an interface used only 
for sniffing - at least some OSes and drivers allow interfaces to be in monitor 
mode while the interface is still associated with a network.  (I just did 
"tcpdump -I" on my MacBook Pro's Broadcom BCM43xx-based Wi-Fi adapter in one 
window, and "ping my.isp.net" in another window, on Mojave, and it worked.)

So it's not similar in that sense.

> How is that handled? Perhaps new libpcap API are needed for AF_XDP.

If there are two capture mechanisms, with one of them giving higher performance 
but not allowing the adapter to run as a regular network interface, then there 
would need to be an API in libpcap to allow that mechanism to be used - and 
there would need to be UI in programs using libpcap to allow that to be 
requested.

It's not yet determined whether AF_XDP does that.

> An API for dedicated capture interface might be useful for other stuff to 
> like CPU pinning, setting up the
> Interface for sniffing programmatically trough ethtool(Offloading, etc).

By "Offloading" do you mean *disabling* offloading?  That's something that 
might be used if you're *not* doing passive sniffing, if you want to see what 
the machine is sending on the wire.  (No, that won't handle the case where the 
offloading is the source of the problem, i.e. where disabling offloading makes 
the problem go away, but for *that* you'll need a network tap and either 
another machine or another adapter on your machine.)

--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to