Data updates can trigger unsolicited responses on a disabled outstation, putting the outstation in an invalid state

[chk-mk]

Thread one creates an outstation with a TCP server, then calls Apply() every (second/minute/hour) in an infinite loop.

Thread two powers up a comms interface (cellular modem, wifi, etc.), starts the IP stack with the appropriate driver, then calls Enable(). After about 24 hours, it calls Disable(), powers off the comms, shuts down the IP stack (cleanest way to unload network drivers on this RTOS...) and then starts over. Downtime is about a minute.

This works just fine, unless the master enables unsolicited responses. Since the first thread is always running, it will sometimes call Apply() during the downtime. The outstation may then try to send data over a closed channel (bug 1?). This fails:

ms(946706820997) ERROR server - Router received transmit request while offline
ms(946706825997) WARN outstation - unsolicited confirm timeout

When the master later re-connects, the outstation doesn't respond to anything (bug 2?). It periodically says this:

ms(946706977402) WARN outstation - Ignoring link frame, remote is flooding

But if the master then closes and re opens the connection, it usually returns to normal.

If the master simply disconnects, the outstation seems to disable unsolicited responses (haven't checked code to confirm) but Disable() doesn't have the same effect.

It's not entirely clear if data updates are allowed when not "enabled". Is this supposed to work? Also, is it fine to call Disable() from another thread?

[jadamcrain]

Hi,

It's intended that you update the outstation while disconnected. We'll need to write a unit test to replicate the bad behavior of sending unsol while disconnected. An illegal state like this could be responsible for the 2nd behavior you're seeeing.

Can I ask what RTOS you're using? Is this using ASIO, or have you ported the core library in some way?

-Adam

[chk-mk]

I'm using QNX and yes with ASIO. It required some minor changes to build since the stable compiler (QCC) is slightly outdated (based on GCC 4.7.3). Otherwise it was surprisingly easy to get up and running.

[jadamcrain]

Ok, thanks. It should be very easy to write a unit test to shake out why the outstation is trying to transmit while offline.

[chk-mk]

Spent a bit more time investigating this. It looks like OnLowerLayerDown() normally (eg. when the master closes the connection) gets called in the LinkContext, which then gets propagated up the stack, cleaning up as it goes, but Disable() fails to trigger an OnLowerLayerDown(). So the upper layers think the lower layers are still up when they are not.

In IOHandler::Disable:

iter->enabled = false;

if (channel)
{
	iter->LowerLayerDown();
}

LowerLayerDown is implemented as follows:

inline bool LowerLayerDown()
{
	if (enabled && online)
	{
		online = false;
		return this->session->OnLowerLayerDown();
	}
	else
	{
		return false;
	}
}

I tried moving iter->enabled = false; below the if (channel) and it seems to have fixed both issues. I'm not sure if this is the best fix, maybe enabled doesn't need to be checked there?

[jadamcrain]

Great. Thanks for digging in. I agree with your assessment. I'll have a look to see if it's best to move the statement or not check enabled in LowerLayerDown().

[jadamcrain]

Have at look at:

e741850

Let me know how this works.

[chk-mk]

Finally got around to trying it. Seems to be working fine. Thanks!