Recovering stuck PPPoE sessions on MikroTik without disconnecting everyone
After a power cut, customers can stay offline because their old PPPoE session is still active on the router. Here is why it happens and how to recover one session at a time.
Pandharinath Networks engineering
Every operator who runs PPPoE on MikroTik RouterOS has seen it. Power returns to a neighbourhood, customer routers and ONTs boot again, and a handful of customers still cannot get online. Their equipment is dialling, the password is right, yet the login is refused.
The tempting fix is to restart the PPPoE server. It works, and it also disconnects every other customer on that server. There is a better way.
Why the session gets stuck
When a customer’s router loses power, it does not say goodbye. The PPPoE server still holds an active session for that username until its keepalive check decides the other side is gone. Two settings then decide whether the customer can reconnect straight away:
only-oneon the PPP profile. When it is enabled, the server allows only one session per username. A new login is refused while the old, dead session is still listed under/ppp active.- Keepalive timing on the PPPoE server. Until the server’s keepalive gives up on the old session, it remains “active”, so the refusal continues.
Most of the time the old session expires by itself within seconds. When it does not (because of keepalive settings, a busy router or equipment that reconnects with a new MAC address) the customer stays offline until someone intervenes.
Recover one session, not the whole server
The targeted fix is to remove only the stale session for that username:
/ppp active print where name="cust-0412"
/ppp active remove [find name="cust-0412"]
The customer’s router, which is already retrying, logs in on its next attempt. Nobody else notices.
Two related situations look similar but need a different fix:
-
The ONT or router was replaced. If the PPP secret is bound to the old device through
caller-id(the MAC address), the new device is rejected even though the password is correct. Clear the binding and let it learn the new one:/ppp secret set [find name="cust-0412"] caller-id="" -
The account has expired or been disabled. Removing the session will not help; check
/ppp secretfordisabled=yesor a profile change first.
Make it a button, not a terminal session
The commands are simple. The problem is who runs them, at what hour, and how carefully. In an operations portal the same recovery becomes a guarded action:
- Staff search for the customer and see their live status: online, offline, or stuck.
- Recover session removes only that customer’s active session through the RouterOS API.
- Reset MAC binding clears
caller-idfor an equipment swap. - Protected accounts (uplinks, staff, test users) can never be disabled, deleted or reset by mistake.
- Every action is written to an audit log with who did it and when.
We use a dedicated API user with only the permissions these actions need, separate read and write credentials, and validation before every change. A support person can resolve the complaint without ever opening WinBox or touching the PPPoE server itself.
A checklist for operators
- Review
only-oneon your PPP profiles and decide deliberately whether you need it. - Check the PPPoE server’s keepalive timeout; very long values keep dead sessions around.
- Never restart the PPPoE server as a first response to a few stuck customers.
- If you bind secrets to MAC addresses, have a documented, logged way to reset the binding.
- Back up the router configuration on a schedule, off the device, before automating anything.
Small operational habits like these are what keep a few hundred customers online after every power cut, and they are exactly the kind of work that should live in software rather than in one engineer’s memory.