Core Update 179 Testing: Evaluating PPP 2.5.0

adamgibbo · 18 August 2023 13:58

Hello IPFire community,

With the upcoming Core-Update 179 integrating PPP 2.5.0, it’s paramount that we test our array of dial-up connections, with a special emphasis on the PPPoE bridging functionality, given its prevalent use and the major changes in the PPP update.

Key Connection Types to Test:

PPPoE (Priority): Ensure seamless connection establishment, stability, and termination. Due to the significant changes in PPP 2.5.0, our primary attention should be on the PPPoE connection.
VDSL: Verify PPPoE via VLAN functionality.
Modem: Test connections via different modems, including 3G and 4G (LTE) wireless modems.
Serial: Validate direct serial links without modems.
PPTP & PPxxx over ATM-BRIDGE: While perhaps less common, ensure that these connections are also operational.

Focused Testing Points for PPPoE:

Dial-in Options: Review the ‘Idle timeout’ behavior and the Dial-on-Demand mode.
Authentication: Test both PAP and CHAP authentication methods.
Reconnection Behavior: Examine IPFire’s handling of disconnections.
Additional Settings: Check non-default settings like MTU adjustments.

Feedback Format:

Connection Type:
Issue/Feedback:
Steps to reproduce:
Configuration (if applicable):
Logs or Error Messages:

If you’re unfamiliar or need a refresher on IPFire’s dial-up configurations, the IPFire wiki is a comprehensive resource.

Your assistance in testing this vital update is invaluable. By ensuring stability and functionality across all connection types, especially PPPoE, we’re paving the way for a robust and reliable release for the entire community.

Thank you for your unwavering support and commitment to IPFire.

Admin: Please feel free to edit this post for relevancy.

Best, A G

adamgibbo · 18 August 2023 14:00

Following up on the initial call for testing, I wanted to share my own findings regarding the PPPoE connections post Core-Update 179.

System Update and Reboot:

Upon applying the update and rebooting my IPFire firewall, I noticed that the PPP version has indeed been updated to 2.5.0 as indicated in the logs.

Logs Overview:

13:25:05  pppd[5192]:     Modem hangup
13:25:05  pppd[5192]:     Connect time 2936.2 minutes.
13:25:05  pppd[5192]:     Sent 2901882632 bytes, received 2170197149 bytes.
13:25:05  pppd[5192]:     Connection terminated.
13:25:07  pppd[5192]:     Exit.
13:25:52  pppd[2205]:     Plugin pppoe.so loaded.
13:25:52  pppd[2205]:     PPPoE plugin from pppd 2.5.0
13:25:52  pppd[2205]:     pppd 2.5.0 started by root, uid 0
13:25:52  pppd[2205]:     Failed to create pid file /usr/var/run/pppdppp-ipfire.pid: No such file or directory
13:25:57  pppd[2205]:     PPP session is 11
13:25:57  pppd[2205]:     Connected to AA:BB:CC:DD:EE:FF via interface red0
13:25:57  pppd[2205]:     Using interface ppp0
13:25:57  pppd[2205]:     Failed to create pid file /usr/var/run/pppdppp0.pid: No such file or directory
13:25:57  pppd[2205]:     Failed to create pid file /usr/var/run/pppdppp-ipfire.pid: No such file or directory
13:25:57  pppd[2205]:     Connect: ppp0 <--> red0
13:25:57  pppd[2205]:     CHAP authentication succeeded
13:25:57  pppd[2205]:     CHAP authentication succeeded
13:25:57  pppd[2205]:     peer from calling number AA:BB:CC:DD:EE:FF authorized
13:25:57  pppd[2205]:     local IP address 192.168.XX.XX
13:25:57  pppd[2205]:     remote IP address 10.XX.XX.XX
13:25:57  pppd[2205]:     primary DNS address XXX.XX.X.XXX
13:25:57  pppd[2205]:     secondary DNS address XXX.XX.X.XXX

Observations:

The connection gets established successfully after the update and the reboot.
There are errors related to the creation of pid files: /usr/var/run/pppdppp-ipfire.pid and /usr/var/run/pppdppp0.pid. This indicates that the respective directories might be missing or there could be permission issues. These errors should be looked into for rectification.

It’s essential for other community members to also share their findings, especially if they are facing similar issues or different challenges. This collective effort will ensure that any anomalies get addressed and result in a more refined final release.

Best regards,

A G

bonnietwin · 18 August 2023 14:05

Core Update 179 Testing has not yet been issued for testing, although I think it is pretty close to it.

Can everyone testing out the PPP-2.5.0 in CU179 Testing add any comments into the bug report.

https://bugzilla.ipfire.org/show_bug.cgi?id=13164

