Hi guys,
Just updated the CCR at my house (one of our testing sites 
) but since this upgrade the PPPoE connection (one of the two uplinks to internet) is broken.
The logs show (every 20 sec):
pppoe1: initializingā¦
pppoe1: connectingā¦
pppoe1: terminatingā¦ - failed to authenticate our selves to peer
Also removing and recreating the connection doesnāt fix it.
Since the changelog contains several PPP related updates, it might be related to the upgrade.
*) ppp - fixed packet size calculation when MRRU is set (was 2 bytes bigger than MTU allows);
*) ppp - significantly improved shutdown speed on servers with many active tunnels;
*) ppp - significantly improved tunnel termination process on servers with many active tunnels;
To verify this I downgraded the device to 6.37.3 and instantly it starts working again.
Since the upstream release-candidate (6.39rc4) includes big changes in the PPP codebase I though lets try that:
!) ppp - completely rewritten internal fragmentation algorithm (when MRRU is used), optimized for multicore;
And also in 6.39rc4 the PPPoE is working fine.
Was wondering if anybody else experienced the same?
Probably good to know is that I used PPPoE over a tagged VLAN interface (for a VDSL connection in the Netherlands)
You are not the only one, same here. Very unstable 6.38, dhcp is terrible, i had to pull out 2xrouters and put back kpn xperia box. I havent use it from 2009.
Today I did the upgrade to 6.39rc7 but again PPPoE client seems broken?
Another thing I noticed is that a PPTP session just runs fine, so its not PPP in general but more like PPPoE specific?
After a downgrade to 6.37.3 it works fine (instant).
Hi I just upgraded to 6.39rc12 which includes some PPP(oE) related fixes.
*) ppp - fixed rare kernel failure on PPP client connection;
*) pppoe - make default keepalive 10s for PPPoE clients;
After this update the PPPoE instant works (again)ā¦
Just upgraded to 6.39rc13 and still working fine!
Havenāt tried 6.38.1ā¦
Just upgraded to 6.39rc15 and still working fine!
Upgraded to 6.39rc17, and (as expected based on the changelog) it still works fine 
Whatās new in 6.39rc17 (2017-Jan-23 16:30):
*) capsman - added save-channel option to speed up frequency selection on CAPsMAN restart;
*) capsman - added support for static virtual interfaces on CAP;
*) dude - (changes discussed here: http://forum.mikrotik.com/t/the-dude-v6-39rc-test-builds/104888/1);
*) hotspot - fixed rare kernel crash on multicore systems;
*) ike2 - default to /32 peer address mask;
*) ike2 - fixed EAP message length;
*) ike2 - update calling_station_id radius attribute;
*) ike2 - update radius attributes;
*) ipsec - better responder flag calculator for console;
*) ipsec - hide sa-addrs for transport policies;
*) wireless - apply broadcast bit to DHCP requests when using station-pseudobridge mode;
*) wireless - update Thailand country frequency settings;
Are these āitās still workingā updates really necessary?
Iām 99% sure that this is unrelated to pppoe, but related to hardware STP on bridges. They were fixed in exatly the same versions and should be working fine with 6.38.1 also.
Hi nescafe2002,
I did these topic updates because of the fact that PPPoE became broken (in 6.38), fixed (in 6.39rc), broken (in a newer 6.39rc) and fixed again (in another 6.39rc).
So I thought it might help to have the next āstableā release not having this issue..
I by the way just did a downgrade of our test CCR to 6.38.1 because of some IPv4 routing (probably mangle related) issues that started in 6.39rc17, so now I can confirm that the PPPoE is also working fine in 6.38.1 again.
We only try to be helpful, we have hundreds of Mikrotik devices deployed in the Netherlands and rely on a stable RouterOS.
@macgaiver, interesting finding / comment (regarding STP relation)!
I do have RSTP enabled on a bridge interface but this is not / does not contain the PPPoE interface.