This is not a direct Ignition problem, but maybe one of the networking experts or Linux gurus in this forum has an idea:
I am running an OPC-UA server on a Linux (Debian Stretch) VM under HyperV. This server polls some modbus devices. The devices of one single brand show a special tcp protocol behaviour by sending a PSH,ACK packet before the modbus answer:
|36|16.083837|10.209.10.14|10.209.61.201|Modbus/TCP|66| Query: Trans: 8; Unit: 1, Func: 3: Read Holding Registers|
|37|16.084226|10.209.61.201|10.209.10.14|TCP|60|502 → 34736 [PSH, ACK] Seq=105 Ack=109 Win=1460 Len=0|
|38|16.085185|10.209.61.201|10.209.10.14|Modbus/TCP|67|Response: Trans: 8; Unit: 1, Func: 3: Read Holding Registers|
|39|16.085209|10.209.10.14|10.209.61.201|TCP|54|34736 → 502 [ACK] Seq=109 Ack=118 Win=29200 Len=0|
After a number of packets (between 1 and 25) the PSH,ACK packet from those devices is lost somewhere between the HyperV host and the Linux VM (Other modbus devices on the same server don’t show this issue). A packet capture on an intermediate network switch show that the PSH,ACK and the modbus answer packets are actually send out by the device and the tcp retransmissions are marked as ‘spurious retransmission’ in that capture.
|44|20.104254|10.209.10.14|10.209.61.201|Modbus/TCP|66| Query: Trans: 8; Unit: 1, Func: 3: Read Holding Registers|
|45|20.314691|10.209.10.14|10.209.61.201|TCP|66|[TCP Retransmission] 34736 → 502 [PSH, ACK] Seq=121 Ack=131 Win=29200 Len=12|
|46|20.734691|10.209.10.14|10.209.61.201|TCP|66|[TCP Retransmission] 34736 → 502 [PSH, ACK] Seq=121 Ack=131 Win=29200 Len=12|
|47|21.566693|10.209.10.14|10.209.61.201|TCP|66|[TCP Retransmission] 34736 → 502 [PSH, ACK] Seq=121 Ack=131 Win=29200 Len=12|
|48|21.567033|10.209.61.201|10.209.10.14|TCP|60|[TCP Previous segment not captured] 502 → 34736 [ACK] Seq=144 Ack=133 Win=1241 Len=0|
|49|35.590454|10.209.10.14|10.209.61.201|TCP|54|[TCP Keep-Alive] 34736 → 502 [ACK] Seq=132 Ack=131 Win=29200 Len=0|
|50|35.590779|10.209.61.201|10.209.10.14|TCP|60|[TCP Window Update] 502 → 34736 [ACK] Seq=144 Ack=133 Win=1168 Len=0|
To make it even more interesting, an identical setup on another physical host shows the same effect but suddenly started to operate normally after updating the Windows Server to version 2019. The same update on the other system had no effect on the issue. Both system are running the same Windows and Linux version.
Has anybody ever experienced something like this or is there an idea what might be causing this?