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

My Dropbox gets into loop and cannot sync, and I find lots of “ignored unknown records” in WireShark trace file. Can I find the root cause from the trace?

0

Hi everyone.

I have found that sometimes my Dropbox will get into loop and cannot sync when I try to upload a new file. So I try to use wireshark and tcpdump to capture packets at both client and router.

I observed that the Dropbox client may first open a TLS connection for transmission. But after a period this connection was terminated and the client opens a new connection again. However the new connection is closed again after several mins and the client again opens a new connection. That seems like a "transmission loop". So I could not sync my file to server.

Moreover, I could see lots of TCP retransmission and Dup ACK in my trace file so I could infer that there exists packet loss in the Internet. I hope to reveal what leads to the disconnection of data flow? Is there a timer to manage these sync flows? Why there are so many Ignored unknown records? Would these Ignored unknown records be the root cause of TLS disconnection?

The data flows I observed were: 1. 50.17.223.173(dstIP)-6759(srcPort), 2. 50.16.184.5(dstIP)-6772(srcPort),(re-transmission) 3. 23.23.227.100(dstIP)-6807(srcPort).(re-transmission)

And here are the trace files: 1. trace at client: https://www.dropbox.com/s/s1whav7v32k3ljq/trace-client.pcap 2. trace at router: https://www.dropbox.com/s/t595gtfp3sx9sjh/trace-router.pcap

Any one could help me? Thank you very much!!!!

asked 22 Jun '14, 19:23

lzq8272587's gravatar image

lzq8272587
26457
accept rate: 0%


2 Answers:

0

At least one "Ignored Unknown Record" was part of an out-of-order transmission, so that might just be an artifact of Wireshark's TCP dissection code not fully handling out-of-order packet (if segment N has the beginning of a TLS record, and segment N+1 has a continuation of that record, and segment N+1 is received before segment N, Wireshark won't reassemble them). I wouldn't worry about those.

However, you do seem to be getting a lot of out-of-order packets and retransmissions, so there might be an issue with your network connection causing packets to be lost; TCP tries to recover from that by the sender "timing out" if there's no acknowledgment from the receiver and re-sending the timed-out data, but even that can't help if the network is really lossy.

answered 22 Jun '14, 19:34

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Hi, Harris. Thank you very much for your comment!

So the "Ignored Unknown Record" was caused by the out-of-order transmission? In my case,I tried to upload a file, and I captured the packets at the client. I still observed the "Ignored Unknown Record" in client trace. Does it mean the TCP packet is out of order when uploading at the client side?

I could understand the receiver gets a out-of-order packet. I'm not sure the packets will out-of-order before sending.

(22 Jun '14, 19:46) lzq8272587

0

The packet loss is not in the internet, it is between the client and the router in the outbound direction.

I would check the device at [192.168.150.1|192.168.2.165]

alt text

answered 22 Jun '14, 22:48

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

Hi, mrEEde:

Thank you very much for your answer.

So the packet loss is between the link between my client and router. I still have a question: why there are so many packets with "Ignored Unknown Record" in the client trace file? Is that caused by the packet loss?

I hope to analyze the trace file and find whether it is the packet loss that leads to disconnection.

BTW, how can I set the ip-id column like you?

Thanks!

(22 Jun '14, 23:34) lzq8272587

Adding the column is easy: Select any field from the packet detail pane and right-click -> Apply as Column

(23 Jun '14, 00:04) mrEEde

If segments are seen that are missing the previous SSL record header, wireshark will not be able to reassemble those and flag them as Ignored... So this symptom is a result of lost packets

(23 Jun '14, 00:06) mrEEde