Bug in Remote Access service

RouterOS General
1

Hello
There is probably bug in Remote Access service when is used for serial port forwarding (https://wiki.mikrotik.com/wiki/Serial_Port_Usage (Winbox menu System->Ports Remote Access tab)).
When client (for example PC) suddenly closes connection, mikrotik won’t close this connection.

When new connection arrives in Firewall->connections tab there are several connections with different source ports (all connections have established state) and in System->Ports Remote Access tab there is only one connection with source port of the first (dead) connection.
mikrotik_remote_bug1.png

2

The problem has been solved by itself, but this is just a workaround.
I’ve simply put the following code into /system scheduler

# Check if OVPN Server is running
:if ([/ping 172.16.0.1 count=2] != 0) do={
# Check if VM aquisition server is running
:if ([/ping 172.16.0.46 count=2] = 0) do={
:log info "Out of ping - reboting Remote Access"
:if ([/port remote-access get 0 disabled] = true) do={
:log info "NO_PING Remote Access disabled - action cancelled"
} \
else={
:log info "NO_PING Remote Access enabled - have to disable Remote Access"
/port remote-access disable 0
}
} \
else={
:log info "Ping OK - still working"
:if ([/port remote-access get 0 disabled] = true) do={
:log info "PING Remote Access disabled - have to enable Remote Access"
/port remote-access enable 0
} \
else={
:log info "PING Remote Access enabled - action cancelled"
}
}
}
3

When you say that the remote client suddenly closes connection, do you really mean a closure using a FIN or at least RST, or what actually happens is that the terminal application crashes or the cable falls out from the connector and none of the two packets above ever makes it to the Mikrotik? I’m not sure whether ~ 10 minutes timeout in the firewall means that FIN was seen in one directon or whether you have changed the TCP timeout to 10 minutes in general.

The remote access terminal differs from a generic TCP server in terms that it connects the session to a single physical resource (the serial port), so it cannot (or rather shouldn’t) serve several clients at the same time. So it does make sense that subsequent connections fail while the first TCP session is still active. I would expect them to be rejected by RST rather than not responded or be established but not transport any data, what’s the actual behaviour?