Veteran Member
Posts: 5,456
Registered: ‎03-12-2011
Kudos: 2746
Solutions: 129

PPPoE Server RFC4638

While I have had great success with the PPPoE client with RFC4638, I can't seem to get RFC4638 to work with the PPPoE server (another EdgeRouter is the client).

After doing a little bit of digging, I think I've worked out why. While the pppoe-server-options looks right

$ grep m.u /etc/ppp/pppoe-server-options
mtu 1500
mru 1500

I suspect those options are being overridden by the process command line arguments

pppd plugin /usr/lib/pppd/rp-pppoe.so nic-xxx rp_pppoe_sess xx:xx:xx:xx:xx:xx rp_pppoe_service  file /etc/ppp/pppoe-server-options 10.255.253.0:1x.x.x.x nodetach noaccomp nopcomp default-asyncmap mru 1492 mtu 1492

Is there any way to either change those command line parameters, or remove the mtu/mru setting from it entirely so that the config file options are used instead?

I couldn't see anywhere that specified those options, so I suspect they might be hardcoded in the pppoe-server binary which will be a little more painful to fix.

Semi-related: Can we get an option to change the PPPoE server local IP address yet? Man Tongue I have some more detailed info in another thread on this.

Highlighted
Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5473
Solutions: 1656
Contributions: 2

Re: PPPoE Server RFC4638

Yeah we will need to look into this. Thanks for the info!

Regarding configurable local IP, yeah as discussed it is on the TODO list and we just need to find the resources to implement it.

Veteran Member
Posts: 5,456
Registered: ‎03-12-2011
Kudos: 2746
Solutions: 129

Re: PPPoE Server RFC4638

I imagine it shouldn't be too hard - the main issue is the ip-up and ip-down scripts that check the IPLOCAL to work out if its a pppoe-server client or not - but that can easily be changed to check the IFPREFIX ($6) instead like 0006rename-pppoe-server does.

Then its just a matter of updating the PPPoEServerConfig.pm to use a config option instead of the hardcoded variable.

I've detailed this in http://community.ubnt.com/t5/EdgeMAX-Feature-Requests/Ability-to-specify-PPPoE-server-local-address/... too. Man Very Happy

Previous Employee
Posts: 10,504
Registered: ‎06-09-2011
Kudos: 3141
Solutions: 945
Contributions: 16

Re: PPPoE Server RFC4638

Patches are always welcome ;-)

EdgeMAX Router Software Development
Veteran Member
Posts: 5,456
Registered: ‎03-12-2011
Kudos: 2746
Solutions: 129

Re: PPPoE Server RFC4638


@UBNT-stig wrote:

Patches are always welcome ;-)


Haha once I get my hands on that fancy custom image building jigger I'll be far more keen to make edits to the base system and CLI (At the moment I'm heasitant to make changes that would be difficult to make persist across upgrades without shooting myself in the foot - configs failing to load properly because those config options don't exist for example) at which point I forsee a fair few patches appearing. Man Very Happy

Veteran Member
Posts: 5,456
Registered: ‎03-12-2011
Kudos: 2746
Solutions: 129

Re: PPPoE Server RFC4638

Hrm, was doing a little bit of digging relating to this and found the RP-PPPoE 3.11 changelogs (which, if memory serves is the version EdgeOS uses): http://lists.roaringpenguin.com/pipermail/rp-pppoe/2012q3/000346.html

o Permit both PPPoE server and client to specify an MTU/MRU of 1500 assuming the underlying Ethernet interface has an MTU of at least 1508.  The larger MTU is negotiated per RFC 4638.  NOTE: Only available with kernel-mode plugin, not user-mode pty redirector.

Which sounds like it should work as it explicitly mentions that the PPPoE server should support RFC 4638 as well.

Are there any ubnt customisations to the pppoe-server package?

Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5473
Solutions: 1656
Contributions: 2

Re: PPPoE Server RFC4638

Yeah both client and server are from 3.11 and the only "customizations" are "Debianization" and cross build support so not really much. Some people have mentioned the old pppd version might be an issue, and updating pppd is still on our TODO list of course.

Established Member
Posts: 812
Registered: ‎12-24-2010
Kudos: 195
Solutions: 26
Contributions: 1

