https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5846
--- Comment #9 from Bill Meier <wmeier@xxxxxxxxxxx> 2011-04-20 11:20:51 EDT ---
Alex:
Right you are.... I got it backwards.
The PacketFormatV1 is the *newer" format; PacketFormat is the "original"
format;
So my comments about V2 were wrong. :(
------
Be that as it may: I tried using the heuristic from the utp.cpp code to
differentiate.
inline bool UTP_IsV1(PacketFormatV1 const* pf)
{
return pf->version() == 1 && pf->type() < ST_NUM_STATES && pf->ext < 3;
}
The heuristic doesn't differentiate the frames in the capture since most of the
frames which I suspect are actually "V0" satisfy the heuristic for V1 and thus
dissect (incorrectly) as V1.
If I add a hack to the heuristic to also check the lengths of the frames with
or without extensions, then the heuristic seems to work and the "V0" frames are
dissected in a better fashion in that no "malformed" or otherwise bad frames
are found. (The values for some of the fields still look a little weird).
I'm inclined to commit the somewhat hackish heuristic until something better is
found.
------
Re: The field is inverted ?
Given the convention used in RFCs used for packet diagrams [1][2], I certainly
would interpret BEP-29 as indicating that the 'version' is in the HO 4 bits.
However, given the utp.cpp code, I agree with your interpretation; (Good
catch!)
[1] http://tools.ietf.org/html/rfc2360: section 3.1
[2] http://en.wikipedia.org/wiki/Bit_numbering
[Extract]
...
MSB 0 bit numbering
MSB 0:A container for 8-bit binary number with the highlighted most significant
bit assigned the bit number 0
Similarly, when the bit numbering starts at zero for the most significant bit
the numbering scheme is called "MSB 0".
Usage
...
The recommended style for Request for Comments documents is "MSB 0" bit
numbering.
...
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
