Modify

Opened 8 years ago

Closed 6 years ago

Last modified 4 years ago

#6845 closed defect (worksforme)

tcpdump dropping packets

Reported by: vinodkone@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Kamikaze 8.09
Keywords: Cc:

Description

I am currently checking the sniffing capacity of a Cambria box (http://www.gateworks.com/products/cambria/gw2358-4.php) which runs OpenWrt (Kamikaze - 8.09.2).

I am testing whether a wireless node put into monitor mode can capture all the traffic going on in the network.

To test this, I set up 2 wireless nodes (not Cambria) running 802.11a on an isolated channel (56) and communicating at UDP traffic at 54 Mbps. Nearby these 2 nodes, I have my Cambria node with a wireless interface on monitor mode on the same channel. I run tcpdump (installed from opkg) on this monitor interface to see how many packets it can capture and how many it drops.

$> tcpdump -i ath0 -s 1 -qtn > /dev/null

Here is a sample output of tcpdump on the Cambria node:


1850 packets captured
334269 packets received by filter
332419 packets dropped by kernel


Clearly, it is dropping a hell lot of packets even though I'm not parsing packet headers and not writing to disk. I am not sure if this is an issue with tcpdump (some filter? I didn't setup any filter as far as i know..firewall?) or the processing capability of Cambria node (660 MHz processor)? or small kernel buffer size? or something else. I am not running any other heavy processes on the Cambria node, as far as i can tell.

Can some one tell me what the problem is and hopefully how to solve this?

Thanks,
Vinod

Attachments (2)

Makefile (2.0 KB) - added by Gus Wirth <gwirth79@…> 7 years ago.
Makefile for Wireshark's dumpcap
Makefile.2 (2.0 KB) - added by msio57@… 5 years ago.
Dumpcap and editcap version 1.8.3

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 years ago by Gus Wirth <gwirth79@…>

There is a serious problem with either tcpdump itself or more likely libpcap. Running tcpdump against a wireless interface causes 100% CPU load when dumping only a few packets. Trying to dump a continuous stream is impossible.

For example, on a Ubiquiti RouterStation (ar71xx) I do the following:

First I set up a monitor VAP for madwifi (regular wireless is disabled):

# wlanconfig mon0 create wlandev wifi0 wlanmode monitor
# iwconfig mon0 chan 11
# ifconfig mon0 up

Then I run:

# tcpdump -i mon0 -w /dev/null &

# top

I use the serial port so as not to interfere with the ethernet port. With only a few packets the CPU load for tcpdump goes to almost 100% with most of the time being spent in System.

I think the next step would be to try something like kismet_drone to test whether the problem is in tcpdump or libpcap, since kismet uses libpcap but not tcpdump. I'll see if I can set up an experiment in the next few days.

The test system is running r19033 with kernel 2.6.30.10 and has an Atheros AR5414 card in it.

comment:2 Changed 8 years ago by Gus Wirth <gwirth79@…>

The problem is most likely with tcpdump and not libpcap.

I set up a kismet drone on the RouterStation and captured all packets on the monitor interface. I got at most about 3% CPU usage and it just chugged along. Although it uses a bit of memory (about 10%) this could be an alternative to tcpdump until it gets fixed.

Now to figure out why tcpdump is broken.

comment:3 Changed 8 years ago by Gus Wirth <gwirth79@…>

I did some more testing and ran tcpdump with strace to see if I could find where it was stalling out. Perhaps not so surprising, tcpdump works fine while running under strace. For example, doing this:

# strace tcpdump -i mon0 -w /dev/null

lets tcpdump run just fine, and it barely slows it down. Its CPU usage is much lower when running under strace.

I did note that with a good connection, 20Mbps throughput caused significant packet loss. It seems that tcpdump is trying to use filters even when just writing everything to a file, which causes the slowdown.

comment:4 Changed 8 years ago by mstombs

Is

"On some systems, increasing the default size of receive socket buffers also helps:
echo 4194304 > /proc/sys/net/core/rmem_max; echo 4194304 > /proc/sys/net/core/rmem_default"

from

http://staff.washington.edu/corey/gulp/

any use? These values overkill, but fix a similar pcap issue with darkstat for me

comment:5 Changed 7 years ago by Gus Wirth <gwirth79@…>

This still isn't fixed as of r22630. However, I did come up with an alternative to tcpdump called dumpcap, which is part of Wireshark. I posted on the forum:

https://forum.openwrt.org/viewtopic.php?id=26204

I've attached the Makefile so you can build it.

Since dumpcap also relies on libpcap to do its work, and it runs just fine, the problem lies in tcpdump itself. dumpcap runs with only about 3-8% CPU overhead at 6Mbps on the wireless interface.

Changed 7 years ago by Gus Wirth <gwirth79@…>

Makefile for Wireshark's dumpcap

comment:6 Changed 6 years ago by nbd

  • Resolution set to worksforme
  • Status changed from new to closed

Changed 5 years ago by msio57@…

Dumpcap and editcap version 1.8.3

comment:7 Changed 5 years ago by anonymous

I've attached new Makefile - Wireshark 1.8.3.

comment:8 Changed 5 years ago by anonymous

it works
tcpdump -n -i eth0 -vv -s 64000 > /var/log/1.cap

hilmy

comment:9 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.