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