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 |
2 Answers:
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 Harris ♦♦ |
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]
answered 22 Jun '14, 22:48  mrEEde 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 |
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.