Wireshark-bugs: [Wireshark-bugs] [Bug 1586] Problems with reassembly for proxied SSL connections
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1586
sake@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sake@xxxxxxxxxx
------- Comment #2 from sake@xxxxxxxxxx 2007-05-04 04:43 GMT -------
I pulled a Netapp NetCache from the shelf and configured my browser to use it
as proxy. The same "[Malformed Packet]" frames are seen with the NetCache
proxy.
Looking at the trace-file, I see that the first frame that has the maximum
segment size (1260 in this case, resulting in a 1260+20+20+14=1314 bytes frame)
is showing up as malformed, the following frames are showing up as "[unknown
record]" since they start in the middle of a SSL-record. As soon as a new full
SSL-record is seen in a frame that is not as large as the MSS, SSL-dissecting
is picked up normally. To me this sounds like a reassembly issue.
Looking at the code of the http-dissector, I can see that the http-dissector
does re-assembly by a loop in "dissect_http()". It calls
"dissect_http_message()" and collects more data if needed by
"dissect_http_message()". I suspect that this function is collecting all the
necessary data before the SSL dissector is called in
"http_payload_subdissector()". This function calls "dissect_tcp_payload()" when
it knows the payload is actually another protocol (like SSL in this example).
The dissection of the transported protocol is usually called directly from the
tcp-dissector and not through the http-dissector. I think this breaks the
re-assembly mechanism of setting the "pinfo->desegment_offset".
I tried to return -1 to "dissect_http()" so that it will collect more data, but
I could not find a way to tell "dissect_http()" how many bytes were succesfully
dissected (which is needed for the loop to work).
I also tried to skip the http-dissection altogether by first checking if we in
fact are dissecting a proxied connection. Unfortunately that didn't work
either.
So I'm a bit stuck now on how to solve this. Maybe it's better to make a
seperate http-proxy-dissector that hands off further dissection to either http
or tcp_payload.
Unfortunately I think I'm in a little over my head with this bug, so if someone
could direct me in the proper direction? Or if someone else could fix this bug,
that's fine too :)
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.
