Hi Guy,

I infer from "eth0" that this is Linux.  (DD-WRT or some other
> OpenWRT-based project?)
>
> Yes. OpenWrt based netgear router.


> On Linux, libpcap creates a PF_PACKET socket for each open pcap_t for a
> regular network interface such as eth0.  Each PF_PACKET socket has a queue
> of its own, regardless of promiscuous mode.
>
> 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.

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 ?).

What queueing the *driver* for the adapter does depends on the driver.
>
> > I am asking above question because I want to know if the router starts
> > dropping packets destined to itself because of this promiscuous mode
> > capture?
>
>         ...
>
> > Router used :
> > http://support.netgear.com/product/WNDR3700v2
>
> Do you have more than one machine plugged into the LAN ports of the router?
>
> According to
>
>         http://wiki.openwrt.org/toh/netgear/wndr3700#interfaces
>
> eth0 is for the "LAN ports (1 to 4)" and, according to
>
>
> http://wiki.openwrt.org/toh/netgear/wndr3700#switch.ports.for.vlans
>
> eth0 is port 5 on a Realtek RTL8366s:
>
>
> http://realtek.info/pdf/rtl8366s_8366sr_datasheet_vpre-1.4_20071022.pdf
>
> switch chip.
>
> I am sniffing on 'br-lan' interface. Its a bridged interface for all the
lan port.
This is because if I have packets going on wlan interface I can capture
them.
I don't think it captures packet to and from the lan ports 1-4.

If eth0 is not in promiscuous mode, I would assume that only traffic going
> between machines on the Ethernet LAN and machines on the 802.11 WLAN would
> arrive on eth0, not traffic between two machines on the Ethernet LAN.  I
> don't know whether the eth0 port can be put into a port mirroring mode
> where traffic on all the Ethernet LAN ports can be sent to the eth0 port
> or, if it can, whether the driver does so if eth0 is put into promiscuous
> mode, so that it sees all traffic through the switch, not just traffic to
> be sent to the WLAN.
>
> If it *is* put into mirroring mode, and you have a significant amount of
> traffic going between Ethernet LAN hosts, then promiscuous mode would
> significantly increase the number of packets received.
>
> If it's *not* put into mirroring mode, promiscuous mode shouldn't make any
> difference.
>
> It is not put in mirroring mode (atleast explicitly in the c code).
It only sees traffic going in and out to the WLAN port.


> Are you capturing in promiscuous mode?

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 ?

The packet drops given by pcap_t is packets dropped by the queue
corresponding to socket on which pcap is reading data.

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) ? 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.

I have not seen packet drops(I don't set the device in promiscuous), but I
want to know in which case they might be dropped (if at all) since the
processor is very beefy and I don't expect them to be dropped !

By the way, according to
>
>         http://www.dd-wrt.com/wiki/index.php/Netgear_WNDR3700
>
> the v2 model has a Atheros AR7161 680 MHz processor; the only model they
> list with a 480 MHz processor is the v3 model, with a Broadcom BCM4718A
> 480MHz processor.


It shows 680 MHz in dmesg log. I said 480 MHz as I read cat /proc/cpuinfo
(which reports 450.12 MIPS to be precise).

Thanks,
Abhinav
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to