From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Call for testers: pppd 2.4.9 without IPv6 configuration, solving bug #12651 Date: Tue, 13 Jul 2021 21:41:13 +0200 Message-ID: <5013a9d6-22a5-55b1-4fe7-64fce351f96d@ipfire.org> In-Reply-To: <11b68712-1e67-ff26-dfd5-57b3f8111ed2@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2755131130360514232==" List-Id: --===============2755131130360514232== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello development folks, in order to get bug #12651 fixed, there is a patchset (https://patchwork.ipfi= re.org/project/ipfire/list/?series=3D2186) available, telling pppd not to ask for IPv6 configuration while dial-up, sinc= e 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 commun= ity.ipfire.org: https://community.ipfire.org/t/core-update-157-pppd-tries-to-fetch-an-ipv6-co= nfiguration-despite-it-shouldnt-causing-dial-up-connections-to-be-terminated-= by-some-isps/5654) To ensure this patchset is actually solving #12651 without introducing any fu= rther issues, I hereby ask people having an IPFire machine running behind one of these two ISPs to test and rep= ort 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 > 2c713a4517cbb9370fff6066c482451b759ccfa909e155ed07230eaa2adcb03217c4168c317= ea376c5154f8e3b4464e9477c65ab996d5007e05f12d55914fe86 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=3D'*' = --no-overwrite-dir --preserve-permissions --numeric-owner -C / Verify the pppd binary to be in place and operational (should return "pppd ve= rsion 2.4.9"): > $ /usr/sbin/pppd --version Start dial-up procedure using pppd 2.4.9 without IPv6 configuration enabled a= gain (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 yo= ur 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=C3=BCller 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-easy-steps= /5652) 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' in= ternet connectivity. :-/ --===============2755131130360514232==--