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

Reading tcpdump capture: Complex interface configuration

0

I'm trying to read a tcpdump capture with Wireshark, but getting pcap: network type 1146433328 unknown or unsupported

This box is using 803.1Q vlan tagging over 803.3ad link aggravation and I have not had a problem with that in the past. However, this one also has an alias defined and that seems to be what's causing the problem. So the interfaces look like:

eth0--+         +--vlan20   => 192.168.20.1
      |         |
      +--Bond0--+
      |         |
eth1--+         +--vlan20:1 => 192.168.20.2

When I try to replay the capture in Wireshark I get the pcap error. The capture does replay fine with tcpdump. For what its worth, I typically ftp the capture and replay with an MS Windows instance of Wireshark. Again, this appears to be the result of the alias since I don't have problems replaying captures where there isn't one (but there is 803.1Q and 803.3ad). I assume it's due to how tcpdump writes the link layer header. Is there a simple switch, or other way, to read these, or write them in a readable way?

TIA.

EDIT:

I can add a little more to this. Wireshark is getting the network type from offset 0x8b-0x8e in the capture file. In this file the payload of the first packet actually begins at offset 0x52. When you replay the capture in tcpdump the payload begins at offset 0x2a. So, the .cap file has a 40 byte header. I'm guessing there is something in the header that causes Wireshark to misinterpret the file structure.

EDIT:

I've decoded the per file header and the first per packet header and I don't see anything obvious. The link layer type is LINKTYPE_ETHERNET just as it should be. Below is the .cap file content, with first packet payload beginning at 52h.

00000000h: D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 ; Ôò¡............
00000010h: FF FF 00 00 01 00 00 00 DA 67 C8 52 DF 6A 0C 00 ; ÿÿ......ÚgÈRßj..
00000020h: 4C 02 00 00 4C 02 00 00 00 25 90 6C A9 82 00 25 ; L...L....%l©‚.%
00000030h: 90 6A F3 3A 08 00 45 00 02 3E D8 31 00 00 40 11 ; jó:..E..>Ø[email protected]
00000040h: 04 AD C0 A8 14 01 C0 A8 06 7F 13 C4 13 C4 02 2A ; .­À¨..À¨..Ä.Ä.*
00000050h: 0A 6E 4F 50 54 49 4F 4E 53 20 73 69 70 3A 31 30 ; .nOPTIONS sip:10

BTW, 1146433328d = 44h 55h 2Fh 30h = SIP/2.0/UDP

asked 04 Jan '14, 09:59

tlum's gravatar image

tlum
1112
accept rate: 0%

edited 04 Jan '14, 12:18

Can you share the pcap file? If not, can you share the first 40-100 bytes as a snippet?

(04 Jan '14, 11:49) Jasper ♦♦

also, can you try to compress the file and then FTP it? Maybe the transfer messes with the file contents.

(04 Jan '14, 11:51) Jasper ♦♦

For me this snippet opens in Wireshark and says "packet seems to have been cut short", which comes as no surprise. Also, in my hex editor the file looks fine to me, including file and packet header. What Wireshark version are you using, and which OS is this? Can you try a newer version perhaps?

(04 Jan '14, 12:38) Jasper ♦♦

One Answer:

0

Tremendously sorry, but the UltraEdit ftp is brain damaged. It appears to have ignored the binary setting and I don't know why. What is even stranger is that if I ftp open the file its binary and its just fine, but if I do a transfer of the file it seems to come over as ascii. But that's not a Wireshark problem, its an UltraEdit problem.

answered 04 Jan '14, 12:42

tlum's gravatar image

tlum
1112
accept rate: 0%

No problem, as long as it works now ;-)

(04 Jan '14, 12:45) Jasper ♦♦