This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Continuation or non-HTTP traffic won’t produce HTTP

0

EDIT2:
I made another capture session and uploaded it to cloudshark.org
The GET request for which there is no HTTP response is frame 364
http://cloudshark.org/captures/c36979d903e0

Then I rearranged the frames in this sequence: ...-364-367-365-368-371-369-372-...
I removed frames 366 & 370. Here's the result:
http://cloudshark.org/captures/5003ae96ae6b

Both captures need SSL keys:
http://pastebin.com/DMcFKW2p


EDIT1:
Following up on SYN-bit's response, I rearranged the out-of-order packets using editcap and mergecap, but the "continuation" issue still persists.
http://imgur.com/NpiXqXw
Notice the 5 packets 365-369 are not in chronological order as the result of re-arranging.
I applied all Landi's suggestions to this new pcap file, to no avail.

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.
END OF EDIT1



I'm doing a simple action:
With wireshark running,
I go to https://www.google.com and then click "Blogger" in the upper bar.

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".
But all I see in wireshark is that right after my GET request for that "Blogger page", I only get "Continuation or non-HTTP traffic".
After that wireshark shows that the browser starts GETing the PNGs and GIFs contained in the "Blogger page" and wireshark successfully recognizes them as PNGs and GIFs.
But wireshark won't dissect the very first HTML page.

P.S. I'm using Firefox with SSLKEYLOGFILE and wireshark successfully decrypts SSL.

P.P.S Here is the relevant screenshot:
http://imgur.com/plp6SRT
Notice the GET request in frame 708
And the GET request in frame 732, which is a PNG linked to from the HTML file that wireshark couldn't dissect

asked 19 Jul '13, 07:26

dansmith's gravatar image

dansmith
16448
accept rate: 50%

edited 19 Jul '13, 13:19


3 Answers:

3

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's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

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.

(19 Jul '13, 08:39) dansmith

You could just try to apply the patch and see what happens.

(19 Jul '13, 09:54) grahamb ♦

Sorry to unmark your response as accepted, but I rearranged the packets and my initial issue persists

(19 Jul '13, 10:06) dansmith

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)?

(19 Jul '13, 11:43) SYN-bit ♦♦

Thanks, I updated my OP with relevant cloudshark links.

(19 Jul '13, 13:21) dansmith

see my edited answer

(20 Jul '13, 04:21) Landi

In the rearranged capture file I can finally see my HTML in frame 406.

(20 Jul '13, 09:43) dansmith
showing 5 of 7 show 2 more comments

0

EDIT

I downloaded your newcap trace and I perfectly see the HTTP Response code like expected

See http://imgur.com/Hnjhr6r

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's gravatar image

Landi
2.3k51442
accept rate: 28%

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

0

After amalgamating SYN-bit's and Landi's answers, I realized that:

We've got 3 relevant preferences:
1. Allow subdissector to reassemble TCP streams
2. Reassemble SSL records spanning multiple TCP segments
3. Reassemble SSL Application Data spanning multiple SSL records

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's gravatar image

dansmith
16448
accept rate: 50%

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