http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1503
sake@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sake@xxxxxxxxxx
------- Comment #1 from sake@xxxxxxxxxx 2007-03-31 14:44 GMT -------
(In reply to comment #0)
> SSLv2 packet header is interpreted badly: if I click on 'Length' field in SSLv2
> record wireshark will highlight 2 bytes in the 'Packet bytes' window but the
> value of the Length field is ok.
>
> In my case it is '80 7a'. The Length value is 122 (0x7a).
In case of SSLv2 handshakes, the length can be either 2 or 3 bytes. If
byte[0]&80==1, the length uses 2 bytes. If not, it uses 3 bytes. In your case,
the bit is set, so two bytes are used. This means the length is calculated as
follows: byte[0]&0x7f << 8 + byte[1]. Since both bytes are used in calculating
the length, both bytes are selected in the byte-pane. To me this looks like
correct behaviour.
> Also, what is missing is the 0x80 value being interpreted as SSLv2 handshake
> (content_handshake_v2 = 128 = 0x80)
Actually your packet is performing a TLSv1 handshake on top of a SSLv2
record-layer. There seems to be a little mixup in the names of fields/filters
and also some difference in how the SSLv2 and SSLv3 dissection-code are
handling things.
I will have a look into this.
Cheers,
Sake
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.