Ask Your Question

# Revision history [back]

Without further information, I'm going to assume that you're working with a Microsoft Network Monitor cap file, and in that case, you may want to refer to this question. I believe it's still applicable, and I've verified it with at least 1 capture file, NetMon34.cap, from the Wireshark menagerie and Wireshark master, specifically Version 2.9.1 (v2.9.1rc0-634-gcdfc56b3). For this particular file, the problematic packet appears to be the very first one, which is a netmon_filter packet.

I did manage 1 solution though, which I'll describe using the NetMon34.cap file as an example:

1. Open the capture file in Wireshark and apply the netmon_filter display filter to find all problematic packets. In the case of the NetMon34.cap file, only packet 1 matched the filter, so we need to remove it. (Perhaps it's always packet 1, and only packet 1, that is the problematic packet in these types of files, in which case this step might not be strictly necessary. It certainly doesn't hurt to be sure though.)
2. Remove the netmon_filter packet using editcap:

editcap -F netmon2 NetMon34.cap NetMon34_2-.cap 1

This will remove packet 1 from the NetMon34.cap file, which is the aforementioned netmon_filter packet, and write the remaining packets to the NetMon34_2-.cap file, which will be saved as a netmon2 file type, which is the only type that seems to work (in my testing at least; I did not attempt every possible format).

3. Open the new NetMon34_2-.cap file in Wireshark. You can now "Save As..." as you please.

You can check/compare file information using capinfos and see the problem with multiple encapsulations in the original file, only a single encapsulation in the file with the netmon_filter packet removed, and finally with a different encapsulation after I used Save As..." to save the file as a pcap file instead of a netmon2 file. For example:

capinfos -E NetMon34.cap
File name:           NetMon34.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (205)
Network Monitor Filter (1)

capinfos -E NetMon34_2-.cap
File name:           NetMon34_2-.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (205)

capinfos -E NetMon34_2-.pcap
File name:           NetMon34_2-.pcap
File encapsulation:  Ethernet


There may be other ways to accomplish this, but this was the only method that I could come up with. For example, in Wireshark, I first tried to have Wireshark ignore the netmon_filter packet (right-click then Ignore/Unignore Packet) and then see if "Save As..." was active, but it still wasn't.

Perhaps a Wireshark bug report should be filed to improve Wireshark's capabilities in this area.

Without further information, I'm going to assume that you're working with a Microsoft Network Monitor cap file, and in that case, you may want to refer to this question. I believe it's still applicable, and I've verified it with at least 1 capture file, NetMon34.cap, from the Wireshark menagerie and Wireshark master, specifically Version 2.9.1 (v2.9.1rc0-634-gcdfc56b3). For this particular file, the problematic packet appears to be the very first one, which is a netmon_filter packet.

I did manage 1 solution though, which I'll describe using the NetMon34.cap file as an example:

1. Open the capture file in Wireshark and apply the netmon_filter display filter to find all problematic packets. In the case of the NetMon34.cap file, only packet 1 matched the filter, so we need to remove it. (Perhaps it's always packet 1, and only packet 1, that is the problematic packet in these types of files, in which case this step might not be strictly necessary. It certainly doesn't hurt to be sure though.)
2. Remove the netmon_filter packet using editcap:

editcap -F netmon2 NetMon34.cap NetMon34_2-.cap 1

This will remove packet 1 from the NetMon34.cap file, which is the aforementioned netmon_filter packet, and write the remaining packets to the NetMon34_2-.cap file, which will be saved as a netmon2 file type, which is the only type that seems to work (in my testing at least; I did not attempt every possible format).

3. Open the new NetMon34_2-.cap file in Wireshark. You can now "Save As..." as you please.

You can check/compare file information using capinfos and see the problem with multiple encapsulations in the original file, only a single encapsulation in the file with the netmon_filter packet removed, and finally with a different encapsulation after I used Save As..." to save the file as a pcap file instead of a netmon2 file. For example:

capinfos -E NetMon34.cap
File name:           NetMon34.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (205)
Network Monitor Filter (1)

capinfos -E NetMon34_2-.cap
File name:           NetMon34_2-.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (205)

capinfos -E NetMon34_2-.pcap
File name:           NetMon34_2-.pcap
File encapsulation:  Ethernet


There may be other ways to accomplish this, but this was the only method that I could come up with. For example, in Wireshark, I first tried to have Wireshark ignore the netmon_filter packet (right-click then Ignore/Unignore Packet) and then see if "Save As..." was active, but it still wasn't.

Perhaps a Wireshark bug report should be filed to improve Wireshark's capabilities in this area.

NOTE: if the NetMon capture file contains IEEE 802.11 plus Network Monitor radio header encapsulated packets instead of Per packet encapsulated packets, then this method still won't work.

Without further information, I'm going to assume that you're working with a Microsoft Network Monitor cap file, and in that case, you may want to refer to this question. I believe it's still applicable, and I've verified it with at least 1 capture file, NetMon34.cap, from the Wireshark menagerie and Wireshark master, specifically Version 2.9.1 (v2.9.1rc0-634-gcdfc56b3). For this particular file, the problematic packet appears to be the very first one, which is a netmon_filter packet.

I did manage 1 solution though, which I'll describe using the NetMon34.cap file as an example:

