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

Follow TCP Stream - Stream Content Empty

0

On running a capture between a client and a webserver I've noticed that there are 4 TCP handshakes between the two devices. I sort of get this due to the way web browsers handle chunked data (Google sort of explained this to me).

What I don't get is: once the first handshake has completed and the connection has been established, If I follow this TCP stream then I can see what's going on between the client and the server.

However, any subsequent connections' TCP streams, and there are 3 of these, are empty. My question, at this point, is, why are the other 3 TCP streams empty?

This question is marked "community wiki".

asked 06 Nov '15, 04:05

joewoody's gravatar image

joewoody
6●2●2●3
accept rate: 0%

There is another interesting thing in the trace. But it is a little bit out of topic, I think. The client does not advertise a MSS in the SYN packet. Fot that kind no Ethernet Frame is larger than 590 byte.

(09 Nov '15, 15:12) Christian_R

One Answer:

0

My question, at this point, is, why are the other 3 TCP streams empty?

most certainly because the was no data transmitted in those streams. But it's hard to tell without a pcap file. Is it possible to upload the file somewhere (google drive, dropbox) and to post the link here?

Regards
Kurt

answered 06 Nov '15, 05:19

Kurt%20Knochner's gravatar image

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

https://drive.google.com/file/d/0B6vUPsqTPCf8ay1vcG1tZXlLZDg/view?usp=sharing

Tried to replicate today. The file in the link above, if my undersatnding is correct, contains 3 TCP handshakes - 2 of whose TCP streams appear to be empty. If the streams contain no data, then why would the connection attempts take place in the first place? This, unless i'm completely wrong, doesn't seem correct.....

Regards JW

(09 Nov '15, 05:15) joewoody

As I thought, there no data in the TCP streams, except 'tcp.stream eq 0'. The other streams contain the 3-way handshake (SYN,SYN-ACK,ACK) only.

then why would the connection attempts take place in the first place?

Wireshark is a network troubleshooting tool that can help you to show what is on the network. It has no magic inside to tell you why something happens ;-)

From what I can see in the capture file:

  • There is a Watchguard Firewall involved
  • There are 5 TCP connections
  • 4 of these connections contain only a 3-way handshake.
  • source ports are counting up

This, unless i'm completely wrong, doesn't seem correct....

Maybe or maybe not. I can only speculate:

  • If you have taken the network capture on the Firewall and the firewall has something like hardware offloading/acceleration you will only see those frames that hit the CPU, which is usually the 3-way handshake. I can't tell you why it's different for the first stream, because I don't know your environment.
  • the external system might have opened several connections but in 4 of them it did not send any data (GET/POST request). Reason unknown.
  • Something is wrong with the capturing system, so it only captured the 3-way handshake
  • The rest of the TCP streams data took a different route and thus the capturing system did not see it. However I can't tell you why, because I don't know your environment.
  • There is some kind of service check configured on the firewall, that tries to figure out if port 80 is still reachable on 172.16.1.11 and it uses a 3-way handshake to check that
  • Any other possible reason ;-)

Regards
Kurt

(09 Nov '15, 14:59) Kurt Knochner ♦