Your IPFire People email address and password will act as your login credentials for the IPFire Bugzilla.

bonnietwin · 18 August 2023 14:10

It looks like there needs to be an additional configure option to define the correct pid path. Currently it is using the PREFIX of /usr, which is incorrect.

I will do an update of that.

bonnietwin · 21 August 2023 17:04

Hi @adamgibbo and all,

The patch for fixing the pid directory to /var/run has been submitted and merged and is now in the latest build of Core Update Testing.

To update to that version then edit /opt/pakfire/db/core/mine to change the entry from 179 to 178.

Then go to the pakfire menu page and refresh the lists and then you should see the Core Update 179 release again. This will then upgrade your system to the latest CU179 version.

adamgibbo · 21 August 2023 22:20

Thanks @bonnietwin I appreciate your time and efforts in updating this package.

Following @bonnietwin’s update, I’ve updated and monitored the logs for the most recent build of Core Update 179. Here are my findings post-patch:

Log:

18:20:52  pppd[16899]:     Modem hangup
18:20:52  pppd[16899]:     Connect time 3968.4 minutes.
18:20:52  pppd[16899]:     Sent 2767761688 bytes, received 1668173239 bytes.
18:20:52  pppd[16899]:     Connection terminated.
18:20:54  pppd[16899]:     Exit.
18:21:39  pppd[2206]:     Plugin pppoe.so loaded.
18:21:39  pppd[2206]:     PPPoE plugin from pppd 2.5.0
18:21:39  pppd[2206]:     pppd 2.5.0 started by root, uid 0
18:21:44  pppd[2206]:     PPP session is 1
18:21:44  pppd[2206]:     Connected to AA:BB:CC:DD:EE:FF via interface red0
18:21:44  pppd[2206]:     Using interface ppp0
18:21:44  pppd[2206]:     Connect: ppp0 <--> red0
18:21:44  pppd[2206]:     CHAP authentication succeeded
18:21:44  pppd[2206]:     CHAP authentication succeeded
18:21:44  pppd[2206]:     peer from calling number AA:BB:CC:DD:EE:FF authorized
18:21:45  pppd[2206]:     local IP address 192.168.XX.XX
18:21:45  pppd[2206]:     remote IP address 10.XX.XX.XX
18:21:45  pppd[2206]:     primary DNS address XXX.XX.X.XXX
18:21:45  pppd[2206]:     secondary DNS address XXX.XX.X.XXX

Observations:

The connection was successfully terminated and re-established.
The previous errors related to the creation of pid files seem to be resolved post-patch.

Regards.
A G

ipcopmann · 22 August 2023 17:40

Running CU 179 Testing for a couple of days, OK so far.
My IPFire reconnects daily to get a new WAN IP and again, OK so far.
Fibre MODEM by the way.

adamgibbo · 25 August 2023 14:16

Happy Friday!

I’m writing with an update on the PPP package anomaly reported by @pmueller for Core Update 179. Peter observed a system log message post-upgrade indicating potential concerns:

Aug 23 16:12:24 maverick kernel: pppd uses obsolete (PF_INET,SOCK_PACKET)

Following this discovery, @AdolfBelka identified a related issue on the PPP GitHub page. Before the official fix in version 2.5.1, a patch has been made available for IPFire. Detailed information and discussions can be found here and here.

This patch is now integrated into Core Update 179 Testing. I encourage those interested to update again and test this version. I’ll be conducting my tests later today and will share the outcomes here.

Your feedback is invaluable. Let us know your findings.

Regards,
A G

adamgibbo · 26 August 2023 18:08

Hello everyone,

I hope you’re all doing well.

I’ve updated and restarted my IPFire firewall to the new testing release, and I can confirm that the bug observed by @pmueller and also present in my logs (though I initially did not see it) has been resolved.

Log Post-Update:

18:23:21  pppd[15842]:     Modem hangup
18:23:21  pppd[15842]:     Connect time 6894.4 minutes.
18:23:21  pppd[15842]:     Sent 760791880 bytes, received 3009721987 bytes.
18:23:21  pppd[15842]:     Connection terminated.
18:24:08  pppd[2467]:     Plugin pppoe.so loaded.
18:24:08  pppd[2467]:     PPPoE plugin from pppd 2.5.0
18:24:08  pppd[2467]:     pppd 2.5.0 started by root, uid 0
18:24:13  pppd[2467]:     PPP session is 24
18:24:13  pppd[2467]:     Connected to AA:BB:CC:DD:EE:FF via interface red0
18:24:13  pppd[2467]:     Using interface ppp0
18:24:13  pppd[2467]:     Connect: ppp0 <--> red0
18:24:13  pppd[2467]:     CHAP authentication succeeded
18:24:13  pppd[2467]:     CHAP authentication succeeded
18:24:13  pppd[2467]:     peer from calling number AA:BB:CC:DD:EE:FF authorized
18:24:13  pppd[2467]:     local IP address 192.168.XX.XX
18:24:13  pppd[2467]:     remote IP address 10.XX.XX.XX
18:24:13  pppd[2467]:     primary DNS address XXX.XX.X.XXX
18:24:13  pppd[2467]:     secondary DNS address XXX.XX.X.XXX