1. Open the capture file in Wireshark and apply the netmon_filter display filter to find all problematic packets. In the case of the NetMon34.cap file, only packet 1 matched the filter, so we need to remove it. (Perhaps it's always packet 1, and only packet 1, that is the problematic packet in these types of files, in which case this step might not be strictly necessary. It certainly doesn't hurt to be sure though.)
2. Remove the netmon_filter packet using editcap:

editcap -F netmon2 NetMon34.cap NetMon34_2-.cap 1

This will remove packet 1 from the NetMon34.cap file, which is the aforementioned netmon_filter packet, and write the remaining packets to the NetMon34_2-.cap file, which will be saved as a netmon2 file type, which is the only type that seems to work (in my testing at least; I did not attempt every possible format).

3. Open the new NetMon34_2-.cap file in Wireshark. You can now "Save As..." as you please.

You can check/compare file information using capinfos and see the problem with multiple encapsulations in the original file, only a single encapsulation in the file with the netmon_filter packet removed, and finally with a different encapsulation after I used Save As..." to save the file as a pcap file instead of a netmon2 file. For example:

capinfos -E NetMon34.cap
File name:           NetMon34.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (205)
Network Monitor Filter (1)

capinfos -E NetMon34_2-.cap
File name:           NetMon34_2-.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (205)

capinfos -E NetMon34_2-.pcap
File name:           NetMon34_2-.pcap
File encapsulation:  Ethernet


There may be other ways to accomplish this, but this was the only method that I could come up with. For example, in Wireshark, I first tried to have Wireshark ignore the netmon_filter packet (right-click then Ignore/Unignore Packet) and then see if "Save As..." was active, but it still wasn't.

Perhaps a Wireshark bug report should be filed to improve Wireshark's capabilities in this area.

NOTE: if the NetMon capture file contains IEEE 802.11 plus Network Monitor radio header encapsulated packets instead of Per packet encapsulated packets, then this method won't work. An alternate solution may be possible though …

The Wireshark menagerie also contains another file I will use for this next example, namely 7620-Native_NetMon.cap. This file is problematic for Wireshark in several ways. First, let's look at the encapsulation information for this file:

capinfos -E 7620-Native_NetMon.cap
File name:           7620-Native_NetMon.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (61)
IEEE 802.11 plus Network Monitor radio header (162)
Network Monitor Filter (1)
Network Monitor Network Info (1)


Due to multiple encapsulations and the Network Monitor radio header, Wireshark can't save this file as another file type and editcap can't deal with it either. So, what to do?

1. Download and install Microsoft Network Monitor 3.4.
2. Open the 7620-Native_NetMon.cap file in NetMon and apply a filter of WiFi.
3. Choose File -> Save As of Displayed frames only and uncheck the Record display filter in capture file option. Since I filtered only the WiFi packets from this capture file, I named the file 7620-Native_NetMon_WiFi.cap.
4. Remove the WiFi filter in NetMon and apply a filter of Ethernet.
5. Choose File -> Save As of Display frames, once again with the Record display filter in capture file option unchecked. Since I filtered only the Ethernet packets from this capture file, I named the file 7620-Native_NetMon_Ethernet.cap.

Now there are 2 files, each with a single encapsulation:

capinfos -E 7620-Native_NetMon_WiFi.cap
File name:           7620-Native_NetMon_WiFi.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
IEEE 802.11 plus Network Monitor radio header (162)

capinfos -E 7620-Native_NetMon_Ethernet.cap
File name:           7620-Native_NetMon_Ethernet.cap
File encapsulation:  Per packet
Encapsulation in use by packets (# of pkts):
Ethernet (61)


While Wireshark is capable of reading the Ethernet file and saving it in another file format, it's still won't work.

not capable of doing this with the WiFi file. The WiFi file is also still problematic for editcap, but we can remove the fixed 32-byte header from those packets and change the encapsulation to a type that Wireshark can deal with.

6) Remove the NetMon 802.11 capture header: editcap -T ieee-802-11 -F pcapng -C 32 7620-Native_NetMon_WiFi.cap 7620-Native_NetMon_WiFi.pcapng

Note that because the NetMon 802.11 capture header has been removed, we need to manually change the encapsulation type. I've also changed the file format to a pcapng file, which is needed later when the separate WiFi and Ethernet capture files are merged together again later.

7) Save the Ethernet file as a pcapng file type as well. Unfortunately, it seems that editcap has a problem whereby it can't perform the conversion, but Wireshark is able to; therefore open the 7620-Native_NetMon_Ethernet.cap file in Wireshark and choose "File -> Save As -> 7620-Native_NetMon_Ethernet.pcapng" with the file type set to pcapng.

8) Finally, merge the 2 pcapng files into one. This can be done either directly in Wireshark using File -> Merge or with mergecap. Since it's trivial to do this with Wireshark, here's the example using mergecap:

mergecap -F pcapng -w 7620-Native_NetMon.pcapng 7620-Native_NetMon_Ethernet.pcapng 7620-Native_NetMon_WiFi.pcapng


After this, you will now have a 7620-Native_NetMon.pcapng file that you can further manipulate in Wireshark.

NOTE: Because Wireshark and mergecap merge packets in chronological order, the packet order in the resulting merged capture file may not be exactly the same as in the original capture file if those packets were not chronologically ordered to begin with, as is this case with this example.