capture on The Official Wireshark Blog

Running Wireshark as You

Thu, 04 Feb 2010 20:11:57 +0000

Running Wireshark on Linux involves an interesting challenge¹: Capturing packets requires root access, but Wireshark is big program and we strongly recommend against running it with elevated privileges. On Linux it’s common to see Wireshark running as root, but this is nearly unheard for similarly-sized applications like Firefox and GIMP. How can we avoid running Wireshark as root?

UPDATE 2010-02-10: Made changes suggested by Jaap and Balint.

A good way 🔗

Notice how I said “capturing packets requires root” above? Here’s a secret — Wireshark doesn’t capture packets. A separate program called dumpcap does. Compared to Wireshark, dumpcap is tiny. It’s much less complex and much safer to run as root. We can make it so that dumpcap runs as root and that only users in a particular group can run it:

$ sudo -s
# groupadd -g wireshark
# usermod -a -G wireshark gerald
# chgrp wireshark /usr/bin/dumpcap
# chmod 4750 /usr/bin/dumpcap

A better way 🔗

It’s also possible to let dumpcap do its job without involving root access at all. For a very long time Linux has allowed the use of fine-grained permissions called capabilities. In many recent distributions you can use the setcap utility to add capabilities to individual files.

Dumpcap needs CAP_NET_RAW and CAP_NET_ADMIN, so what do we need to feed setcap? On my Ubuntu Karmic system the setcap man page points you to cap_from_text. Cap_from_text points you to _cap_names, an array in the kernel. It would be nice if the setcap man page included a list of capability names along with a few examples. As it turns out, the names need to be in lower-case.

$ sudo -s
# sudo apt-get install libcap2-bin
# groupadd -g wireshark
# usermod -a -G wireshark gerald
# chmod 750 /usr/bin/dumpcap
# setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

You can also set these capabilities for Wireshark and TShark directly. Fully-functional filesystem capabilities is something the Linux world has needed for a very long time. I’m glad they’re finally seeing wide deployment.

Who’s Doing This? 🔗

Debian and Gentoo are using group-based permissions for Wireshark. Ubuntu is working on it. Hopefully the other distributions will follow suit.

1. This is a problem on other systems too, but it’s usually easier to solve. On Windows you can run the NPF service at startup. On OS X you can use ChmodBPF.

Comments 🔗

Comment by Jake on 2010-02-08 05:45:00 +0000 🔗

Note that the recent Debian packages already implement this, something you’ll notice when installing them. Thanks Balint. For Ubuntu it’s still on Wishlist status.

Comment by Balint on 2010-02-10 04:11:39 +0000 🔗

Gerald,
Could you please suggest using the wireshark system group instead of packetcapture?
Gentoo and Debian already use wireshark group, and it would be easier for newcomers to use the same group name everywhere.

I plan to update the Debian packages to use setcap, thanks for the hint.

Comment by Gerald Combs on 2010-02-10 10:59:09 +0000 🔗

I changed the example group to “wireshark” and mentioned Gentoo, Debian, and Ubuntu.

Comment by Balint on 2010-02-17 10:28:51 +0000 🔗

It would also make sense to use groupadd -g -r wireshark instead of groupadd -g wireshark to make the new group a system group. That would match and nicely coexist with Debian’s and Ubuntu’s installation method.

Capture Filters and Offsets

Mon, 05 Oct 2009 13:03:53 +0000

A couple of questions have come up on the wireshark-users mailing list recently about using capture filters for MPLS and VLANs. Each user was having the same problem yet these are different network technologies — what do they have to do with each other?

The answer is offsets.

Let’s take an up-close and personal look at the capture filter “ip src host 10.16.32.48”. We can do this by running tcpdump -d, which takes a filter, compiles it, and dumps out the result. The dump of our filter looks like this:

(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 5
(002) ld       [26]
(003) jeq      #0xa102030       jt 4    jf 5
(004) ret      #96
(005) ret      #0

If this makes no sense don’t worry. You just need to know that the first two lines look for the IP ethertype (0x800) starting at byte 12 and the next two lines look for the IP address 10.16.32.48 (0xa102030) starting at byte 26. This is the minimum amount of checking required for that capture filter if you’re running IP over Ethernet.

What happens if you’re using 802.1q?

802.1q inserts an extra four bytes in front of the ethertype, so this filter won’t do what you want. The ethertype will be at offset 16 instead of 12, and the IP source address will be at offset 30 instead of 26. Libpcap and WinPcap don’t know you’re using .1q, and adding a check to the filter code would add a lot of unnecessary overhead. We have to add the word “vlan” to our filter to get the right offsets, e.g. “vlan and ip src host 10.16.32.48”:

(000) ldh      [12]
(001) jeq      #0x8100          jt 2    jf 7
(002) ldh      [16]
(003) jeq      #0x800           jt 4    jf 7
(004) ld       [30]
(005) jeq      #0xa102030       jt 6    jf 7
(006) ret      #96
(007) ret      #0

There’s a gotcha here, though. What if we change the “and” to an “or”?

(000) ldh      [12]
(001) jeq      #0x8100          jt 6    jf 2
(002) ldh      [16]
(003) jeq      #0x800           jt 4    jf 7
(004) ld       [30]
(005) jeq      #0xa102030       jt 6    jf 7
(006) ret      #96
(007) ret      #0

We’re looking for the IP address at byte 30. Shouldn’t we be looking at both 26 and 30?

The filter compiler uses a base offset for fetching data from the packet. Any time you use “vlan”, “mpls”, or “pppoes” in a capture filter, this offset is increased from that point on. It’s also cumulative. That is, while all of these filters are logically equivalent, they’re not in practice:

ip src host 10.16.32.48 or vlan or vlan (Looks for 10.16.32.48 at offset 26)

vlan or ip src host 10.16.32.48 or vlan (Now it’s looking at offset 30)

vlan or vlan or ip src host 10.16.32.48 (Offset 34. When will it ever end?)

“vlan” and “mpls” increase the base offset by 4. “pppoes” increases it by 8.

Missing Packets and Chimnies

Thu, 17 Sep 2009 00:33:43 +0000

You’ve just fired up Wireshark on your Windows Server 2003 or 2008 system and you’re not seeing nearly the amount of traffic you should. What’s happening?

The Windows Server 2003 Scalable Networking Pack introduced a feature called TCP Chimney Offload. Chimney offloading lets the OS networking stack hand off established TCP connections to the NIC for processing. This frees up the CPU, bus, and memory for other things and lets you scale up the number of connections you can handle. Hooray! Once the OS hands a connection off to the NIC, that traffic completely bypasses WinPcap and therefore doesn’t show up in Wireshark. You see the TCP connection setup and non-TCP traffic but no TCP data. Oops.

How do you fix the problem? It depends on your environment.

You can disable chimney offloading as described in KB 91222 (Server 2003) or KB 951037 (Server 2008). If you have a gigabit NIC you can probably get away with leaving it disabled. If you have a 10 gig NIC this might affect your performance. You can also SPAN or tap in and capture on an external machine, assuming you’re sufficiently equipped.