On Mar 3, 2016, at 2:17 PM, jing dai <dxj910...@gmail.com> wrote:
> I'm using tcpdump over a data link type.
>
> tcpdump -y PPP -c 1
No, what you're doing is using tcpdump on a *network interface*, and *trying*
to use a particular data link type on that interface.
> Here's prompt message, PPP is not one of the DLTs supported by this
> device. And actually, only EN10MB works.
Yes, you're capturing on the default network device, which is probably either
an Ethernet or a Wi-Fi device.
If you capture on an Ethernet interface, you will, not surprisingly, get
Ethernet headers, not PPP headers. There *is* "PPP over Ethernet" (PPPoE):
https://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet
but PPPoE Session packets are Ethernet packets, with the Ethernet header
followed by a PPPoE header, followed by a PPP packet.
You can't ask an Ethernet device to provide PPP headers for Ethernet packets.
*If* you're using PPPoE, your OS's PPPoE implementation *might* provide an
additional network interface for the PPPoE traffic, and if you capture on
*that* interface you might get PPP headers, but you'd have to explicitly
specify that interface with the "-i" flag, *and* there's no guarantee that it
will supply PPP headers (it probably won't do so on Windows or Linux, for
example).
If you capture on a Wi-Fi interface, you will, somewhat surprisingly, get
*Ethernet* headers, not Wi-Fi headers, by default. You'll need to capture in
monitor mode to get Wi-Fi headers - and all that I said about PPP headers, and
PPPoE, applies to Wi-Fi the same way it applies to Ethernet.
If you're capturing on a mobile phone network interface, it might be running
PPP on top of all the GPRS/EDGE/HSDPA/HSUPA/etc. mobile phone stuff, but the
software may just supply the packets as Ethernet packets, with no option to
request PPP headers.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
