Spurious Retrasmissions false?

asked 2024-07-18 08:45:39 +0000

nanass
3 ●1 ●1

I have two devices, a modbus client (10.32.0.131) and a modbus server (10.32.43.32). I have captured the conversation between them at the client end and at the server end. What I see is on the client end capture everything is normal without TCP retransmissions, however on the server side end I see spurious retransmissions. Checking, it seems that in the server-side capture wireshark sees the ack before the tcp query, so it marks the ack as ACked unseen segment and the tcp query as Spurious Detrasmissions. If I remove the option to Analyze tcp sequence numbers, I see the ack before the query as before but this time without tcp spurious retrasmissions. My question is why this can happen and if it is a false false positive spuria retransmission. What is your opinion? Thank you.

edit retag flag offensive close merge delete

Comments

Can you describe the server side capture setup? As the communication apparently works it would appear this is an artefact of the capture.

grahamb ( 2024-07-18 08:57:26 +0000 )edit

Yes, the communication works, I filter by follow tcp stream. And on the server side I first see the server's ack for the client's query, then I see the client's modbustcp query and finally the server's modbus tcp response.

nanass ( 2024-07-18 09:21:08 +0000 )edit

So what does the capture setup \ environment look like?

grahamb ( 2024-07-18 10:22:02 +0000 )edit

add a comment

answered 2024-07-18 10:59:24 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

Wireshark marks a packet as a spurious retransmission when it sees a TCP segment that falls within already acknowledged data. As you say you do not see retransmissions on the client side, the data was only sent once. So the only explanation is that somehow the capture setup on the server side records the outgoing ACK before it records the incoming TCP data segment that generated that ACK.

Did you take a look at the timestamps? if the timestamp of the ACK is higher than the timestamp of the TCP data segment, then at least the packets were seen in the correct order, they just were recorded in another order on the file. I've seen this happening when using a passive TAP which outputs each direction to a separate capture interface. You can fix this by running reordercap on the file (included in the Wireshark installation).

edit flag offensive delete link

Comments

Thanks for your comment, according to the timestamp the order would be correct, but it is true that the difference is microseconds, so I understand that it is so minimal that it may be recorded in the wrong order in the file.

10:59:56,635213 is the timestamp for ACK 10:59:56,635300 is the timestamp for TCP

nanass ( 2024-07-19 05:33:13 +0000 )edit

Good to see that my assumption about the timestamps was right, it proves that the packets were in order on the network and the way the packets are captured is responsible for the TCP analysis messages.

The question of how you are capturing the packets (on the host, by a spanport, using a TAP, etc) and how that influenced the reordering the packets in the capture process. Can you shed a light on the way you are capturing the packets?

SYN-bit ( 2024-07-19 06:35:13 +0000 )edit

I am capturing the packets using port mirror on the switches, a port mirror with a pc with wireshark on the client side and another port mirror with another pc with wireshark on the server side.

nanass ( 2024-07-19 06:40:22 +0000 )edit

Are you mirroring RX and TX to separate interfaces on the Wireshark PC, capturing on both interfaces? If so, could you try mirroring to one interface?

SYN-bit ( 2024-07-19 08:24:05 +0000 )edit

Actually I am capturing on the client side switch, Tx and Rx from the client port to the pc with wireshark. On the other hand, I am capturing on the server switch, Tx and Rx from the server port to the other PC with wireshark.

nanass ( 2024-07-19 09:08:08 +0000 )edit

add a comment

Spurious Retrasmissions false?

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Spurious Retrasmissions false? edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Spurious Retrasmissions false?