Feature request

I'm not sure if this is implented in a newer Beta or now.

Can we please make it so you can't have PPPoE enabled and also have a static IP entered....

So if PPPoE is entered can we blank out the static IP, or Grey it out. 

I have techs who normally use Static IP's. Then we also use PPPoE for some customers. If they enable PPPoE, but leave the radio in a static IP mode we get no service (as expected) But, they scratch their heads why they get nothing. Not realizing that they may have selected PPPoE from a prior install, or other setting change.

UBNT radios don't allow you to use both modes. You have to choose which one you want at the top of the page, and then you enter either a static IP, DHCP, or PPPoE credentials. Likewise, why you have to turn on DHCP in order to use PPPoE is kind of weird also. Another extra thing you have to click on to make a cambium radio work.


We discussed your request and this is a good suggestion, but this may cause much more trouble to the other customers after they do the upgrade. Some of them already using static IP and PPPoE server and disabling static IP potentially may lead to incorrect IP assignment and accounting. The risk very high compared to the profit.

I don't understand what you mean.

If you set a static IP address, and enable PPPoE, I don't have any access.

If I set PPPoE credentials and don't set DHCP, and leave the static IP blank, I still have no access.

It "seems", that if you want to use PPPoE, you HAVE to select DHCP for it to even work. Meaning, it's more of a bug than a request. Have you guys actually tried to use a radio with a static IP address and then enable PPPoE?  Even with proper credentials, You have no service, nor does the static IP address work...

IDK, we use "framed IP" addresses with PPPoE. Maybe others don't, and that's where our problem happens. In either case, you shouldn't need to select DHCP client for PPPoE to work. The two are not related.

And.... BUMP..

Why is it that Cabmium is pretty much the only manufacturer that allows both static and PPPoE on their interfaces at the same time?

Why can't you fix this so PPPoE works like it should..? DHCP and PPPoE have nothing in common, and you should not need to select DHCP in order for PPPoE to get an IP address.

Likewise, you should not be able to choose Static and PPPoE at the same time. It's one or the other. 

If you must keep it this way, move the PPPoE enable/Disable up to where you have to select static,DHCP IP for WAN. At least that way you know when you have something wrong.. But, if you do that, you will clearly see how much of a cludge it is to NEED to turn on DHCP for PPPoE to work properly with a framed IP address.

Damnit Cambium, Stop dismissing your customers. This post was over 2 weeks ago. With no reply as to how or why you are doing what you are doing. NO ONE else allows Static and PPPoE at the same time. It's either or.

"Some of them already using static IP and PPPoE server "

Wut ?  We use Static IP's via PPPoE as in the user is always assigned the same IP via PPPoE.  How do you use the "static IP" setting in the radio and PPPoE at the same time ? Assuming that even works (does it ?) what is the purpose of the PPPoE Auth if you used the "static IP" setting in the radio ?

Does the static IP get used if PPPoE fails to authenticate or something ?  If that is what is supposed to happen then why is it breaking PPPoE for Tristan ? Is it because he uses "framed IP" ? I'm curious because, even though I never even thought about using static IP and PPPoE, we also use framed IP address and maybe there is something to this whole "Static IP and PPPoE at the same time" I might find useful if I knew how it worked.

It doesn't work very well if there is an idea behind it.

Actaul implementation of PPPoE on an interface has you NOT add an IP address on that customer facing interface for actual security of that port. You can defeat the whole purpose of PPPoE by doing that on your customer facing router port.

What we have found is a couple things.

If you have PPPoE enable using a framed IP, you HAVE to enable DHCP client for anything to work.

If you have a static IP assigned in the radio via static IP, it gets over ridden by PPPoE.

If you have a static IP in the radio and have static selected, along with PPPoE enabled with a proper credential and a framed IP. NOTHING works.. The Cambium AP will show the client radio using the static IP, but you can't reach the radio.

If you have Static IP enabled, and PPPoE enabled, but do NOT have a framed IP, the radio will work with the static IP. AND still authenticate via PPPoE. (I found this out from a tech who keeps not setting up the radio right and not turning on DHCP, or uses a used preconfigured radio and doesn't realize what settings are on)

You should never be able to use PPPoE and static IP at the same time. It's a total security nightmere and isn't how PPPoE is even desgined.. I've never seen you be able to use both at the same time in any device. And certainly have never had to enable DHCP client for it to work on an interface either.

and yeah, we do have an ip assigned to PPPoE ports. But, that is our own fault, and also needed as we switch over customers to PPPoE.

"If you have Static IP enabled, and PPPoE enabled, but do NOT have a framed IP, the radio will work with the static IP. AND still authenticate via PPPoE. "

I wonder what is the point of authenticating if the radio has a static IP ?  How does PPPoE control access if not by IP and if it doesn't control access then what purpose does it serve ? 

Danged if I know.. All I do know is that it will authenticate. Because I have seen it in the concentrator logs and didn't know why. And then logged in via the static IP address to the radio. I really feel like Cambium has PPPoE boogered up.  

It works. But, not like its supposed to IMO.. I'd love to find a use case from any other vendor that makes you select DHCP client for PPPoE to work, and/or doesn't also disallow using any other form of WAN IP while having PPPoE enabled..

bump for cambium response.

I'd like a use case for how and why you have PPPoE set up the way you do.

Just bumping again for a use case for your method of PPPoE cambium..

Why are you allowing PPPoE to be broken by being able to select static and PPPoE methods?

still waiting Cambium?

Why have you broken PPPoE? What is your use case for making us select DHCP client when using PPPoE?

PPPoE feature was designed to work this way. The problem with implementing this feature like you proposed make sense. But imagine that someone is using static IPs with PPPoE and after next firmware upgrade he will loose access to all SMs because he didn't configured PPPoE server to handle IPs correctly. He did everything correctly by our User Guide, but then we just changed the rules. So it is better to keep this as-is.

I've never heard of using a static IP with PPPoE that isn't using a "framed IP"... Using static IP's while also using PPPoE is not how PPPoE is designed and is against best practices.. But, I degress.

Can you at least put the PPPoE enable/Disable up where the selection can be made in clear site of one or another? This way you can't accidentally have both going when you aren't really supposed to?

1 Like