Wireshark-bugs: [Wireshark-bugs] [Bug 10611] PTPoE dissector gets confused by packets that inclu
Guy Harris
changed
bug 10611
| What |
Removed |
Added |
| Status |
RESOLVED
|
CONFIRMED
|
| Resolution |
FIXED
|
---
|
Comment # 15
on bug 10611
from Guy Harris
(In reply to Stephen Donnelly from comment #12)
> (In reply to Guy Harris from comment #11)
> > I don't know what the "messageLength" field in the PTP header means - I'll
> > buy a copy of the damn paywalled standard if I need to - but if it's an
> > actual message length, *that* should be used to determine whether there are
> > TLVs or not.
> >
> > As Stephen noted, it's not the job of *any* protocol running atop Ethernet
> > to dissect the FCS, so I've approved and merged his change.
>
> From Draft 2.2 (pre-standard):
>
> 13.3.2.4 messageLength (UInteger16)
> The value of the messageLength shall be the total number of octets that form
> the PTP message. The counted octets start with the first octet of the header
> and include and terminate with the last octet of any suffix or, if there are
> no suffix members with the last octet of the message as defined in Clause 13.
OK, so everything after messageLength is either padding of some sort or a
trailer of some sort (including the FCS if it's running directly on top of the
link layer) - or both, as the first frame in the attached capture has 2 bytes
of Ethernet-layer padding and 4 bytes of FCS.
> So I believe the point is that to determine how many (if any) suffixes (TLV
> entries) are present you have to know the 'base length' for each messageType
> (64 bytes for Announce messages) as well as the messageLength value.
The dissector presumably knows that, and dissects as TLVs everything in the
message past the "base length" portion.
So I'll tweak the PTP dissector to:
1) make sure the messageLength isn't bigger than the on-the-wire data
available for the message;
2) if not, set the length of the tvbuff handed to it to the messageLength.
That might even cause the FCS to be recognized as such in the capture (courtesy
of the FCS heuristics in the Ethernet dissector).
You are receiving this mail because:
- You are watching all bug changes.
