Hello development folks,
in order to get bug #12651 fixed, there is a patchset (https://patchwork.ipfire.org/project/ipfire/list/?series=2186) available, telling pppd not to ask for IPv6 configuration while dial-up, since at least British Telecom and Otenet seem to terminate a dial-up connection in case the peer fails to apply the IPv6 configuration, albeit IPv4 is working properly.
(For the records: A lengthy and fruitful discussion also took place at community.ipfire.org: https://community.ipfire.org/t/core-update-157-pppd-tries-to-fetch-an-ipv6-c...)
To ensure this patchset is actually solving #12651 without introducing any further issues, I hereby ask people having an IPFire machine running behind one of these two ISPs to test and report feedback here, or in Bugzilla (preferred).
Therefore, a precompiled pppd 2.4.9 is available at https://people.ipfire.org/~pmueller/ppp-2.4.9-noipv6.tar.gz, including its libraries and the patched initscript for networking on RED.
Please download this .tar.gz, and verify its SHA512 checksum first. It should look like this:
$ sha512sum ppp-2.4.9-noipv6.tar.gz 2c713a4517cbb9370fff6066c482451b759ccfa909e155ed07230eaa2adcb03217c4168c317ea376c5154f8e3b4464e9477c65ab996d5007e05f12d55914fe86 ppp-2.4.9-noipv6.tar.gz
Afterwards, please copy this archive onto your (testing) IPFire machine. Stop the running pppd first (this might take a few seconds), and backup its executable and the networking initscript:
$ /etc/rc.d/init.d/network stop red $ cp /usr/sbin/pppd /root/pppd-2.4.8.orig $ cp /etc/rc.d/init.d/networking/red /root/red.orig
Afterwards, unpack the .tar.gz, preserving file system attributes and writing the contents directly into /:
$ tar -xavf ppp-2.4.9-noipv6.tar.gz --acls --xattrs --xattrs-include='*' --no-overwrite-dir --preserve-permissions --numeric-owner -C /
Verify the pppd binary to be in place and operational (should return "pppd version 2.4.9"):
$ /usr/sbin/pppd --version
Start dial-up procedure using pppd 2.4.9 without IPv6 configuration enabled again (might also take a few seconds):
$ /etc/rc.d/init.d/network start red
Afterwards, your IPFire machine should have a stable dial-up connection to your ISP again.
$ ps aux | grep pppd | grep noipv6
should return the process command line of pppd, being invoked with "noipv6". In addition, "IPV6CP" must _not_ show up in /var/log/messages anymore after running the dial-up procedure with pppd 2.4.9 in place.
Please report back if this works like described above. Especially report back in case of any errors, side effects, or things behaving strangely afterwards. Your feedback is important to ensure we can safely ship pppd 2.4.9 without breaking anything else.
Thank you very much in advance.
Thanks, and best regards, Peter Müller
P.S.: Although this might sound like a contradiction: Please do not download and run any 3rd party software on your IPFire machine, especially not in productive environments (see also: https://community.ipfire.org/t/how-to-compromise-your-ipfire-system-in-two-e...) This case is a bit different, since the download source is the IPFire project infrastructure itself, and ppp is so critical we cannot simply throw it into the testing tree, risking to break peoples' internet connectivity. :-/