Question on print-ppp.c

[Michael Haardt <michael () moria de>]

Hello,

I just came across a broken PPP PAP ACK packet which was just
4 bytes long, because it lacked the message-length octet.

pppd 2.4.5 accepts such truncated PPP PAP ACKs and only logs a debugging
message, but at least it generates 5 byte packets.  LWIP copied that code.
TI NDK accepts truncated packets as well, although it also generates them,
so perhaps it counts less.

tcpdump did not show it being truncated due to a check that prevents
that.  While that could be fixed easily with

--- ./tcpdump-4.5.1/print-ppp.c 2013-11-08 00:22:54.000000000 +0100
+++ ./tcpdump-4.5.1-patched/print-ppp.c 2014-03-17 19:50:42.000000000 +0100
@@ -946,8 +946,13 @@
                break;
        case PAP_AACK:
        case PAP_ANAK:
-               if (length - (p - p0) < 1)
-                       return;
+               /* Although some implementations ignore truncation at
+                * this point and at least one generates a truncated
+                * packet, RFC 1334 section 2.2.2 clearly states that
+                * both AACK and ANAK are at least 5 bytes long.
+                */
+               if (len < 5)
+                       goto trunc;
                TCHECK(*p);
                msg_len = *p;           /* Msg-Length */
                p++;

I wonder if that is the right way.  I see printing other PPP packets
contains similar checks that explicitly do not print them as being
truncated.

Am I missing something here? I see nothing in the RFC about optional
fields.

Michael
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers