I have a scenario where a Modbus Master is polling a slave using Modbus TCP. A session is established, and then the Slave / PLC inadvertently sends a Fin,Ack and ends the Session before the Modbus Request is sent. I have looked through the packets looking at Timing , thinking that it is a timeout issue, looking for un-expected ACK's or something like that, but nothing is apparent. I was wondering if anyone has had similar issues and could point me in the correct direction? What could cause the slave / server to end the session? The Master is at Port 3172 TCP: 3172 → 502 [SYN] Seq=0 Win=512 Len=0 MSS=532 TCP: 502 → 3172 [SYN, ACK] Seq=0 Ack=1 Win=512 Len=0 MSS=532 TCP: 3172 → 502 [ACK] Seq=1 Ack=1 Win=512 Len=0 TCP: 502 → 3172 [FIN, ACK] Seq=1 Ack=1 Win=512 Len=0 Modbus/TCP: Query: Trans: 101; Unit: 1, Func: 5: Write Single Coil asked 15 Dec '15, 15:48  Little Sqrt edited 17 Dec '15, 11:08  grahamb ♦ |
2 Answers:
Check out this blog post: https://blog.packet-foo.com/2014/01/tcp-server-slamming-the-door/ I'm not sure how much of it applies to Modbus, but it looks like a classical "no, you're not in my list of IPs I can talk to" aborts. answered 16 Dec '15, 04:12  Jasper ♦♦ edited 16 Dec '15, 04:13 Thanks Jasper, turns out that the PLC(server) is setup to receive Modbus requests from a particular port and IP, if it doesn't match, then it terminates the session. (17 Dec '15, 10:17) Little Sqrt |
It turns out that the PLC (Server) is programmed to accept requests from a particular Port number. Consequently, I think that Jasper hit the nail on the head. The thing that we can't figure out, is why the SRC Port numbers are incrementing upon each successive session?? https://www.dropbox.com/s/whb0h1r55mn15cr/Server_Terminating_TCP_Session.pcapng?dl=0 Here is the code if you want to have a look. answered 17 Dec '15, 10:24 Little Sqrt This is a different question (and definitely not an answer to the existing one), so you should either raise it as such yourself or confirm that I may convert what you've just written into a new question. But to give you the response quickly, using a different source tcp port when creating a new session is a normal client behaviour, as the pair of client and server sockets (ip:port) is the only identifier of the session to which a given packet belongs. So after closing one session, it is a good idea not to reuse the same socket pair for new sessions for some time, otherwise arrival of a delayed packet from the previous session could confuse the current session. So after re-reading what you wrote (that the PLC expects the tcp requests to come from a single remote port), I wonder what were the reasons of the author of the PLC software (configuration?) to do so. (17 Dec '15, 11:00) sindy |
We can't really help by just looking at your text excerpts of the TCP header details of the traffic. You haven't even shown the TCP header from the packet with the request.
Please post the actual capture somewhere publicly accessible, e.g. Google Drive, Dropbox etc.