[barcaroller <barcaroller@xxxxxxxxx>]

> On Jul 19, 2017, at 8:27 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> 
> (For some reason, I never got this message, although it appears in the archives.  Sorry about the delay in getting back to you on this.)
> 
> On Thu, 11 May 2017, at 16:29:05 -0400, barcaroller <barcaroller@xxxxxxxxx> wrote:
> 
>> I'm hoping someone can point me in the right direction.  I have a PCAP file where the packets do not have an Ethernet header; instead they have a PPP (Point-to-Point Protocol) header.
>> I have a few questions.
>> 
>> 1. The PPP header I'm seeing in wireshark has the following structure:
>> 
>>    Address     0xFF (1 byte)
>>    Control     0x03 (1 byte)
>>    Protocol  0x0021 (2 bytes)
>>    <...followed by IPv4...>
>> 
>> 
>> What happened to the 1-byte Flag field (usually set at 0x7E) which indicates the beginning of the PPP frame?
> 
> That, along with escaping of octets with the frame value, is part of the framing, which is usually stripped by whatever software is doing the capturing.  For example, if you're capturing on a PPP interface using the OS's capturing mechanism, those packets will probably first be processed by the PPP driver, which, for PPP-over-async-serial, would strip the framing octets and un-escape escaped octets, assembling a frame without the flag field and with un-escaped octets. That would then be handed to other layers of the networking stack, among which would be the layer doing packet capture processing.
> 
>> 2. Given that the flag field is missing, how was wireshark still able to guess the proper format of the packet?  The packet format is:
>>    PPP
>>      IPv4
>>         UDP/Teredo
>>           IPv6
>>             ICMPv6
> 
> Capture files that can support more than one type of link-layer header contain an indication of the link-layer header type, either for all packets in the file, each interface on which packets in the file were captured, or each packet.  That can indicate a PPP header, which, for all those file types, means "de-framed and de-escaped PPP".  It may or may not contain the other part of "HDLC-like framing", namely the address and control fields; if it's not guaranteed to be there or not to be there, Wireshark will check for FF 03 and, if it finds it, treat them as the address and control fields of "HDLC-like framing".
> 
>> 3. Even if the flag field were present,
> 
> For pcap and pcapng, there would have to be a *separate* link-layer header type value for "framed and escaped PPP-over-async-serial", so that Wireshark (and tcpdump and every other program that reads pcap and pcapng files) would know whether the flag octets are present and whether some octet values are escaped, and can remove the flags and un-escape the escaped octets.
> 
>> how does wireshark usually identify the type of Layer 2 header?  Does it guess?
> 
> As per the above, it relies on the file containing an indication of the link-layer header type (or of supporting only one link-layer header type).

Thank you; that was very informative!