Re: Different/Same queue used for promiscuous capture on ethernet ?

[Guy Harris <guy () alum mit edu>]

On Oct 5, 2013, at 5:07 PM, abhinav narain <abhinavnarain10 () gmail com> wrote:

> Okay, thats what I expected. The drops shown by pcap_t handle refer to the drop from this buffer. 
> This will depend on how fast is the userland binary processing the frames from this buffer.

Yes.

> What about kernel buffer ? How do I know if I actually dropped the frame because I ran out of memory on the device 
> (if at all ?).

Those drops are probably due to the driver's receive ring filling up; whether the driver reports that, and how it 
reports that, is a function of the driver and possibly the driver framework into which it plugs.

> I am sniffing on 'br-lan' interface. Its a bridged interface for all the lan port.

So you're *not* capturing on "eth0", you're capturing on "br-lan"?

The diagram at

        http://wiki.openwrt.org/toh/netgear/wndr3700#switch.ports.for.vlans

doesn't seem to show any switch ports other than Port 5 being attached to the "Device CPU"; as far as I know, the 
"Device CPU" is what's running Linux, so I don't see it being able to bridge anything other than the interfaces shown 
as being attached to the device CPU, namely port 5 on the switch (which is not *any* of the external Ethernet LAN 
ports!), the external WAN port, and the two 802.11 adapters.

Now, maybe the VLAN configuration causes the router to act like something other than an access point with one LAN port 
(eth0), one WAN port (eth1), and two 802.11 radios (i.e., the Device CPU), with the LAN port plugged into a 4-port 
switch (the Realtek switch, with one port ignored)

> It is not in promiscuous mode. 
>  
> > If so, do you see as many packets dropped if you *don't* capture in promiscuous mode?
> Can you explain why will this happen ?

If packets are arriving on one of the Ethernet ports of the device CPU that are not:

        broadcast packets;

        multicast packets that the Ethernet port in question accepts;

        unicast packets sent to that port's MAC address;

then:

        when not in promiscuous mode, those packets will be discarded by the Ethernet hardware and therefore they will 
not be added to the device's receive ring or to the PF_PACKET socket's queue;

        when in promiscuous mode, those packets will be received into the device's receive ring and, if they pass 
whatever packet filter is on the PF_PACKET socket, *will* be added to its queue;

so there will be more traffic seen in promiscuous mode and therefore a greater chance that packets will be dropped.

> My question was if the packets drop in promiscuous mode will actually cause packets to be dropped for other 
> applications (file upload in some application on browser, for eg) ?

Possibly, in the case where there are packets that would be discarded by the hardware when not in promiscuous mode and 
not discarded by the hardware in promiscuous mode.

> or the queue for the promiscuous mode socket will be separate which will just cause packets which are being processed 
> by pcap application to be dropped and not affect tcp timeouts to the other flow.

There's more than one queue involved - there's the socket queue (which shouldn't affect other sockets), and there's the 
device's receive ring (through which packets for *all* sockets must pass).  If going into promiscuous mode increases 
the number of packets that the interface accepts, the receive ring might fill up faster.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers