Comment # 19
on bug 8239
from Manuel Hofer
(In reply to comment #18)
> (In reply to comment #17)
> > "FALSE" and let another dissector have a crack at it.
> for that to
> > work the dissector would have to see the initial packets of every sstp
> > session, because the "SSTP" string only appears once.
> to detect a already
> > established sstp session we would have to look at more bytes, which could be
> > rather inefficient (i'm not exactly familiar with the way wireshark handles
> > heuristic dissectors, i assume they are excuted for each packet that doesn
> > match anything else?).
>
> i dont think it would even be possible to safely
> > distinguish sstp from other protocols. if you look at the packet types
> > (http://msdn.microsoft.com/en-us/library/cc247417.aspx) there isn't anything
> > unique to the protocol, e.g. looking at the length field and comparing to
> > the bytes remaining in tvb isn't possible due to other protocols being
> > encapsualted in sstp.
>
> > any suggestions?
>
> What is the definition of a "SSTP session"?
the way the protocol works:
1. a tcp connection is established on port 443
2. tls connection established
3. client sends the HTTP message with the "SSTP" string (SSTP DUP_REQUEST or
something like that)
4. from this point on, only SSTP Control and Data packets are exchanged
> You may be able to use the
> "conversation API" mentioned in doc\README.developer, section 2.2. Perhaps
> the logic should be (pseudocode):
>
> if first 4 bytes == "SSTP"
> then create_conversation()
> dissect_sstp()
> return TRUE
> else if find_conversation("SSTP")
> dissect_sstp()
> return TRUE
> else
> return FALSE
yes, but this only works if wireshark saw the one initial packet with the
"SSTP" string as described above.
SSTP sessions that were already at an "established" state before the capture
was started, would simply not be recognized as such and therefore not
dissected.
You are receiving this mail because:
- You are watching all bug changes.