| 2023-05-18 12:27:16 +0000 | received badge | ● Famous Question (source) |
| 2022-04-08 08:07:35 +0000 | received badge | ● Notable Question (source) |
| 2022-04-08 08:07:35 +0000 | received badge | ● Popular Question (source) |
| 2021-05-04 06:56:15 +0000 | commented answer | TCP Dup ACK after reconnection - sequence number problem? Thanks for the answer and for pointing out how to fix the capture time shift. The client is a PLC which uses TwinCAT. On |
| 2021-05-03 07:12:07 +0000 | answered a question | TCP Dup ACK after reconnection - sequence number problem? It appears that my capture was too short in time. And apparently there were no major bugs in the TCP stacks. Server si |
| 2021-05-03 06:14:33 +0000 | marked best answer | TCP Dup ACK after reconnection - sequence number problem? Hi there, currently I'm debugging the network traffic between two devices in the same network. The network architecture is quite simple. Device 1 <-> Switch 1 <-> Switch 2 <-> Device 2 To verify the software on the devices, I check different scenarios. One of them is the correct reconnection after I unplugged the network cable between Switch 1 and Switch 2 and plugged it in again after few seconds. I uploaded a wireshark capture to my onedrive: Wireshark capture Packets 1-9 are correct communication. Between Packet 9 and Packet 10 the cable is unplugged. In Packet 10 Device 1 tries to send data to Device 2 without receiving ACK. In Packets 11/12 Device 2 sends Keep-Alive messages. Between Packet 12 and 13 the cable is plugged in again. Packet 13 ACKs the last Keep-Alive message, which seems fine. From now on, it gets weird. I only see TCP Dup ACK messages. I assume that the TCP stacks get confused on the difference in the sequence numbers. While Device 1 thinks it's own sequence number is 49, Device 2 thinks it is 37. Device 1 does not support Fast Retransmission. Can someone explain what is happening here? I'm struggeling to understand where the problem is. Is the problem in Device 1 where the TCP stack thinks it is on sequence number 49 while the package is not yet acknowledged or is it in Device 2? I really appreciate your help. Kindly, Philipp Post answer captures: ServerCapture_reconnection_after_unplugging_cleaned.pcapng ClientCapture_reconnection_after_unplugging_cleaned.pcapng |
| 2021-05-03 06:14:33 +0000 | received badge | ● Scholar (source) |
| 2021-04-29 12:20:56 +0000 | commented answer | TCP Dup ACK after reconnection - sequence number problem? I'll try to investigate if there have been other Keep-Alive messages. Would it be a valid behaviour if the TCP/IP stack |
| 2021-04-29 12:10:46 +0000 | commented answer | TCP Dup ACK after reconnection - sequence number problem? @grahamb Exactly, device 1 is the client, device 2 is the server. I'll try to get another capture to see if there are pa |
| 2021-04-29 08:24:55 +0000 | commented answer | TCP Dup ACK after reconnection - sequence number problem? Thanks for sharing your thoughts. Let me better explain the capture settings. 1. Device 1 <-> Switch 1 <-> |
| 2021-04-29 07:26:04 +0000 | commented question | TCP Dup ACK after reconnection - sequence number problem? That is correct. For both devices the link is still up. The application has a timer. But the time the cable was unplugge |
| 2021-04-29 06:08:32 +0000 | asked a question | TCP Dup ACK after reconnection - sequence number problem? TCP Dup ACK after reconnection - sequence number problem? Hi there, currently I'm debugging the network traffic between |
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.