This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Problems with editcap and “wpan” encapsulation option

0

Hello everyone. I'm doing some work in wireless sensor networks and right now I have a capture file with some IEEE 802.15.4 frames encapsulated in SLL. The protocols in each frame are: sll:wpan:6lowpan:ipv6:icmpv6

I tried removing the SLL header and changing the encapsulation type using editcap with the following command:

editcap -T wpan -C 16 test.pcap test_wpan.pcap

However, when trying to read the test_wpan.pcap file, I got a two-byte padding warning in my ICMPv6 (IEEE 802.15.4 footer with FCS), which leads me to believe the "wpan" option is actually setting the encapsulation type of "wpan-nofcs".

Regarding the WTAP_ENCAP number, with no processing of editcap I see 25 in each number. When I use editcap with "wpan", the number is changed to 104, and when I use the "wpan-nofcs" the number set is 127. Taking a look at http://www.tcpdump.org/linktypes.html, shouldn't the numbers be:

  • SLL -> 113
  • WPAN -> 195
  • WPAN-NOFCS -> 230

??

Am I missing something?

asked 05 Jul '13, 07:27

ojay's gravatar image

ojay
16347
accept rate: 0%

edited 08 Jul '13, 10:13

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142


2 Answers:

2

OK, hopefully this will be of more help:

  1. Chop off the 16 bytes of the Linux cooked capture encapsulation, saving to a pcap file for best chance at success (NOTE: At this point, specifying "-T wpan" isn't strictly required):

    editcap -T wpan -C 16 -F libpcap test.pcap tmp.pcap

  2. Open the tmp.pcap file with Wireshark >= SVN revision 50036. (Visit http://wiresharkdownloads.riverbed.com/wireshark/automated/ and download a recent automated version meeting that criteria.)

    The packets are not correctly decoded because Wireshark now thinks that all frames are 16 bytes shorter than they're supposed to be. This can be corrected by exporting the packets to a text file and then re-importing them back into a new capture file, this time specifying the encapsulation.

  3. Before exporting to text:

    a. Add the "Absolute date and time" column.

    b. Temporarily hide all other columns.

    c. Turn off: Edit/Preferences/Protocols/Data/ "Show not dissected data on new Packet Bytes pane".

  4. File/Export Packet Dissections/As "Plain Text" file...

    a. Include the packet summary line (Absolute date and time only)

    b. Exclude the column headings.

    c. Exclude the packet details.

    d. Include the packet bytes.

    e. File name: tmp.txt

  5. Close the current (incorrectly decoded) tmp.pcap capture file.

  6. Import the tmp.txt file to a correctly decoded pcap file via File/Import from Hex Dump...:

    a. Browse to where tmp.txt is located.

    b. Select Date/Time and check that Format = "%F %T." (no quotes).

    c. Select "IEEE 802.15.4 Wireless PAN" as the Encapsulation type.

If all went OK, you should know have an as-yet unsaved pcap file in the format you were looking for. There may be an easier way to do this, but hopefully this provides at least 1 usable solution for you.

answered 08 Jul '13, 11:50

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

I can't post a comment, Akismet always considers it SPAM -.-

--edit--
I'm having problems compiling Wireshark, I posted a question about it but I can't paste the link to it here because apparently the anti-spam plugin thinks it's spam. Good times...

(09 Jul '13, 13:53) ojay

Hmm, that's too bad. Try posting to wireshark-dev?

(09 Jul '13, 16:57) cmaynard ♦♦

BTW, the only reason I suggested using r50036 or later is so that you can avoid writing the column headings to the temporary tmp.txt file, because if they're present, the import will fail. You may be able to get away with not upgrading if you can figure out how to write a script that removes the column headings from the tmp.txt file prior to importing.

(09 Jul '13, 17:37) cmaynard ♦♦

Okay I managed to successfully compile it! Thank you for all the help! :D

One thing though, when I try to save the file as pcap (Wireshark wants to save it in pcap-ng by default), I get a warning message saying there are comments in the file and if I save in pcap format I will loose them. Now, I don't what those comments might be. Is there anyway to read the comments and then decide if I want to delete/modify instead of Wireshark just telling me there are comments without me being able to read them?

(10 Jul '13, 09:21) ojay

Statistics -> Summary will show the capture file comments, while Analyze -> Expert Info will show the per-packet comments under the "Packet Comments" tab.

(10 Jul '13, 09:28) cmaynard ♦♦

Thank you! I noticed another thing. The original file displayed 48 packets (all ICMPv6, Data frame type of IEEE 802.15.4), but now the new file I created following your steps shows 72. Some packets showing Beacon frame type of IEEE 802.15.4 now appear. Is that because of the checkbox "Show not dissected data on new Packet Bytes pane" or did the IEEE 802.15.4 dissector got improved in version 1.11? I was using version 1.8.2, the most recent from the Ubuntu packaging system.

(10 Jul '13, 09:48) ojay

There have been improvements to the IEEE802.15.4 dissector since 1.8.2, so I'm fairly certain that is the reason. It's certainly not because of checking the "Show not dissected data on new Packet Bytes pane" preference, which is only needed to avoid writing the hex bytes for the entire frame along with the undissected hex bytes subset of the packet (if any) to the text file. If that were to happen, it would mess up the import.

(10 Jul '13, 10:11) cmaynard ♦♦

Or it could be that those extra frames are incorrectly being dissected as IEEE802.15.4 packets now? Do they look like valid beacon frames? How were they dissected before the encapsulation conversion? If you could post a small capture file before conversion to cloudshark, then it might helpful to see exactly what's going on.

(10 Jul '13, 10:16) cmaynard ♦♦

I can't post any links in comments...

--edit-- Here it is: cloudshark.org/captures/7002738c9fc1 (FTFY)
The packets tree is not the same as I see it in Wireshark 1.8.2/1.11, the IEEE 802.15.4 frames aren't decoded in cloudshark.

(11 Jul '13, 02:04) ojay
2

Update: As of r50493, with the introduction of the -L option to editcap, you can now accomplish what you want in a single step. Example:

editcap -T wpan -C 16 -L -F libpcap test.pcap test_wpan.pcap
(11 Jul '13, 07:40) cmaynard ♦♦
showing 5 of 10 show 5 more comments

2

Did you try the following?

editcap -T wpan -C 16 -F libpcap test.pcap test_wpan.pcap

answered 08 Jul '13, 10:27

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

Thank you for the reply! I didn't know we had to specify libpcap format, I thought it was a default option?

I still see a wrong WTAP_ENCAP number (104 instead of 195) and Wireshark still warns me there's 2 bytes after ICMPv6 it doesn't recognize (should recognize as WPAN FCS).

The only difference I noted is this:

$ file test_wpan.pcap
test_wpan.pcap: pcap-ng capture file - version 1.0

$ file test_wpan_new.pcap
test_wpan_new.pcap: tcpdump capture file (little-endian) - version 2.4, capture length 65535)

(08 Jul '13, 10:39) ojay

pcap-ng is the new default, but it doesn't always work. There is at least 1 bug already reported about it.

WTAP_ENCAP's != DLT's.

What does capinfos (and/or Wireshark's summary) say about each of those files?

Maybe you could post a small capture file to cloudshark?

(08 Jul '13, 10:42) cmaynard ♦♦