Hello All...I'm stuck. I'm on OSX 10.6 and I captured on the VPN tunnel interface (Juniper Network Connect jnc0). Wireshark is able to read the file just fine, but when I go to use "advanced" analysis system it tells me that the file is corrupt. I recapture, same problem. I can see that the file has an encapsulation of "Null / Loopback" so I use editcap to switch to ether - well, it's NOT ether and simply changing the encapsulation identifier isn't going to fix the problem. I'm looking at bittwist and NetDude in hopes of an answer, but I'm not seeing one. So, is there a way to convert the link layer encapsulation from Null/Loopback to ether and have it work properly? asked 08 Dec '11, 12:12  GeonJay |
One Answer:
In theory, it's possibly to construct a "fake" Ethernet header, with fake source and destination addresses, for a LINKTYPE_NULL packet, at least as long as it's an IPv4 packet (fake Ethernet type 0x0800) or an IPv6 packet (fake Ethernet type 0x86dd), and most if not all packets captured with that link-layer header type will be IPv4 or IPv6 packets. I don't know of any program that will do that, however. It might exist, but, if so, I've never seen it. Nothing in the Wireshark suite of programs will do it. (It's also annoying that whoever wrote the "advanced" analysis system couldn't be bothered to support LINKTYPE_NULL, or even just to say "this is a valid pcap file, but I don't handle that link-layer type"; calling it "corrupt" just because the link-layer header type was LINKTYPE_NULL is completely bogus. What software is that?) answered 08 Dec '11, 23:19  Guy Harris ♦♦ It's OpNet ACE. I wasn't bright enough to think of forcing an etherII header and the ether-type of 0x0800 - I think bittwist can do that. Let me play with it. All of the packets I'm interested in are IPv4 - we're diagnosing a Microsoft Lync registration issue that only affects Mac users when working remotely. SYN - I'll work on scrubbing a piece of the file and popping it up here. (09 Dec '11, 06:35) GeonJay Ok. The Null/Loopback header length is 4bytes and EtherII is 14. The tool would have to completely remove/replace the layer 2 header. I'm thinking I could use editcap's chop from beginning feature to remove layer1/2 info then add new header info - but I'm in no way a coding genius and the tool would have to autosense packet types and lengths. Ugh :( (09 Dec '11, 07:12) GeonJay You should file a complaint with OPNET that they should, ideally, support at least LINKTYPE_NULL and possibly some other link-layer header types (LINKTYPE_PPP, LINKTYPE_C_HDLC, LINKTYPE_IEEE802_11, and LINKTYPE_IEEE802_11_RADIO, for example) and, if they don't, they should at least give a better error than "the file is corrupt" for an unsupported link-layer header type. (09 Dec '11, 10:32) Guy Harris ♦♦ Unfortunately, bittwiste won't do it; the bittwiste man page says "Bittwiste is designed to work only with Ethernet frame". A pcap-based program could read a packet, discard packets where the 4-byte header (in either byte order) is neither IPv4 (2) nor any of the IPv6 values (24, 28, 30), replace the 4-byte header with {00:00:00:00:00:00,00:00:00:00:00:00,0x0800} for a value of 2 and {...,0x86dd} for the other values, leave the payload alone, and write the packet out. (09 Dec '11, 10:43) Guy Harris ♦♦ Thanks for the help Guy! (09 Dec '11, 14:18) GeonJay |
Are you able to post an example somewhere? Even a trace with few packets encoded with uuencode posted here will do :-)