Re: PPPoE Server RFC4638

[ Edited ]

I am able to get 1500 to work with PPPoE server as long as the route allows at least 1508 clear through to the endpoint ........ 1.4.1 and 1.5a1 give same results... Even my AirOS radios running 5.6b2 are getting 1500/1500 through PPPoE if the access point allows 1508 through WAN and LAN (and bridge), and the CPE allows 1508 through the WAN

root     25103  2049  0 Apr13 ?        00:00:20 pppd plugin /usr/lib/pppd/rp-pppoe.so nic-switch0 rp_pppoe_sess 4:00:xx:xx:xx:xx:ad rp_pppoe_service  file /etc/ppp/pppoe-server-options 10.255.253.0:XX.xxx.xx.153 nodetach noaccomp nopcomp default-asyncmap mru 1500 mtu 1500
ubnt     26572 26558  0 22:52 pts/0    00:00:00 /bin/busybox grep ppp
root     26808  2049  0 Apr13 ?        00:00:15 pppd plugin /usr/lib/pppd/rp-pppoe.so nic-switch0 rp_pppoe_sess 38:00:xx:xx:xx:xx:f9 rp_pppoe_service  file /etc/ppp/pppoe-server-options 10.255.253.0:xx.xxx.xx.187 nodetach noaccomp nopcomp default-asyncmap mru 1500 mtu 1500

 

Veteran Member
Posts: 5,456
Registered: ‎03-12-2011
Kudos: 2746
Solutions: 129

Re: PPPoE Server RFC4638


@ajbtv2 wrote:

I am able to get 1500 to work with PPPoE server as long as the route allows at least 1508 clear through to the endpoint ........ 1.4.1 and 1.5a1 give same results... Even my AirOS radios running 5.6b2 are getting 1500/1500 through PPPoE if the access point allows 1508 through WAN and LAN (and bridge), and the CPE allows 1508 through the WAN

root     25103  2049  0 Apr13 ?        00:00:20 pppd plugin /usr/lib/pppd/rp-pppoe.so nic-switch0 rp_pppoe_sess 4:00:xx:xx:xx:xx:ad rp_pppoe_service  file /etc/ppp/pppoe-server-options 10.255.253.0:XX.xxx.xx.153 nodetach noaccomp nopcomp default-asyncmap mru 1500 mtu 1500
ubnt     26572 26558  0 22:52 pts/0    00:00:00 /bin/busybox grep ppp
root     26808  2049  0 Apr13 ?        00:00:15 pppd plugin /usr/lib/pppd/rp-pppoe.so nic-switch0 rp_pppoe_sess 38:00:xx:xx:xx:xx:f9 rp_pppoe_service  file /etc/ppp/pppoe-server-options 10.255.253.0:xx.xxx.xx.187 nodetach noaccomp nopcomp default-asyncmap mru 1500 mtu 1500

 


Hmm interesting. I might have to re-check my setup to ensure something in the middle isn't missing the higher MTU - perhaps it's doing some MTU detection to prevent shooting oneself in the foot.

Are you using an EdgeOS device as the PPPoE client too? Or just AirOS? Perhaps it doesn't work when EdgeOS is both the client and server?

Will test more and report back.

Established Member
Posts: 812
Registered: ‎12-24-2010
Kudos: 195
Solutions: 26
Contributions: 1

Re: PPPoE Server RFC4638

Sorry, I fell behind on getting back to you.


The PPPoE client on the Edgemax does seem to be the problem with establishing a 1500/1500 connection.  I have confirmed this issue with 1.5a1 as well. 

Veteran Member
Posts: 5,456
Registered: ‎03-12-2011
Kudos: 2746
Solutions: 129

Re: PPPoE Server RFC4638


@ajbtv2 wrote:

The PPPoE client on the Edgemax does seem to be the problem with establishing a 1500/1500 connection.  I have confirmed this issue with 1.5a1 as well. 


It's odd, I've not had any issues with the PPPoE client establishing a 1500 byte MTU to my ISP at all, and tests (netalyzr, etc) show that it's working properly too.

Must be certain PPPoE concentrators that have issues while others are fine.