EDIT2: Then I rearranged the frames in this sequence: ...-364-367-365-368-371-369-372-... Both captures need SSL keys: EDIT1: The "continuation" still continues to the end of the capture file. Before I interrupted the capture, the last frame with "continuation" had TCP relative Seq. on 26024, which means there was roughly 26K worth of data from the server. And yet, no HTML was dissected. I'm doing a simple action: I'm expecting to see in wireshark: HTTP/1.1 200 OK (html/text) for the page that shows up in the browser when I press "Blogger". P.S. I'm using Firefox with SSLKEYLOGFILE and wireshark successfully decrypts SSL. P.P.S Here is the relevant screenshot: asked 19 Jul '13, 07:26  dansmith edited 19 Jul '13, 13:19 |
3 Answers:
THe problem is that the first segment of the HTTP response is received out-of-order. Since re-assembly is being initiated in the first frame that wireshark sees, it is not able to determine how to re-assemble this response. There are a couple of related bug reports on bugzilla: answered 19 Jul '13, 08:22  SYN-bit ♦♦ showing 5 of 7 show 2 more comments |
EDIT I downloaded your newcap trace and I perfectly see the HTTP Response code like expected Like said - be sure to turn off Reassembly then you'll see the return code right after the GET in frame 365, otherwise it will appear in frame 406. Mind to EITHER turn reassambly completely ON (TCP plus both settings inside SSL prefs) of OFF (again TCP plus both settings in SSL Prefs) <<< end of edit >>> It does but you have TCP segment reassembly turned on by default which is why wireshark waits until the whole data block is successfully transmitted before dissecting it as a whole. Just turn of TCP stream reassembly in the TCP protocol prererences and you're fine. answered 19 Jul '13, 07:29  Landi edited 20 Jul '13, 04:21 Unfortunately your suggestion didn't work. Right clicking a TCP frame->Protocol Preferences-> unchecking Allow subdissector to reassemble TCP streams followed by screen reload didn't produce new HTTP OK's (19 Jul '13, 08:01) dansmith could you please try filtering for a single TCP Session by right-clicking a GET request where you don't see the HTTP OK and then selecting Conversation Filter -> TCP and check again (19 Jul '13, 08:12) Landi Unfortunately, Conversation Filter didn't help either (19 Jul '13, 08:36) dansmith |
After amalgamating SYN-bit's and Landi's answers, I realized that: We've got 3 relevant preferences: I tried multiple combination of the 3 switches. In order to see "HTTP/1.1 200 OK [Unreassembled Packet]" in frame 365 of the re-arranged capture, one only needs to disable 3 (whether 1 and/or 2 is on/off doesn't matter) But the issue remains - wireshark still won't dissect the HTML file from the chunked HTTP frames. I guess it is because wireshark expects a final chunk of size 0, but google never sends the chunk with size 0. answered 20 Jul '13, 06:12 dansmith what exactly do you mean by "won't dissect" what are you trying to accomplish?? Sorry I don't get it... like in my screen shot at my wireshark it dissects each single data packet as http (20 Jul '13, 06:29) Landi Stream 30 in the re-arranged capture file does have a final chunk of 0 in frame 406, with all re-assembly options enabled at the TCP, SSL and HTTP layer, I get a normal "HTTP/1.1 200 OK" response in frame 406. (20 Jul '13, 07:01) SYN-bit ♦♦ Yes, the HTML part in frame 406 of the rearranged capture is what I wanted all along. I'm simply mystified how I wasted the whole day not seeing it. (20 Jul '13, 09:40) dansmith |
SYN-bit, any ideas if the patch in Bug 5971 can be adapted to the current version of wireshark? I could do it myself. I just need a confirmation that the code hasn't changed too drastically since 2 years ago when the patch was submitted.
You could just try to apply the patch and see what happens.
Sorry to unmark your response as accepted, but I rearranged the packets and my initial issue persists
No worries. Do the packets contain sensitive data? If not, could you upload the faulty session to www.cloudshark.org and post the link here (together with the SSL session key for that particular SSL session)?
Thanks, I updated my OP with relevant cloudshark links.
see my edited answer
In the rearranged capture file I can finally see my HTML in frame 406.