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

Is text2pcap able to produce valid “PPP In HDLC-Like Framing” packets with escaped chars?

0

If I capture "PPP In HDLC-Like Framing" packets over USB interface wireshark decodes correctly the packets (Flag Sequence 0x7E is recognized and escaped chars are handled 0x7D plus xor 0x20).

alt text

Instead if I try to convert an hexdump log of raw PPP packets into a pcap file with text2pcap (specifying as LINK_TYPE = 9 http://www.tcpdump.org/linktypes.html) they are not correctly recognized by Wireshark (Flag Sequence 0x7E and escaped chars are not handled).

alt text

I tried changing "LINK_TYPE" with each of the types which reports "HDLC" with no success.

Is it a limit of text2pcap or wireshark?

In my opinion if the decoder finds the "LINK_TYPE" explicitly declared inside the pcap header it is not able to discard the Flag Sequence (0x7E) and de-escape the other chars instead when the packet is encapsulated inside the URB (where the "LINK_TYPE" is not specified for the URB PDU) it is decoded correctly.

Can I conclude there is no way to use text2pcap for my needs?

Thank you in advance.

asked 17 Aug '15, 08:37

mmaz's gravatar image

mmaz
11●1●1●5
accept rate: 0%

edited 17 Aug '15, 08:45

2 Answers:

1

The best that I could come up with as a possible workable solution would be to prepend the following 4 bytes to your data: 00 00 88 81, i.e.:

000000 00 00 88 81 7e ff 7d 23 c0 21 7d 21 7d 21 7d 20
000010 7d 39 7d 21 7d 24 7d 22 7d 20 7d 22 7d 26 ff ff
000020 ff ff 7d 23 7d 25 c2 23 7d 25 7d 25 7d 26 7d 20
000030 7d 20 30 c8 e2 d4 7e
000037

... and then assuming this data is saved in a file called, "ask45158.txt", run text2pcap as follows:

text2pcap -d -e 101 -i 47 ask45158.txt ask45158.pcap

The extra 4 bytes are a dummy GRE header, and the -e 101 -i 47 options will add a dummy IP header and generate a pcap file with LINKTYPE_RAW encapsulation. It may be possible to add a dummy USB header and specify -i 189 instead, but it was easier for me to generate the dummy GRE header. If you can add those 4 bytes and don't care about the dummy IP and GRE headers, then this might be a potential solution for you.

Here's the sample tshark output of running tshark -r ask45158.pcap -O lcp:

Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Ethernet II, Src: 0a:01:01:01:01:01 (0a:01:01:01:01:01), Dst: 0a:02:02:02:02:02 (0a:02:02:02:02:02) Internet Protocol Version 4, Src: 10.1.1.1 (10.1.1.1), Dst: 10.2.2.2 (10.2.2.2) Generic Routing Encapsulation (CDMA2000 A10 Unstructured byte stream) PPP In HDLC-Like Framing Point-to-Point Protocol PPP Link Control Protocol Code: Configuration Request (1) Identifier: 1 (0x01) Length: 25 Options: (21 bytes), Maximum Receive Unit, Async Control Character Map, Auth entication Protocol, Magic Number Maximum Receive Unit: 512 Type: Maximum Receive Unit (1) Length: 4 Maximum Receive Unit: 512 Async Control Character Map: 0xffffffff (All) Type: Async Control Character Map (2) Length: 6 Async Control Character Map: 0xffffffff, US, RS, GS, FS, ESC, SUB, E M, CAN, ETB, SYN, NAK, DC4, DC3 (XOFF), DC2, DC1 (XON), DLE, SI, SO, CR, FF, VT, LF, HT, BS, BEL, ACK, ENQ, EOT, ETX, STX, SOH, NUL (All) 1... .... .... .... .... .... .... .... = US: True .1.. .... .... .... .... .... .... .... = RS: True ..1. .... .... .... .... .... .... .... = GS: True ...1 .... .... .... .... .... .... .... = FS: True .... 1... .... .... .... .... .... .... = ESC: True .... .1.. .... .... .... .... .... .... = SUB: True .... ..1. .... .... .... .... .... .... = EM: True .... ...1 .... .... .... .... .... .... = CAN: True .... .... 1... .... .... .... .... .... = ETB: True .... .... .1.. .... .... .... .... .... = SYN: True .... .... ..1. .... .... .... .... .... = NAK: True .... .... ...1 .... .... .... .... .... = DC4: True .... .... .... 1... .... .... .... .... = DC3 (XOFF): True .... .... .... .1.. .... .... .... .... = DC2: True .... .... .... ..1. .... .... .... .... = DC1 (XON): True .... .... .... ...1 .... .... .... .... = DLE: True .... .... .... .... 1... .... .... .... = SI: True .... .... .... .... .1.. .... .... .... = SO: True .... .... .... .... ..1. .... .... .... = CR: True .... .... .... .... ...1 .... .... .... = FF: True .... .... .... .... .... 1... .... .... = VT: True .... .... .... .... .... .1.. .... .... = LF: True .... .... .... .... .... ..1. .... .... = HT: True .... .... .... .... .... ...1 .... .... = BS: True .... .... .... .... .... .... 1... .... = BEL: True .... .... .... .... .... .... .1.. .... = ACK: True .... .... .... .... .... .... ..1. .... = ENQ: True .... .... .... .... .... .... ...1 .... = EOT: True .... .... .... .... .... .... .... 1... = ETX: True .... .... .... .... .... .... .... .1.. = STX: True .... .... .... .... .... .... .... ..1. = SOH: True .... .... .... .... .... .... .... ...1 = NUL: True Authentication Protocol: Challenge Handshake Authentication Protocol (0x c223) Type: Authentication Protocol (3) Length: 5 Authentication Protocol: Challenge Handshake Authentication Protocol (0xc223) Algorithm: CHAP with MD5 (5) Magic Number: 0x000030c8 Type: Magic Number (5) Length: 6 Magic Number: 0x000030c8

answered 17 Aug '15, 13:13

cmaynard's gravatar image

cmaynard ♦♦
9.4k●10●38●142
accept rate: 20%

Thank you for your suggestion, I will follow it.

Do you have any env var which enables field expansion of tshark? Because using your command line I get a compact output:

Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Ethernet II, Src: 0a:01:01:01:01:01 (0a:01:01:01:01:01), Dst: 0a:02:02:02:02:02 (0a:02:02:02:02:02)
Internet Protocol Version 4, Src: 10.1.1.1 (10.1.1.1), Dst: 10.2.2.2 (10.2.2.2)
Generic Routing Encapsulation (CDMA2000 A10 Unstructured byte stream)
PPP In HDLC-Like Framing
Point-to-Point Protocol
PPP Link Control Protocol
(17 Aug '15, 15:16) mmaz

It doesn't expand the PPP Link Control Protocol? His command line was intended to give compact output for everything above LCP - that's what -O lcp does. If you want everything expanded, use -V rather than -O lcp.

(17 Aug '15, 15:55) Guy Harris ♦♦

It's working fine! I copied and pasted also the final ":" :-)

(18 Aug '15, 02:33) mmaz

@mmaz

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(18 Aug '15, 03:13) grahamb ♦

1

Well, you'll have to adhere to the specified format for using a LINK_TYPE. In this case LINKTYPE_PPP is defined as: "PPP, as per RFC 1661 and RFC 1662; if the first 2 bytes are 0xff and 0x03, it's PPP in HDLC-like framing, with the PPP header following those two bytes, otherwise it's PPP without framing, and the packet begins with the PPP header.". So that means that the flag octet has no place in this format.

The USB bulk data heuristics were created ad-hoc, to try to accomodate as much as possible the sample captures found 'in the wild', for which the format is 'unspecified'. So that's why the PPP over USB Bulk is being dissected, while LINKTYPE_PPP capture is considered malformed.

answered 17 Aug '15, 12:06

Jaap's gravatar image

Jaap ♦
11.7k●16●101
accept rate: 14%

Thank you for the reply. I tried:

1) removing the flag 0x7E at the beginning and at the end of the hexdump -> text2pcap creates a file where the packet is not correctly recognized because of the first 0x7D

2) removing also che first 0x7D and now the packet starts with 0xFF 0x03 -> text2pcap creates a packet which is recognized as "malformed"

3) removing all the 0x7D and xor-ing with 0x20 all the escaped bytes -> now text2pcap produces a valid pcap file comparable with the URB encapsulated.

I can conclude LINKTYPE_PPP dissector doesn't fully adhere to RFC 1662 where the escaping with 0x7D is described.

(17 Aug '15, 15:03) mmaz
1

I can conclude LINKTYPE_PPP dissector doesn't fully adhere to RFC 1662 where the escaping with 0x7D is described.

You can also conclude that the description of LINKTYPE_PPP on [the tcpdump.org link-layer header types page(http://www.tcpdump.org/linktypes.html) needs to clarify that it is NOT for raw octet streams. It's for frames that have been un-stuffed and that have the Address, Control, Protocol, and Information fields from section 3.1 "Frame Format" of RFC 1662. I will update it.

There is no LINKTYPE_ value for either octet-stuffed or bit-stuffed PPP-in-HDLC-like-framing packets, unfortunately, so, no, text2pcap can't do it directly - Chris Maynard's solution is the best that can be done.

(17 Aug '15, 15:42) Guy Harris ♦♦