Hi,
I’ve been using PPPoE for my network authentication for a while now, usually with a router at the client’s end to manage the link. With the inclusion of the PPPoE client in 9.4, I have a few routerless clients that use this feature. However, when their radios re-reg, the PPPoE login will get stuck either in LCP Negotiating or IPCP stage. The only solution is to reboot the SM. This was mentioned in the 9.4 release notes as an open issue, but it persists with 9.5 (which I just upgraded to). Are there any settings that anyone knows of that can reduce the frequency of this happening? It never happens with my router clients. I’d be willing to fiddle with Mikrotik settings if they would improve the situation.
Thanks,
Ryan
Hidden Lake Wireless
Using that settings works for me fine. After re-reg, session automatically starts. Using 9.5fw on 5400SM´s, on 9.4fw CHAP wasn´t supported, so i have not tested PPPoE.
Thanks for the reply,
Those are the exact settings I use except my PPPoE device has a service name. I’m using 900MHz and have seen the problems on both P9 and P10 hardware. I should say the this problem only occurs some of the time. Most of the time it will re-login after a re-reg. But once it get hung up, there is no connectivity for the user until the radio is rebooted.
Ryan
Hidden Lake Wireless
Service name and AC name i´ve left blank, because i have only one on that route. So it´s not necessary to fill them. But I can try to fill them for few days and wait (but probably this is not the problem). Are you using authentication? PAP or CHAP? I use CHAP and it works well on all revisions i have installed on network (approx 170 clients on 10 APs, SMs P9-P11). No similiar problems at all like yours.
Anyway, why your SMs are re-registrating? How often your RF connections falls down? Bad local RF conditions, interference, weak signal or what? I´ve good signal on most of SM´s, very rare re-regs.
If the SM make re-reg and the PPPoE isn´t connected, can you connect to the web management of that SM using RF link from AP? If this is possible, try to go to the configuration -> PPPoE and press CONNECT button. Should it work?
Sorry for poor english 
Hi,
Your english is great - no worries.
I’m using mikrotik for my access concentrator and it allows PAP,CHAP,MSCHAP1,MSCHAP2. I’ll consider limiting it to CHAP and see what happens. I’ll have to do some reading on the different authentication schemes, I guess.
What are my SMs re-registering…why indeed…I have an all 900MHz system because we have a thickly wooded area. I have to use big Yagis for some customers that are within a mile just to get a decent signal. It’s a little puzzling because my strong signal client will re-reg about as often as the others - every few days. I’ve done all I can to balance the power levels at the AP although it’s not perfect. There are 2 other WISPs using 900MHz on the perimeter of my service area and I’ve coordinated with them to make sure we’re in sync. I’d love to clean up the re-regs but I’m not sure what else to do.
As for the connect button - when the problem occurs it’s during the connection process and neither the connect nor the disconnect buttons will reset it. They don’t show up at all on my end, but I can still get to the radio web page to reboot it.
Thanks for your help,
Ryan
Hi,
Well, I changed my Mikrotik PPPoE authentication to CHAP only. I just had one of my customers re-reg and the Canopy radio got stuck in the IPCP-Negotiating step, requiring a reboot. This is a P9 unit. None of my router users have this problem. The signal is very strong for this particular customer and I’m still working on trying to figure out why I get so many re-regs. This seems to be an issue with the Motorola firmware. According to 9.4.2 release notes they fixed the problem but it’s still occurring for me
Ryan
From 9.4.2 Release Notes:
“Before, on a link with some re-regs, the SM might get
stuck in “LCP Negotiating” mode if a PPPoE session
was started, but the LCP and IPCP stages never
completed. Connect/disconnect buttons wouldn’t
have resolved the issue. Release 9.4 partially
resolved this issue, and Release 9.4.2 fully resolves
it.
A new stage of PPPoE session status called
Connecting was added. Now if there is a problem
setting up the PADI/PADO part of the PPPoE
session Connecting will be reported rather than LCP
Negotiating.”
I had issues with 9.4, now with 9.5 it seems to work flawlessy.
Probably there are some micro-interruptions on the path.
How is your packet loss and round trip delay from SM to concentrator?
BTW, I’m using Mikrotik RB1000 as PPPoE concentrator…
Massimo
The ping to the radio varies from about 8ms to 23ms. The BER is x10-7 so very few bit errors. The signal is very strong - in fact I have the SM turned down almost all the way. How do I measure packet loss?
Ryan
Probably HPING is one of best choices. Try to ping device behind that SM.
I can’t ping anything behind the SM as it’s acting as the router. I can only ping the 169.254.x.x public admin address. Ping on the WAN address is also disabled.
Thanks,
Ryan
To measure packet loss, just ping your concentrator from SM LAN.
In a windows shell you can simply use
ping x.x.x.x -t
after some minutes, you can press CTRL-C and the command will tell you the percentage of packet loss.
It should be 0% for stable PPPoE connections.
It is 0%. The connection is stable but will re-reg about once a day. Sometimes when it re-regs the PPPoE in the SM gets stuck. So the re-regs are higher than I’d like and I have yet to understand why as the connection is very good. But the more concerning problem is the PPPoE getting stuck requiring a reboot of the SM.
Ryan
Just an update…
I’ve tried adjusting the PPPoE keepalive timeout. I have 3 customers that don’t use routers and every one of them will get stuck in this PPPoE connecting mode and need a reboot occasionally. Motorola, I think this is still an issue with 9.5 and needs to be addressed.
Final Update:
10.3.1 seems to have fixed this problem. I haven’t had any issues with customers using the built-in PPPoE in the SM since I updated the firmware. Thanks Motorola!
Ryan