Problem with TCP handshake

TCP-Handshake

asked 2023-02-24 08:32:00 +0000

kaj
1

updated 2023-02-24 09:46:40 +0000

SYN-bit

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

Hi Everyone.

please see below info from wireshark (I can't add a screen, sorry). This is communication beetween PLC and kepware server. The configuration is such that when an external client needs data from the PLC, it sends a request to the server. The server queries the PLC and forwards the requested data to the client. The client does not have direct access to the PLC. Few times per day we have problem with frozen ports, and on this info below you can see the reason. Please help with interpretation and possible reasons. As you can see, server started handshake to finish transmission, didn't get respond from host. Why it started new transmission with different port ? It's possible, that server got question from another client and start new transmission without ending previous session? Shouldn't it retransmit the packet instead of starting a new session? In new session it changed port and everything fell apart. What can cause such errors?

Serwer  PLC TCP 64  **56948** → 8090 [FIN, ACK] Seq=101 Ack=1570 Win=64227 Len=0

Serwer  PLC TCP 70  **56959** → 8090 [SYN, ECE, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM
58413   58:54,1 

PLC Serwer  TCP 64  8090 → 56959 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
58414   58:54,1 

PLC Serwer  TCP 64  [TCP Previous segment not captured] 8090 → 56948 [FIN, ACK] Seq=1571 Ack=102 Win=4096 Len=0
58415   58:54,1 

Serwer  PLC TCP 64  [TCP Dup ACK 58410#1] 56948 → 8090 [ACK] Seq=102 Ack=1570 Win=64227 Len=0
58416   58:54,1 

PLC Serwer  TCP 64  8090 → 56948 [FIN, ACK] Seq=1572 Ack=102 Win=4096 Len=0

edit retag flag offensive close merge delete

add a comment

answered 2023-02-24 09:59:47 +0000

SYN-bit

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

From the (very limited) data you provided, I could deduct that the PLC seems to be counting a phantom byte for each retransmission of the FIN it sends. I assume there was a FIN before with SEQ=1570 which was not captured (as can be seen with the line with "[TCP Previous segment not captured]"). It seems the server also missed that packet (lost on the network somewhere? Do you see errors on the switch port to which the PLC is connected?). Since the retransmission of the that FIN packet has a sequence number of 1571 instead of 1570 it is not processed and the session can not be properly terminated.

Can the PLC handle multiple TCP connections? If not, it is logical that the new session is rejected with a RST. If it could handle more TCP connections, maybe there were too many hanging sessions and it can't handle an extra one.

To properly troubleshoot this, you would need to analyze the traffic over a longer period of time. But for starters, I would raise a support ticket with the PLC vendor to see if this (the increasing SEQ for FIN retransmissions) is a known issue and if they already have a new firmware with a fix for it.

Comments

If you are able to share an (anonymized) trace of a longer time period on a public file-share, that would help in helping you :-)

See: https://blog.packet-foo.com/2016/11/t...

SYN-bit ( 2023-02-24 10:08:32 +0000 )edit

add a comment

Your Answer

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

Problem with TCP handshake

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Problem with TCP handshake edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Problem with TCP handshake