Wireshark version 1.8 has a great new feature that allows data to be captured from multiple interfaces at the same time. Since this wasn’t possible in previous versions the only option was to run multiple copies of Wireshark and then merge the captures using Mergecap. Merging captures can be time consuming so I’m really happy to see that Wireshark can now do the heavy lifting for me.
How to do it
To capture on multiple interfaces at the same time you simply need to open the capture interfaces window (CTRL+I), then click the checkboxes next to each interface you want to capture from. After selecting all of the interfaces just click start capture as you normally would.
When is this feature useful?
There are many troubleshooting situations where this feature can be very useful. Here are a few ways you can take advantage of this feature.
- Capture traffic from both the LAN and WAN interfaces of a router at the same time.
- Sniff packets from a wireless and wired network at the same time.
- Capture from multiple span ports or taps simultaneously (Client / Server).
- Your not sure which interface the packets are traversing (iSCSI Multipathing).
Reducing dropped packets
Capturing from multiple interfaces at the same time can cause packets to be dropped during the capture if the machine can’t sustain the increased traffic rate. There are a few settings that can be tweaked to reduce the number of drops that may occur.
Limit the size of the packets being captured
For most troubleshooting tasks it’s not important to see the payload of the packet, usually what I’m looking for is in the headers. Instructing Wireshark to capture the first 100 bytes of a packet helps keep the capture buffer from becoming full.
Packet capture length must be set for each individual interface. To access these settings open the capture options (CTRL+K), then double click on the interface to open the settings screen below. Enable the checkbox ‘Limit each packet to’, and set the length to 100 bytes, or however many bytes you need to see.
Increase the capture buffer size
By default Wireshark uses a buffer size of 1MB. Sometimes this isn’t large enough to keep up with large amounts of network traffic. If you’re seeing drops during a capture session you may need to increase the buffer size. I usually increase the buffer size in small increments until the drops disappear, making the buffer too large can cause issues.
This setting is also found in the interface settings (screenshot above).
Other advice
Wireshark (especially on Windows) can only handle so many packets per second before things fall apart. Sometimes it’s best to use another program to capture the packets and then load them into Wireshark for offline analysis. Gulp is an excellent open source program for Linux designed for lossless packet captures at gigabit speeds. Its also capable of handing 10-gigabit captures without drops depending on conditions.
The hardware of the system running the capture has a big impact on the success or failure of a capture as well.
I love me some Wireshark!
Just a quick question to see if you’ve run into this and solved it.
I built a passive tap and bought a dual gigabit card for my laptop. Using the ability to capture two interfaces at the same time is great. However, how do I get the packets in chronologcal order and saved in that order? Wireshark reports segments acknowledged that were unseen because they occur later due to the way it is reading them in. Quite often a group of ACK packets will get grouped later in the capture and some will appear before the actual packet the are ACKing.
I can sort the display but I can’t get the packets exported or saved in the order they are displayed so they will be in the proper order to read back in.
Hey Gary,
You might be running into a limitation of the hardware you are using to run your captures. The packets don’t get time stamped until they are received by the kernel. If there is a bottle neck in the bus, or nic buffers then you’ll see some out of order time stamps. High end dedicated capture cards can do time stamps in hardware which avoids these limitations.
You’ll probably get better results using a desktop with a couple of PCIe network cards installed. Or if you have access to a switch that supports span, or monitor ports you could connect both tap outputs to the switch then span both ports to a single cable going to your capture host.
You can also get much better performance if you run the captures under Linux. Windows can’t handle near as many packets / second as Linux can, especially if you use a program such as Gulp. Under Linux you can bond multiple interfaces together into a single logical interface to capture from.
There’s a few useful tips in the white paper called Best Practices in Gigabit Capture that you might find useful.