gazroo

Why does ML/1400 send a TCP [RST] ?

8 posts in this topic

Hi all,

I have my own driver to communicate with a MicroLogix 1400.

Please refer to the attached screenshot from Wireshark. 10.10.21.10 is my driver's host, and 192.168.1.192 is the ML1400.

The startup sequence to establish a connection & session with the PLC is correct I believe:

- In the grey highlight, client requests a connection to .192 via SYN and this is ack'd
- A session is registered, and forward open is successful
- There's a lot of stuff in green simply because I've also got an HTTP browser session open to the PLC to monitor its session table
- In between, spaced 8 seconds apart, are my two attempts to keep the connection alive by sending a List Identity request (as a ping, if you like). These are highlighted in pale blue.
- However, 16.5 seconds from the start of the grey highlight, and 16.4 seconds after sequence=115 ack=99, the controller sends back a [RST, ACK] and a callback from my socket code tells me that the session has been dropped.

The connection timeout for the PLC is configured as either 30 or 60 seconds, so I don't see how that's relevant here when the reset is happening only 17 seconds after it was established ?

However, presumably the PLC doesn't see the application-level "List Identity" request as a valid means of keeping the connection alive.

What is the correct mechanism to use that the PLC will accept as a keep-alive ?

Wireshark-Reset.PNG

1 person likes this

Share this post


Link to post
Share on other sites

I was going to write a bunch of stuff but decided at least one more test was needed.

With no other connection to the PLC, issue the register session and forward open. Then doing nothing.

How long before the PLC drops the connection?

 

Edited by Mark-

Share this post


Link to post
Share on other sites

Mark,

See whether you go with this idea, but I think there's a more obvious answer.

I've just realised that the List Identity is being sent as a UDP datagram. As such, there's no way it is ever going to act as a keep-alive for the TCP session !

It doesn't explain why the ML1400 is only waiting 17 seconds before it issues the RST, but I can worry about that later.

Do you agree ?

Gary

 

Share this post


Link to post
Share on other sites

Do the test.

Share this post


Link to post
Share on other sites
On 10/07/2020 at 4:34 PM, Mark- said:

I was going to write a bunch of stuff but decided at least one more test was needed.

With no other connection to the PLC, issue the register session and forward open. Then doing nothing.

How long before the PLC drops the connection?

 

Mark,

Apologies - I've only just got back on to this so I wasn't ignoring you ! And sorry that I might have jumped the gun when I talked about needing to send the NoOp as a means to prevent the TCP RST from taking place. See below.

I've stopped tweaking, and stripped the code back in the way you said, i.e. all that I do now is to register a session then Forward Open. That's it - I've taken out the NoOp device ping, and taken out any triggers that would cause the code to try to read or write any proxy tags configured in my driver.

I just wait, watch Wireshark, and watch a browser session onto the PLC so I can monitor the Encapsulated Session Table.

The first thing to report is that the TCP RST is no longer happening after 16 seconds. In fact it isn't happening at all now. It definitely used to -- I have absolutely no explanation why it has stopped. I've double-checked Wireshark and it is definitely no longer there.

Next thing that happens is that, after 60 seconds, the PLC session table shows the session transitioning from ACTIVE with 1 x CIP Cnx to ACTIVE with 0 x CIP Cnx. This is now starting to make sense, because the PLC was configured for a 60 second Ethernet connection timeout via the relevant setup tab in RS Logix.

Thirdly, I can see that the PLC is now sending me a [TCP Keep-Alive] every 45 seconds like clockwork. It never used to do this. I'm sending back [TCP Keep-Alive ACK] but not deliberately from my own code -- something much lower down my comms stack must be doing that on my behalf (not that it really matters).

So that answers your request for test results.

One final observation. After I completed the above tests, I put the repeated NoOp request back into my code -- TEMPORARILY. Wireshark shows it gets sent every 8 seconds to the PLC, as before. However, NOW, it's having absolutely no effect! In other words, the connection goes inactive after 60 seconds, with or without the repeated NoOp.

Concluding question

Presumably, you would argue that the above now seems more like what you would expect to happen ? So I think my only remaining question is this: what is the CORRECT method for ensuring the session doesn't go inactive after that configured interval (60 seconds for my PLC here) ? Since the TCP-level NoOp appears not to have an effect any more, should it be a connected or unconnected request ? Should I assume I can read a well-known tag such as N7:0 (which sounds prone to error) or is there a better approach ?

Thanks

Gary

Share this post


Link to post
Share on other sites

Yeah the "keep-alive" at the TCP level and the "watchdog/keep-alive" at the CIP level are different.

I guess the first question is why keep a polling/response type connection active/open unless it is used. That was rhetorical.

Leave the TCP level to itself and only work at the CIP level because that is what is timing out.

Did you retry the "List identity" command?

 

Share this post


Link to post
Share on other sites
On 14/07/2020 at 9:05 PM, Mark- said:

Yeah the "keep-alive" at the TCP level and the "watchdog/keep-alive" at the CIP level are different.

I guess the first question is why keep a polling/response type connection active/open unless it is used. That was rhetorical.

Leave the TCP level to itself and only work at the CIP level because that is what is timing out.

Did you retry the "List identity" command?

 

Mark,

Many thanks for the reply.

I temporarily re-inserted a ping every 8 seconds to send "List Identity". This turned out NOT to stop the session from going inactive after 60 seconds and I think Wireshark explained why: the protocol column shows 'ENIP' rather than 'CIP' for that packet, whereas presumably the PLC needs to see a CIP-level incoming request before it will reset its 60-second timeout.

I took out the List Identity and in its place sent a read tag request every 8 seconds for N7:0. This does now prevent the session from going inactive (probably no surprise there !!).

So, question: are there any CIP-level commands that would be suitable alternatives to a tag read as a CIP watchdog mechanism ? In this respect, one customer asked if we could add some configuration to our driver to allow them to choose which tag to read as a watchdog (in case N7:0 doesn't exist on any given PLC). This seems overkill, and it could well be that it actually doesn't matter if N7:0 doesn't exist (as long as the tag read request just gets through to the PLC, since I don't need/want to read the response). I'll test this approach next -- however, if there's a neater alternative to a tag read you can suggest, could you let me know ?

Appreciate your help.

Share this post


Link to post
Share on other sites
2 hours ago, gazroo said:

...however, if there's a neater alternative to a tag read you can suggest, could you let me know ?

SWAG, Get_Attribute_List

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now