Observations:

The previous issue with the message 'pppd uses obsolete (PF_INET,SOCK_PACKET) is now resolved.
The connection was terminated and re-established successfully without any issues.

In summary, the updated release appears stable in my setup and addresses the previously noted issues.

Thanks to @AdolfBelka and everyone involved.

Best regards,
A G

adamgibbo · 30 November 2023 14:44

Hello everyone,

Firstly, I apologise for reviving this older thread. I’m reaching out to the community for insights regarding a potential issue I’ve encountered with the PPP configuration in IPFire, particularly concerning MTU/MRU settings.

Background: After transitioning to a different machine and connection type since the testing of PPP 2.5.0, I’ve observed some unexpected behavior related to MTU/MRU settings. My ISP supports RFC 4638 (baby jumbo-packets), prompting me to adjust the MTU and MRU to 1500 via the IPFire WUI. However, these changes don’t seem to be reflected in the actual connection.

When I check the MTU of the ppp0 network using ip link show ppp0, it consistently shows:

19: ppp0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1492 qdisc htb state UNKNOWN mode DEFAULT group default qlen 3

This output indicates that the MTU remains at the default 1492, despite attempts to update it to 1500 in the WUI.

I’m seeking input on whether this could be indicative of a bug in the PPP implementation or if there are known limitations with jumbo frames over PPPoE in IPFire. Any insights or suggestions for further troubleshooting steps would be greatly appreciated before I proceed to file a report on Bugzilla.

tphz · 30 November 2023 15:39

Please see if the information on the following page is helpful
https://www.sonicwall.com/support/knowledge-base/how-can-i-optimize-pppoe-connections/170505851231244/

Regards

bonnietwin · 30 November 2023 15:59

I have found where the MTU and MRU values are put into the ppp settings file via the pppsetup.cgi WUI page code.
You should be able to check that in the /var/ipfire/ppp/settings file. I believe that you should find the MTU you have set in that file.

What I have not been able to find is any code that uses those values from the settings file and I have also checked back in Core Update 100 and not found anything.
It could be that I am not looking correctly so maybe someone else more familiar with the ppp code in IPFire could check it out.

cfusco · 30 November 2023 16:20

I see eval $(/usr/local/bin/readhash /var/ipfire/ppp/settings) in /etc/ppp/ip-up. Can be this the code you were looking for?

bonnietwin · 30 November 2023 16:45

It looks like it might be. I will have a look at it.

Many thanks

ms · 30 November 2023 20:33

There is no code in place that would stop you from doing this, although I have never heard of this before. It will probably not be worth it for the performance gain, but I am curious…

Could you enable verbose logging and send us what the ISP is sending you?

One limitation could be, that the physical Ethernet interface will have its MTU set to 1500 no matter what. That way, you will probably never be able to transmit a packet larger than 1492, but you should still see a higher MTU on the PPP interface.

We do not set the MTU manually, but rely on pppd to do this. Maybe it is a bug in pppd, indeed.

adamgibbo · 30 November 2023 23:49

Thanks @bonnietwin, I have checked /var/ipfire/ppp/settings and the 1500 MTU value does indeed show in there:

...
MRU=1500
...

So it appears that the value change in the WUI is making modifications to the file at /var/ipfire/ppp/settings, but it is not applying the value to the connection.

To further investigate, I conducted ping tests to ping.ipfire.org with different payload sizes:

A test with a 1472-byte payload (ping -D -s 1472 ping.ipfire.org) resulted in packet fragmentation, indicating an operational MTU of less than 1500.
However, a test with a 1464-byte payload (ping -D -s 1464 ping.ipfire.org) was successful, aligning with an operational MTU of 1492.

This discrepancy suggests that while the settings file reflects the updated MTU/MRU values, these are not being effectively applied to the PPPoE connection.

Every little helps I am just exercising my inner nerd with this one.

Thanks for this insight. It led to a successful implementation of baby jumbo frames on IPFire, albeit manually:

After setting the red0 interface to 1508 MTU with ip link set dev red0 mtu 1508 and doing the same to make the ppp0 interface 1500 MTU, I confirmed the settings:

2: red0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc cake state UP mode DEFAULT group default qlen 1000
21: ppp0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp

