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.
