Been messing with PPPoE client on RouterOS and I have noticed a couple of issues, that probably should be corrected to increase the robustness of the implementation.
- The PADT that use to terminate the session at the Discovery level seems to get sent to the 00:00:00:00:00:00 ether address, it should be the ether address of the AC whose session it is trying to terminate. This may still work depending on what the AC does with a non RFC conforming request and if there are any switches between them that might absorb this packet.
- After the Discovery is complete and the PPP attempts to start with LCP Config Requests, if no response is received, RouterOS will just sit there sending an increasingly infrequent LCP Config Request - eventually (after about 100 secs - after 10 retransmissions?) it will send a PADT (with incorrect destination ether addr - see above) and start the PADI again. However, and this is wierd, it does not restart the timer between LCP Config Requests - in other words they start as infrequently as before, about every 30 seconds and keep climbing. So now it will take even longer for the PPP to send the 10 LCP packets. Even disabling and reenabling the PPPoE client doesn’t reset this timer between requests (though it does force a PADT etc).
Should I lodge this as a support request?