1 | initial version |
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:
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).
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.
2 | No.2 Revision |
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:
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).
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.
3 | No.3 Revision |
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:
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).
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?
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.
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.