Tags: , ,
Posted by: peter

While I have been using Wireshark for many years (since back when it was still called ethereal) I only just discovered tshark which is the command line version. It’s a more modern replacement for tcpdump which has some very nice capabilities that make it worth learning for terminal based packet analysis, as well as a minimalist version called dumpcap which can be used for packet capture only.

In my case I want to capture traffic on a fairly busy gigabit interface in order to inspect a brief event that only happens randomly once every couple of days. I do have a separate SMS alarm that triggers when the event happens thanks to OpenNMS, but by the time I have received the alarm, logged into my packet capture machine and kicked off tcpdump it’s usually too late to capture anything useful. This is where the following usage of dumpcap’s inbuilt ring buffer mode comes in handy:

    dumpcap -n -a filesize:102400 -b files:4500 -w /tmp/capture/problem.pcapng

This command when run in the background using “screen” will continuously capture data from the network, storing it in 4500 automatically rotated, time stamped files of 100MB each. This means that I always have the last 450GB of network traffic available to analyse without ever filling up the 500GB disk in my capture machine which should allow me to solve the problem next time it occurs!

Posted by: peter

I recently had to setup some openSUSE Linux boxes which will be used to capture add-hoc network traffic for debugging purposes. As there will be multiple users with the need to do this, I wanted to allow the use of tcpdump by non-root users. This is fairly straight forward to accomplish using file system capabilities, but as it’s not clearly documented anywhere else here is what I came up with:

  1. First install tcpdump and libcap-progs:

    zypper install tcpdump libcap-progs
  2. Then create a dedicated group called pcap for users who should be able to run tcpdump and add your user to it:

    groupadd pcap
    usermod -a -G pcap peter
  3. Modify the group ownership and permissions of the tcpdump binary so that only users in the pcap group can run it:

    chgrp pcap /usr/sbin/tcpdump
    chmod 750 /usr/sbin/tcpdump
  4. Set the CAP_NET_RAW and CAP_NET_ADMIN capabilities on the tcpdump binary to allow it to run without root access (These options allow raw packet captures and network interface manipulation):

    setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
  5. Optionally, check that the permissions are correct:

    # ls -l /usr/sbin/tcpdump
    -rwxr-x--- 1 root pcap 770776 Feb 19  2011 /usr/sbin/tcpdump
    # getcap /usr/sbin/tcpdump
    /usr/sbin/tcpdump = cap_net_admin,cap_net_raw+eip
  6. Optionally, symlink the tcpdump binary to a directory that is in the path for a normal user:

    ln -s /usr/sbin/tcpdump /usr/local/bin/tcpdump
  7. Optionally, configure the SuSEconfig permissions module so that it wont reset the file permissions next time you run it by adding the following to the bottom of /etc/permissions.local

    /usr/sbin/tcpdump             root:pcap       0750
     +capabilities cap_net_admin,cap_net_raw+eip
  8. Inform that Linux kernel that it should enable file system capabilities at boot by adding the following option to the kernel line in /boot/grub/menu.lst:

  9. Reboot to enable file system capabilities

Posted by: peter
When doing embedded network development, its typical that you have the embedded device you work on connected to one network interface (eth1) while you are simultaneously connected to your corporate or home LAN and the internet via another interface (eth0 or wlan0).

The thing about embedded development is that you spend a lot of time rebooting the embedded device with new firmware which sends your PC’s network interface down and up which triggers a new DHCP request on that interface, which then proceeds to time out (often there is no DHCP server on the embedded device) before you have to manually assign the same static IP that you were using on the interface a few seconds before.

As it turns out there is a way to tell NetworkManager to keep its mitts off of a particular interface. Firstly, find the udi of the interface with the ‘lshal’ command. eg:

udi = ‘/org/freedesktop/Hal/devices/net_00_05_1b_ac_6c_03’
info.capabilities = {‘net’, ‘net.80203’, ‘wake_on_lan’} (string list)
info.category = ‘net.80203’ (string)
info.interfaces = {‘org.freedesktop.Hal.Device.WakeOnLan’} (string list)
info.parent = ‘/org/freedesktop/Hal/devices/usb_device_7a6_8515_0001_if0’ (string)
info.product = ‘Networking Interface’ (string)
info.subsystem = ‘net’ (string)
info.udi = ‘/org/freedesktop/Hal/devices/net_00_05_1b_ac_6c_03’ (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = ‘net’ (string)
linux.sysfs_path = ‘/sys/devices/pci0000:00/0000:00:1d.7/usb7/7-1/7-1.6/7-1.6:1.0/net/eth1’ (string)
net.80203.mac_address = 21939121155 (0x51bac6c03) (uint64)
net.address = ‘00:05:1b:ac:6c:03’ (string)
net.arp_proto_hw_id = 1 (0x1) (int)
net.interface = ‘eth1’ (string)
net.linux.ifindex = 5 (0x5) (int)
net.originating_device = ‘/org/freedesktop/Hal/devices/usb_device_7a6_8515_0001_if0’ (string)
org.freedesktop.Hal.Device.WakeOnLan.method_argnames = {”, ”, ‘enable’} (string list)
org.freedesktop.Hal.Device.WakeOnLan.method_execpaths = {‘hal-system-wol-supported’, ‘hal-system-wol-enabled’, ‘hal-system-wol-enable’} (string list)
org.freedesktop.Hal.Device.WakeOnLan.method_names = {‘GetSupported’, ‘GetEnabled’, ‘SetEnabled’} (string list)
org.freedesktop.Hal.Device.WakeOnLan.method_signatures = {”, ”, ‘b’} (string list)

Then add this udi as an un-managed device to the [keyfile] section of ‘/etc/NetworkManager/nm-system-settings.conf’. eg:


It should take effect immediately, and you shouldn’t even need to restart NetworkManager.

Note: Thanks to tambeti on #opensuse-gnome for the tip.