On Oct 5, 2013, at 5:07 PM, abhinav narain <abhinavnarai...@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
