Dave Lyneham wrote:
DLT_PPP_PPPD (166) is defined in "pcap-bpf.h" but not a type supported
by Wireshark. The difference is simply an extra byte preceeds the
actual PPP packet containing 00 or 01 to indicate direction.
No, it isn't. The difference is the replacement of the first byte of
the packet, *presumed* to be an address byte (i.e., no address
compression), with the direction byte.
If someone was inspired to add this protocol type it could be quite
helpful for debugging PPP connection.
...if anything actually wrote out files in that format.
That DLT_ value was added for the benefit of pcap_compile(), not for the
benefit of tcpdump/Wireshark/etc. The comment for it in pcap-bpf.h says:
/*
* Another PPP variant as per request from Karsten Keil <kkeil@xxxxxxx>.
*
* This is used in some OSes to allow a kernel socket filter to distinguish
* between incoming and outgoing packets, on a socket intended to
* supply pppd with outgoing packets so it can do dial-on-demand and
* hangup-on-lack-of-demand; incoming packets are filtered out so they
* don't cause pppd to hold the connection up (you don't want random
* input packets such as port scans, packets from old lost connections,
* etc. to force the connection to stay up).
*
* The first byte of the PPP header (0xff03) is modified to accomodate
* the direction - 0x00 = IN, 0x01 = OUT.
*/
This doesn't say that you couldn't modify the PPP implementation for an
OS to supply the direction information, but that *is* a modification -
unless there already exist PPP implementations that put the direction
information into the packet data, you can't fix this problem solely by
modifying Wireshark (if nothing generates files with that DLT_ value,
the code in Wireshark to read it would, in effect, be dead code).