Google Chrome TCP Retransmission
Hi I'm a new in Wireshark and im trying to study a certain transaction which caused a Network Error.
This set of packets occured after 6hrs 31mins of soaking google chrome overnight. Before 6 hrs and 31mins the trace is almost fine with very little abnormalities, wherein the communication between the client and the host does not break.
BTW, The device that google chrome is communicating with is a prototype communications module, so let me know if there's any problem caused by it.
communications module: 192.168.1.5 google chrome: 192.168.1.50
"1","0.000000","192.168.1.5","192.168.1.50","TCP","384","80 > 63364 [PSH, ACK] Seq=1 Ack=1 Win=532 Len=330 [TCP segment of a reassembled PDU]"
"2","0.000404","192.168.1.50","192.168.1.5","TCP","54","63364 > 80 [FIN, ACK] Seq=1 Ack=331 Win=64971 Len=0"
"3","0.001056","54:55:58:10:00:37","Broadcast","ARP","60","Who has 192.168.2.50? Tell 192.168.1.5"
"4","0.004033","192.168.1.5","192.168.1.50","TCP","60","80 > 63364 [FIN, ACK] Seq=331 Ack=2 Win=532 Len=0"
"5","0.004109","192.168.1.50","192.168.1.5","TCP","54","63364 > 80 [ACK] Seq=2 Ack=332 Win=64971 Len=0"
"6","0.550871","192.168.1.50","192.168.1.5","TCP","66","63366 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"7","0.801320","192.168.1.50","192.168.1.5","TCP","66","63367 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"8","1.010239","192.168.1.50","192.168.1.5","TCP","66","63369 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"9","3.550877","192.168.1.50","192.168.1.5","TCP","66","[TCP Retransmission] 63366 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"10","3.800935","192.168.1.50","192.168.1.5","TCP","66","[TCP Retransmission] 63367 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"11","4.012859","192.168.1.50","192.168.1.5","TCP","66","[TCP Retransmission] 63369 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"12","7.017225","192.168.1.50","192.168.1.5","TCP","66","63374 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1"
"13","9.546120","192.168.1.50","192.168.1.5","TCP","62","[TCP Retransmission] 63366 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1"
"14","9.796111","192.168.1.50","192.168.1.5","TCP","62","[TCP Retransmission] 63367 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1"
"15","10.007071","192 ...
Sigh, another wall of text. Can you share a capture file, use a public share such as Google Drive, DropBox etc. and post a link to the file back here?
Hi grahamb.
Let me know if you can access the link. You can scroll to packet 422073 to make it easier.
https://drive.google.com/file/d/1eKDU...
Is the "communications module" still functional after the onset of this issue? Could its TCP/IP stack have locked up?
192.168.1.5's packets are sourced from packets with ethernet address 54:55:58:10:00:37. There are no packets sourced from the communications module's ethernet address 54:55:58:10:00:37 after frame 422068. At frame 422096, a little over 36.45 seconds later, you will see the first of a number ARP packets sent on behalf of the "google chrome" host trying to (re-)discover the ethernet address for the host with ip address 192.168.1.5.
This display filter could prove useful:
Hi Jim.
J: Is the "communications module" still functional after the onset of this issue? Could its TCP/IP stack have locked up?
M: Since the communication module is in the prototype stage yet, according to the developer, he is deliberately putting the module in a hang up/ locked state so as we can filter out any problems. Its obvious because the network LED is not blinking when I checked it.
FYI: Its not yet clear whether the locked state happened during the occurrence of TCP retransmission because the test has been running for a long time so I don't have any clue as to when the connection dropped.
What I would like to understand is how and why is the lock event being triggered so we can do a fix.
J: There are no packets sourced from the communications module's ethernet address 54:55:58:10:00 ...(more)