Wireshark-bugs: [Wireshark-bugs] [Bug 5746] Wireshark not able to decode the PPP frame in a sflo
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 11 Mar 2011 18:00:58 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5746

--- Comment #12 from Guy Harris <guy@xxxxxxxxxxxx> 2011-03-11 18:00:57 PST ---
The Address and Control fields can, in a PPP connection, be negotiated off with
the Address-and-Control-Field-Compression option, and it's permanently off for
PPPoE (it mandates the absence of the Address and Control fields; see section 6
of RFC 2516).

As RFC 1662 says:

      On reception, the Address and Control fields are decompressed by
      examining the first two octets.  If they contain the values 0xff
      and 0x03, they are assumed to be the Address and Control fields.
      If not, it is assumed that the fields were compressed and were not
      transmitted.

         By definition, the first octet of a two octet Protocol field
         will never be 0xff (since it is not even).  The Protocol field
         value 0x00ff is not allowed (reserved) to avoid ambiguity when
         Protocol-Field-Compression is enabled and the first Information
         field octet is 0x03.

So a valid PPP frame beginning with 0xff 0x03 is unambiguously a
PPP-in-HDLC-like-framing frame.  It's still probably reasonable to use the
"ppp" dissector, which doesn't check for the Address and Control fields, for
protocols such as PPPoE that are defined not to use those fields.

Switching the sFlow dissector to use the "ppp_hdlc", which checks for 0xff 0x03
and treats them as the Address and Control fields if present, is the right
thing to do; there's no need to do those checks in the sFlow dissector.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.