If ppp_hdlc() is called with length < 2, bad things happen.
Notably, if length == 1, handle_ppp() will be called with "length < 0".
At this point, things get ugly and print_unknown_data() tries to print
way too much data.
If ppp_hdlc() is being called with "p - 1", shouldn't the next parameter
> Rather than just hexdump the PPP data and say "unknown PPP proto (0x00fb)",
> I thought it might be better to print out a nicer message...
>
> --- print-ppp.c.orig2004-07-05 18:30:38.0 +1000
> +++ print-ppp.c 2004-07-05 18:30:47.0 +1000
> @@ -1170,6 +1170,9 @@
> case PP
CVS log entries from 04.07.2004 (Sun) 09:05:17 - 05.07.2004 (Mon) 09:05:14 GMT
=
Summary by authors
=
Author: itojun
File: tcpdump/print-dhcp6.c; Revisions: 1.34
On Mon, Jul 05, 2004 at 06:27:24PM +1000, Darren Reed wrote:
> The frame format here is something like this:
>
> ethernet{ip{l2tp{hdlc{ppp{ip{gre{ppp{...
...i.e., as opposed to
ethernet{ip{l2tp{ppp{ip{gre{ppp{...}}}
-
This is the tcpdump-workers list.
Visit https://lists.sand
Rather than just hexdump the PPP data and say "unknown PPP proto (0x00fb)",
I thought it might be better to print out a nicer message...
--- print-ppp.c.orig2004-07-05 18:30:38.0 +1000
+++ print-ppp.c 2004-07-05 18:30:47.0 +1000
@@ -1170,6 +1170,9 @@
case PPP_MPLS_MCAST
> Normally a NIC or interface providing access to an HDLC link/network would
> perform de-bytestuffing internally before the packets ever get to libpcap.
> Obviously de-bytestuffing a packet twice can corrupt data. Do we really
> want to have de-bytestuffing code in libpcap?
This isn't in libpc
