Ask Your Question
0

Google Chrome TCP Retransmission

asked 2020-04-01 04:02:47 +0000

max gravatar image

updated 2020-04-01 09:40:30 +0000

grahamb gravatar image

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 ...
(more)
edit retag flag offensive close merge delete

Comments

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?

grahamb gravatar imagegrahamb ( 2020-04-01 09:41:37 +0000 )edit

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...

max gravatar imagemax ( 2020-04-01 10:54:00 +0000 )edit

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:

eth.src == 54:55:58:10:00:37 || arp
Jim Young gravatar imageJim Young ( 2020-04-01 12:16:04 +0000 )edit

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)

max gravatar imagemax ( 2020-04-01 14:43:18 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-04-01 12:28:35 +0000

SYN-bit gravatar image

In your capture file there are broadcast packets for 192.168.1.255, so I assume your subnet-mask is 255.255.255.0.

Just before the prototype (192.168.1.5) stops responding to the SYN packets of 192.168.1.50, there are 3 ARP requests for 192.168.2.50. When the subnet mask is 192.168.2.50, there should not be an arp for systems in 192.168.2.0/24. As after 3 ARP packets for 192.168.2.50 there are no responses to 192.168.1.50 anymore, I suspect that the ARP requests for 192.168.2.50 in reality should have been ARP requests for 192.168.1.50.

You might want to look into the networking code of the prototype to see if there is an off-by-one error in the code that is responsible for creating the ARP requests.

edit flag offensive delete link more

Comments

S: In your capture file there are broadcast packets for 192.168.1.255, so I assume your subnet-mask is 255.255.255.0.

M: Yes you are right.

S: Just before the prototype (192.168.1.5) stops responding to the SYN packets of 192.168.1.50, there are 3 ARP requests for 192.168.2.50

M: Yes this is a bug in the code, It should not reflect in the network log. To be exact, this prototype has 2 ports for redundancy. Wherein the other port's default IPadd is 192.168.2.5. The other port is connect to MS Edge but it did not capture any problem.

Do you think this might have caused the communications error between chrome and the prototype? The first ARP happened @ 421704 but the communications is still OK. 2nd ARP happened 10 seconds after but communications is still OK ...(more)

max gravatar imagemax ( 2020-04-01 14:55:54 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-04-01 04:02:47 +0000

Seen: 99 times

Last updated: Apr 01