Hello,
I’m facing a constant problem with pppoe clients (not the same clients all time) where client remains connected to the server, but no traffic can be done not even icmp, when I ping the gateway what I get is request time out. Is this any pppoe issue that all you guys have faced in the past or just an Windows XP bug.
Regards.
Faton
Anyone had this problem ?
No - at least not that I am aware of 
What RouterOS version is that?
Best regards,
Christian Meis
I’m using two versions 2.9.27 and 2.9.38, the problem is occuring in both versions, I can not define what is it, firstly I thought it could be ipconflict but that it is not a case. I have tried also an pppoe client WINPOET again it hapens. It is very strange.
I have tried with another pppoe client FRIENDLY PPPPOE and again problem was occuring, anyone any idea.
Thanks for feedback.
Regards.
We have arround 550 pppoe clients on a MT with a total throughput of max 90 mbps and we have the same problem with XP clients.Anyway we placed hardware routers on our network and the routers have no problem.
we don’t know if we had a problem with MT or not. but we have a dsl modem connected via pppoe mode. but the modem is oftenly disconnected. then we need to restart the modem again.
after that we change the pppoe mode to brigde mode on the modem, but the gateway is not using MT. the modem run smoothly not oftenly disconnected
this is the configuration (MT 2.9.28 ) :
[admin@NexcomPPPoE] ppp profile> print detail
Flags: * - default
0 * name=“default” use-compression=default use-vj-compression=default use-encryption=default only-one=default
change-tcp-mss=yes dns-server=x.x.x.x
1 name=“nexcom” local-address=10.67.1.1 remote-address=pppoe use-compression=yes use-vj-compression=default
use-encryption=default only-one=yes change-tcp-mss=default rate-limit=512000/128000 dns-server=x.x.x.x
2 * name=“default-encryption” use-compression=default use-vj-compression=default use-encryption=yes only-one=default
change-tcp-mss=yes rate-limit=384000/64000
[admin@NexcomPPPoE] ppp aaa> print
use-radius: yes
accounting: yes
interim-update: 0s
0 service=ppp called-id=“” domain=“mydomain” address=x.x.x.x secret=“mysecret” authentication-port=1812
accounting-port=1813 timeout=1s200ms accounting-backup=no realm=“”
[admin@NexcomPPPoE] interface pppoe-server server> print detail
Flags: X - disabled
0 service-name=“nexcom” interface=broadcom max-mtu=1480 max-mru=1480 authentication=pap keepalive-timeout=180
one-session-per-host=yes max-sessions=0 default-profile=nexcom
please help
I have seen this before also; only with XP. Oddly, sometimes the only way to fix the problem, is to simply recreate the PPPoE connection in XP.
I have seen this before also; only with XP. Oddly, sometimes the only way to fix the problem, is to simply recreate the PPPoE connection in XP.
Same here, but we haven’t had anyone with this issue since ~2.9.27. I was not happy with the PPPoE in 2.9.27 but we have had great results with 2.9.38!
Hi,
my first post. I just read this thread. We ware running a pppoe Server with Version 3.10 and have the same Problem. It only occurs with WinXP and Vista clients. Not with Linux, mac, or any router. The connection just stops and no more traffic is passed, but the connection looks active. No Log Entries.
I allread found out that the Problem turns up faster, when the connection is on heavy load. Viewing Youtube Videos or downloading a File. Redialing helps to solve the problem until next download or streaming is started.
Is there allready a solution for this Problem? Maybe a newer firmware?
thanks,
flexn
This bug is discussed in several topics but please go to this http://forum.mikrotik.com/t/mikrotik-pppoe-timeout-bug/25232/1 new topic and resume there . thanks
Yes I also have this problem and posted a message here a couple of weeks ago and didn’t get much help!! Except one guy said to disable MSCHAP and CHAP authentication. This does actually just about give you a more stable connection but I feel it is still not perfect and also it’s not a good fix but a dodgy workaround!! Still stalls sometimes for a few secs on big downloads for example.
So could it be a Microsoft problem from a recent update? The lack of posts from anyone to do with MikroTik is worrying but maybe they don’t know either for sure yet? This gotta be a big worry though if wisps are using PPPoE!! Luckily I’m only testing PPPoE right now myself but it would be really bad for us if it was live service?
Out of interest is anyone here with the problem also running hotspot on same interface?
there an option about timeout i recomend to increase it , it may solve the problem as it occurs when there hight demand of traffic from user
when the user read his max limit , so mikrotik can’t ping the pppoe client so it will considered as dead but it will not disconnect it !
I think we fixed the Problem. We disabled all Authentication Methods besides CHAP and the Connection stays up and doesnt freaze any more. ms-chap and ms-chapII seam to cause the Problem. But actualy I dont understand why the authentication Method lets the connection freaze.
It has to do with the MPPE encryption. XP and UBNT clients (and probably others) run fine for awhile and then no traffic will pass. You probably didn’t have to disable the other Authentication methods… Simply turning off encryption in the pppoe profile should have worked.
First I also thought that it only has to do with encryption. But it doesnt. Turning Encryption on or off didnt help.
What about Authentication Methods ? did you test just PAP ? seems unrelated but who knows 
I had the same problem of microsoft windows pppoe client hangs. Always when I was uploading something the pppoe connection freeze.
Doing some test I tried the authentication mode workaround, and is working for me, no more freeze. 
I disabled MSCHAP and MSCHAP2 and the microsoft pppoe client doesn’t hang anymore.
I’v noticed that with authentication mode MSCHAP the encoding will be set to MPEE128. Disabling MSCHAP the encoding field get blank.
Maybe that encoding is the cause of the freezing…
bye.
By the way, the correct it statefuL with one L at the end. MikroTik can change that for next release of ROS.