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

Unreadable data in “Follow TCP stream”

0

Hi all, I am new to using wireshark. I captured network activity while loading a simple text based webpage and selected the option "Follow TCP data". I can see the HTTP request and response in plain text, but the data part is completely scrambled. It is simple http request so I expected the data part to be readable as well. Where am I going wrong? Please let me know.

asked 15 Dec '14, 11:27

nckr's gravatar image

nckr
16●1●1●4
accept rate: 0%

One Answer:

2

The HTTP response is most certainly using compression, like the example below:

As "Follow TCP Stream" does not support HTTP decompression, you won't see the HTTP response in cleartext. We would need something like "Follow HTTP Stream", which does not yet exist.

You can look at the response in cleartext within the packet bytes pane and the packet details pane, as the HTTP dissector does decompression of the HTTP data.

GET / HTTP/1.1
Host: www.apple.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Accept-Encoding: gzip, deflate, sdch

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Content-Encoding: gzip   <======================== HERE !!!!
Content-Length: 2584
Cache-Control: max-age=471
Expires: Mon, 15 Dec 2014 20:10:33 GMT
Date: Mon, 15 Dec 2014 20:02:42 GMT
Connection: keep-alive
Server: Apache


………….r……8.L.ND.r..J..9.6m.{,gz…H.B….J.d2s……F……H..e9….........w..O.&gt;\......3..r..\...1.q.-....YO.4..z.*.E.......a....8 .I.........OG.E/cQ........sp.9.d.P........L....F.$....&#39;..I..X....wR...7y..D.s.(.2 ..O.l..9.Yh&#39;].sn8.....~…..O%…..'…
j.D…7g……7g?t.L_y"..7D11..Y
.g..43.J.W……s.b.E4.R!'T.n…….n..b..b…..[..9p…..FV5..M…J.L..0.9.K.c..E..
……FWt.T.].t.v.s&.Df2c…..o…o….{.2.a.v…J..N…..wW…O..}i.mC….C.lz.k.c…e….i…..o..C…l..a[..x..X7.F.:.h..].n…..S….qyL……-.L….r<..
2..>…k..=.c…c..+/.=……)Z..).GG?Ni..r.v.8M…yz…hV.e..r=.e,..u!……&7U..ioRra.&..8Y>M&.?……0p..h.?H3……..c..G:..+X.YG….].n..D&K…………..r:'<…+(….J.{…R..(x

Regards
Kurt

answered 15 Dec ‘14, 12:07

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 15 Dec ‘14, 12:11

If I select a single TCP packet and look at its TCP segment data (which in my case has 1452 bytes), in the packet details pane, it has 4 columns. Is the 4th column ASCII representation of the data? If so is it clear text or still some compressed form for a simple http request? I expected it to be clear text since it is not https, but it looks scrambled as well.

(16 Dec ‘14, 01:02) nckr

If I select a single TCP packet and look at its TCP segment data

please select the frame with the HTTP response in the info column, as that’s the frame where the HTTP dissector has seen all TCP segments required to re-assemble the whole HTTP response and where it is able to do decompression.

If you select the TCP segment data in that frame, you will still only see compressed data!!

alt text

However, if you select the HTTP data (or the reassembled TCP segments), you should see the HTTP response in cleartext. See also the tabs at the bottom of the window.

As the HTTP response can spread over several TCP segments (as in my example), that’s how the HTTP dissector (in combination with the TCP dissector) shows the combined data of the response.

alt text

Regards
Kurt

(16 Dec ‘14, 02:32) Kurt Knochner ♦

Thanks a lot for your response! I am now able to see the uncompressed data in clear text!

(16 Dec ‘14, 07:56) nckr