PPPoE faults cost more than hotspot faults, because a PPPoE customer is a monthly subscriber who will leave if the line is unreliable. This guide covers the PPPoE problems ISPs and WISPs actually hit on MikroTik, what causes each, and how to fix it, ending with the operational changes that stop them recurring.
Error 691: invalid username or password
The classic. Before touching the customer's router, check in this order.
- •The account is expired or suspended. On a correctly automated network this is the most common cause of 691 by a wide margin: the subscriber's plan lapsed and the system disabled the secret. Confirm the billing status first.
- •The secret exists twice. A local PPP secret on the router and a RADIUS user for the same subscriber will fight. Decide which is authoritative, on a RADIUS-backed network it is RADIUS, and remove the local duplicate.
- •Case, whitespace and service name. Credentials copied by hand pick up trailing spaces. A service-name mismatch between the client and the PPPoE server also presents as an authentication failure.
- •RADIUS is unreachable. If the router cannot reach the RADIUS server, every login fails as if the password were wrong. Check the RADIUS secret, the ports and the route.
Error 678 or 651: no response from the server
This is layer 1 and 2, not credentials. Check the physical link and the port, then confirm the PPPoE server is running on the correct interface: a server bound to the wrong bridge or VLAN answers nobody. On a wireless backhaul, check for a broken link before assuming a configuration fault. If several customers on one access point are affected at once, the fault is upstream of all of them.
The customer paid but is still disconnected
Another billing fault wearing a network costume. The payment landed, but the account was never reactivated, either because reconciliation is manual, or because a payment callback failed silently. The customer is now calling you while sitting next to a router that is working perfectly.
The fix that lasts: the payment must reactivate the subscriber without a human. With built-in RADIUS and Change of Authorization, a confirmed payment restores the live session in seconds, no ticket, no callback, no evening spent re-enabling secrets. The payment side is covered in how to fix M-Pesa and billing problems.
Sessions drop every few minutes
Work outward from the customer. Check for a duplicate session, the same credentials in use in two places will fight until one wins. Then check MTU: PPPoE overhead means an MTU of 1480 with MSS clamping is the safe default, and a wrong MTU produces the classic symptom of a connection that works until a large page loads. Then check keepalive timeout, and finally the wireless or fibre link itself for packet loss.
Speeds are wrong after a plan change
If a customer upgrades and stays slow, the live session is still carrying the old profile. PPPoE sessions do not pick up a new rate limit until they are re-established, or until the network is told to change them mid-session. A RADIUS Disconnect-Message drops and instantly reconnects the session with the new profile; a Change of Authorization can update it in place. Both require incoming RADIUS enabled on the router and the port open. Doing this by hand, disable, wait, enable, is why plan upgrades so often generate a second support call.
IP pool exhausted
When the pool runs out, new sessions fail and old ones behave strangely. Size the pool above your peak concurrent sessions, not your subscriber count, and check for leaked addresses held by sessions that never closed cleanly. If you run several sites, give each its own pool so one busy site cannot starve another.
RADIUS accounting is wrong or missing
If your usage reports look implausible, check that accounting is enabled on the router, that interim updates are being sent, and that sessions that die ungracefully are being closed by the server rather than left open forever. Stale open sessions inflate concurrency and can trip the duplicate-session logic on a legitimate reconnect.
Everything works, but only some customers are affected
Segment before you speculate. Same access point, same VLAN, same PPPoE server, same profile, same plan expiry date? One of those groupings will contain every affected customer, and that grouping is your fault domain. Guessing without segmenting is how an evening disappears.
The recurring-fault test
If you fix the same PPPoE fault more than twice a month, it is not a fault, it is a process. Expired-account 691s mean your billing is not driving your network. Slow-after-upgrade means plan changes are not pushed to live sessions. Paid-but-offline means payment and provisioning are separate systems. Each of those is an automation gap, not a MikroTik gap.
Close the loop
Iterative Billing runs PPPoE the way the faults above suggest it should be run: billing drives RADIUS, RADIUS drives the session, payments reactivate subscribers automatically, plan changes are applied to live sessions with CoA, and agentic AI monitors connections, troubleshoots at the customer-router and MikroTik network level and reboots routers remotely when they misbehave. Adding a MikroTik is fully automated and takes at most 8 minutes to fully up and running.
Apply at https://billing.iterativebilling.com/register to try it against your own network, and see PPPoE billing for how the provisioning side works. Be Wisp B.
Frequently asked questions
- What causes PPPoE error 691 and how do I fix it?
- Error 691 means authentication failed. On an automated ISP network the most common cause is an expired or suspended account, so check billing status first. Then check for a duplicate identity, a local PPP secret on the router competing with a RADIUS user for the same subscriber, and remove whichever is not authoritative. Also check for trailing whitespace in copied credentials, a service-name mismatch, and an unreachable RADIUS server, which makes every login fail as though the password were wrong.
- What does PPPoE error 678 or 651 mean?
- It means the client got no response from the server, which points at layer 1 or 2 rather than credentials. Check the physical link and port, then confirm the PPPoE server is running on the correct interface, since a server bound to the wrong bridge or VLAN will answer nobody. If several customers behind one access point fail at the same time, the fault is upstream of all of them.
- Why is a customer still slow after upgrading their package?
- Because the live PPPoE session is still carrying the old profile. Sessions do not adopt a new rate limit until they are re-established or updated in place. A RADIUS Disconnect-Message drops the session so it instantly reconnects on the new profile, and a Change of Authorization can update it live; both need incoming RADIUS enabled on the router with the port open. Iterative Billing performs this automatically when a plan changes.
- Why do PPPoE sessions keep dropping every few minutes?
- Check for duplicate sessions using the same credentials in two places, then MTU: PPPoE overhead means 1480 with MSS clamping is the safe default, and a wrong MTU typically shows as a connection that works until a large page loads. After that check the keepalive timeout, and finally the wireless or fibre link itself for packet loss.