My PPPoE server is not diconnecting clients "gracefully". The session gets dropped on the server, but the client continues to think it is connected, so it never re-esstablishes the session. A majority of my clients are Tranzeo CPEs, but the issue is not limited to their gear exclusively. Their development team is working on a fix, but I would love to figure out how to solve this on the server end, so all of the other clients will be fixed as well. Does anyone know how to fix this on the server? Can a script be implemented to work around this? Any help would be greatly appreciated!

Here is the info that Tranzeo's tech emailed me:

We have reviewed this case. In summary, we see the issue, and we know
what is causing it. In simple terms, if a session dies at the AP,
perhaps due to contention, the server only sends a PadT once. If the
connection is restored later, the CPE uses the old ID. This ID is
invalid, and has already been closed, but the PadT is never resent.
However, the id is still responded to, which means that the CPE has no
reason to start a new session. As a result, the CPE has a session that
it thinks is valid, and since it is getting a response to its queries,
it will not close the session. Microtik expects the CPE to send the
PadT command, we expect the AP to.

Could you be more specific about the problem you have with PPPoE server (what do you see at 'ppp active print' for ecoding option) ?
As according to this mail, problem has nothing to do with MikroTik RouterOS as PPPoE server.

there is nothing in the encoding column, should it have some value there?

I'm not sure if the problem is with the router or not, but it sure seems that way. I use a variety of PPPoE clients, and all of them behave the same way. The client router logs in; they're online for a while, then the server drops the connection (I sometimes see a log line of "Peer is not responding"); the client never sees that the connection is dropped, the status still shows as connected, and the user can't browse. Power cycling the client router, or logging in & manually disconnecting & then reconnecting gets the user back online.

Even if it is not a problem with the mikrotik router, is there any way to work around this on the Mikrotik side? For example; can a script be written that responds with a PadT packet to any requests coming from a client with an invalid session id?

Note, that if you think there is a problem with RouterOS, you must contact support department (support@mikrotik.com) with as much details as possible about the problem.

What do you see in the logs for the wireless interface, when you experience these issues ?

I emailed Mikrotik support; but have not gotten a response yet.

The router is connected to a switch which is then connected via PtP links to Tranzeo & Proxim Access Points (so there is no "wireless interface" on the Mikrotik). Neither of these APs have logging functionality that helps with any of this, they're set up in bridge mode, so no PPPoE details would show up there anyways. The clients are mostly Tranzeo CPEs, which don't have any logging functionality at all. Some of them are set up in bridge mode with Linksys & D-Link routers behind them, & the limited logging on those has not revealed anything either. The PPPoE server itself has log lines of "<PPPoE-username>: terminating... - peer is not responding", if that helps.

It sounds like the tranzeo is dropping it's wireless link to the access point. Or the data link to the PPPoE server is dropping packets or dropping all together. The only reason a PPPoE session would drop is if it lost it's physical/data link connection with the network, causing the connection to timeout/drop. Start at Layer1 and work you're way up.. Since PPPoE is a Layer2 protocol there's not much to troubleshoot. Either the CPE is losing connection with the AP or you have packet loss or a bad link somewhere between the CPE and the PPPoE Server. Also make sure your "keep alive timeout" is set on the PPPoE server. I have mine set to 30secs.

keepalive-timeout (time; default: 10) - defines the time period (in seconds) after which the router is starting to send keepalive packets every second. If no traffic and no keepalive responses has came for that period of time (i.e. 2 * keepalive-timeout), not responding client is proclaimed disconnected.

You can also turn on PPPoE debugging/logging on the PPPoE concentrator for more detailed information. I wouldn't suggestion leaving it on as it will fill up your log file quickly.

We are using Mikrotik PPPoE servers in conjunction with mikrotik and tranzeo CPE's and it works fine (we also use Mikrotik APs). The nice thing about mikrotik CPE's is they perform true 802.1d bridging (when using WDS/EoIP) whereas the Tranzeo CPE's use some kind of MAC-NAT with PPPoE pass through. You'll note that when a tranzeo user connects it reports the tranzeo's MAC address instead of the PPPoE client's mac address in the "Calling Station ID" field. This isn't necessarily a problem unless you're trying to establish multiple PPPoE sessions from behind one Tranzeo CPE.