I then used ping -D -s 1472 ping.ipfire.org to confirm successful transmission:

~]$ ping -D -s 1472 ping.ipfire.org
PING fw01.ipfire.org (81.3.27.38) 1472(1500) bytes of data.
[1701387261.723207] 1480 bytes from fw01.ipfire.org (81.3.27.38): icmp_seq=1 ttl=55 time=21.6 ms
[1701387262.725028] 1480 bytes from fw01.ipfire.org (81.3.27.38): icmp_seq=2 ttl=55 time=21.1 ms
[1701387263.727628] 1480 bytes from fw01.ipfire.org (81.3.27.38): icmp_seq=3 ttl=55 time=21.8 ms
[1701387264.728997] 1480 bytes from fw01.ipfire.org (81.3.27.38): icmp_seq=4 ttl=55 time=21.3 ms
[1701387265.730216] 1480 bytes from fw01.ipfire.org (81.3.27.38): icmp_seq=5 ttl=55 time=20.6 ms
^C
--- fw01.ipfire.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 20.636/21.279/21.797/0.406 ms

I guess IPFire can now be considered RFC 4638 compliant (kinda). IPFire never stops surprising me. Thank you all for the work and insights. This community is invaluable.

ms · 4 December 2023 17:17

Hmm, it should do this here:

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/networking/red;hb=81b3cf237ccd48d7e0481b3d81b0406fa66ce578#l442

I suppose your use-case is just rather rare, because most people will get the MTU from their ISP and that is it. Can you confirm that any configured MTU is missing from the pppd command line? It could still be that pppd does not use the given value.

adamgibbo · 4 December 2023 18:54

Thanks for showing interest @ms

After resetting the MTU and MRU values to auto-negotiate in the WUI (left blank), the ppp0 interface defaulted to an MTU of 1492, which is standard for a PPPoE connection (1500 - 8 = 1492 bytes, accounting for the PPPoE overhead). The physical interface red0 was set at the standard Ethernet MTU of 1500.

Then I set both MTU and MRU to 1500 in the WUI and rebooted the system. Post-reboot, here are the observations:

The red0 interface retained the MTU setting of 1500 (should be 1508 to allow for overhead)
The ppp0 interface remained at an MTU of 1492 (should be 1500).
However, the pppd process showed the MTU and MRU values as 1500 (/usr/sbin/pppd ... mtu 1500 mru 1500), indicating that the settings were correctly passed to pppd.

These findings suggest that while the IPFire system correctly passes the MTU/MRU settings to the pppd process, the actual MTU of the PPPoE connection (ppp0) does not change, likely due to the inherent 8-byte overhead of PPPoE which is missing from red0.

Below are the results from ps aux | grep pppd with both auto-negotiate and WUI set to 1500 MTU:

MTU Auto-negotiate:

# ps aux | grep pppd
root      2577  0.0  0.0   9692  6384 ?        S    18:01   0:00 /usr/sbin/pppd plugin pppoe.so red0 usepeerdns defaultroute noipdefault noauth default-asyncmap hide-password nodetach noipv6 noaccomp nodeflate nopcomp novj novjccomp nobsdcomp user [REDACTED USERNAME] lcp-echo-interval 20 lcp-echo-failure 5 -pap
root      4127  0.0  0.0   6500  2544 pts/0    S+   18:02   0:00 grep pppd

MTU Set to 1500 in WUI:

# ps aux | grep pppd
root      2576  0.0  0.0   9692  6388 ?        S    18:12   0:00 /usr/sbin/pppd plugin pppoe.so red0 usepeerdns defaultroute noipdefault noauth default-asyncmap hide-password nodetach noipv6 noaccomp nodeflate nopcomp novj novjccomp nobsdcomp user [REDACTED USERNAME] lcp-echo-interval 20 lcp-echo-failure 5 -pap mtu 1500 mru 1500
root      6098  0.0  0.0   6500  2520 pts/0    S+   18:36   0:00 grep pppd

ms · 6 December 2023 11:00

Trying my best

This is good, but it seems that they cannot be applied. Fair.

There is an option to enable debugging on the “dialup” page. That way, we can see what IPFire and your ISP are negotiating to confirm that the ISP is actually okay with the 1500 bytes, but pppd caps it later on.

Another thing to attempt would be to manually set the MTU of red0 to 1508 or even larger and see if the ppp0 interface will then configure the correct MTU of 1500 bytes.

Would you like to give this a try?

tphz · 6 December 2023 11:33

I wonder if the information on the following pages might be helpful

https://idea.popcount.org/2020-08-02-orange-ftth-on-a-custom-router/
https://idea.popcount.org/2023-04-01-orange-ftth-and-ipv6---part-two/

Regards