| Message ID | 47f6b552-e533-2e20-3d0b-c7bad78c88ac@ipfire.org |
|---|---|
| State | Accepted |
| Commit | 52764dbe7f6439045040ab35719953cf178063b9 |
| Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4GKqkp2CFfz3xCm for <patchwork@web04.haj.ipfire.org>; Wed, 7 Jul 2021 19:49:38 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4GKqkp048Hz1Yb; Wed, 7 Jul 2021 19:49:37 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4GKqkn6G5Vz2xTN; Wed, 7 Jul 2021 19:49:37 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4GKqkm62chz2xQs for <development@lists.ipfire.org>; Wed, 7 Jul 2021 19:49:36 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4GKqkm1kPfzZ6 for <development@lists.ipfire.org>; Wed, 7 Jul 2021 19:49:36 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1625687376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZUjxORIFKLSLdRfr2/glqhHL5irGAyzRDzswM52ME/Q=; b=y2Mq7nAMKjXMVIumZjLjx++AaE7aIyD1YWFqOFa9h9SPYANGr7d11Qr0CJ60nh3yd0s7YX Zm+8wVE8N6QNaqAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1625687376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZUjxORIFKLSLdRfr2/glqhHL5irGAyzRDzswM52ME/Q=; b=Mpevo4+LujA5yNqlnHQgYE6r9P1eS4sg4vWrv4n2SXcq2X+Xbj9xXfjUGnu2aeBsGoV4iB fC5J8h+fyPqrc4YwM1eyHldoTC2ymNbbTR7NBwNsBtRgHeLL6FkgJJRINnZaE25nd1/Pvu n/8poq8cqbnUaJaMFMNfGWXO8RtjxJJ5pyWujLgVP8uIHPTL+BgBkgdrhEyLEUgSWGnR/w D0+VHItTh0TbviR6CKHj0s+6oSWquBTrXIVGr2g9+h+1/FNMyo61e+7SB2dnfBSq5cpesX JhdFWX2PsKh2ZWYZhf49M1LgNFi48UIQ7tHUvQeOwitsOuzqFDDx7ZNRqMmpvw== Subject: [PATCH 2/2] Tell pppd not to ask for IPv6 addresses during dial-up To: development@lists.ipfire.org References: <4d95ffef-feac-4505-7528-d45a247165fb@ipfire.org> From: =?utf-8?q?Peter_M=C3=BCller?= <peter.mueller@ipfire.org> Message-ID: <47f6b552-e533-2e20-3d0b-c7bad78c88ac@ipfire.org> Date: Wed, 7 Jul 2021 21:49:35 +0200 MIME-Version: 1.0 In-Reply-To: <4d95ffef-feac-4505-7528-d45a247165fb@ipfire.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
| Series |
[1/2] Revert "Revert "ppp: update to 2.4.9""
|
|
Commit Message
Peter Müller
July 7, 2021, 7:49 p.m. UTC
pppd 2.4.9 supports IPv6 and asks for an IPv6 configuration by default.
Setting the received prefix in the kernel will never work, however, as
the rest of IPFire 2.x does not support IPv6.
pppd notices the ISP about this, and at least Otenet (GR) and British
Telecom (several countries) decide to close a dial-up connection then.
German DTAG seems to ignore such errors silently.
This patch adds an option to the pppd call to prevent asking for an
IPv6 configuration, hence avoiding this errors.
To apply this patch, it is necessary to ship ppp 2.4.9 again. Since I
have no access to a testing machine behind an ISP supporting IPv6, this
patch unfortunately is untested.
Fixes: #12651
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
---
src/initscripts/networking/red | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hello, > On 7 Jul 2021, at 20:49, Peter Müller <peter.mueller@ipfire.org> wrote: > > pppd 2.4.9 supports IPv6 and asks for an IPv6 configuration by default. > Setting the received prefix in the kernel will never work, however, as > the rest of IPFire 2.x does not support IPv6. > > pppd notices the ISP about this, and at least Otenet (GR) and British > Telecom (several countries) decide to close a dial-up connection then. > German DTAG seems to ignore such errors silently. > > This patch adds an option to the pppd call to prevent asking for an > IPv6 configuration, hence avoiding this errors. > > To apply this patch, it is necessary to ship ppp 2.4.9 again. Since I > have no access to a testing machine behind an ISP supporting IPv6, this > patch unfortunately is untested. In general, but especially for such critical things, this is unacceptable. Please look for someone who can test this. > > Fixes: #12651 > > Signed-off-by: Peter Müller <peter.mueller@ipfire.org> > --- > src/initscripts/networking/red | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/initscripts/networking/red b/src/initscripts/networking/red > index ca0a8ae58..56f8ebb66 100644 > --- a/src/initscripts/networking/red > +++ b/src/initscripts/networking/red > @@ -410,7 +410,7 @@ case "${1}" in > ### Standard PPP options we always use > # > PPP_STD_OPTIONS="$PLUGOPTS usepeerdns defaultroute noipdefault noauth" > - PPP_STD_OPTIONS+=" default-asyncmap hide-password nodetach" > + PPP_STD_OPTIONS+=" default-asyncmap hide-password nodetach noipv6" > PPP_STD_OPTIONS+=" noaccomp nodeflate nopcomp novj novjccomp" > PPP_STD_OPTIONS+=" nobsdcomp user ${USERNAME} lcp-echo-interval 20" > PPP_STD_OPTIONS+=" lcp-echo-failure 5 ${AUTH}" > -- > 2.26.2
Hello Michael, thanks for your reply. > Hello, > >> On 7 Jul 2021, at 20:49, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> pppd 2.4.9 supports IPv6 and asks for an IPv6 configuration by default. >> Setting the received prefix in the kernel will never work, however, as >> the rest of IPFire 2.x does not support IPv6. >> >> pppd notices the ISP about this, and at least Otenet (GR) and British >> Telecom (several countries) decide to close a dial-up connection then. >> German DTAG seems to ignore such errors silently. >> >> This patch adds an option to the pppd call to prevent asking for an >> IPv6 configuration, hence avoiding this errors. >> >> To apply this patch, it is necessary to ship ppp 2.4.9 again. Since I >> have no access to a testing machine behind an ISP supporting IPv6, this >> patch unfortunately is untested. > > In general, but especially for such critical things, this is unacceptable. Full ACK. > Please look for someone who can test this. Well, with a high level of confidence, I can tell this patch does the job, since pppd's debug log show it is not asking for an IPv6 configuration afterwards. A PPPoE connection attempt to my ISP looks like this running pppd 2.4.9 before applying this patch: Jul 10 22:XX:XX maverick pppd[22492]: Plugin rp-pppoe.so loaded. Jul 10 22:XX:XX maverick pppd[22492]: PPPoE plugin from pppd 2.4.9 Jul 10 22:XX:XX maverick pppd[22492]: pppd 2.4.9 started by root, uid 0 Jul 10 22:XX:XX maverick pppd[22492]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12 Jul 10 22:XX:XX maverick pppd[22492]: dst ff:ff:ff:ff:ff:ff src REDACTED Jul 10 22:XX:XX maverick pppd[22492]: [service-name] [host-uniq dc 57 00 00] Jul 10 22:XX:XX maverick pppd[22492]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 30 Jul 10 22:XX:XX maverick pppd[22492]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[22492]: [service-name] [host-uniq dc 57 00 00] [AC-name REDACTED] Jul 10 22:XX:XX maverick pppd[22492]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12 Jul 10 22:XX:XX maverick pppd[22492]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[22492]: [service-name] [host-uniq dc 57 00 00] Jul 10 22:XX:XX maverick pppd[22492]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 30 Jul 10 22:XX:XX maverick pppd[22492]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[22492]: [service-name] [host-uniq dc 57 00 00] [AC-name REDACTED] Jul 10 22:XX:XX maverick pppd[22492]: Recv PPPOE Discovery V1T1 PADS session 0xe9b3 length 12 Jul 10 22:XX:XX maverick pppd[22492]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[22492]: [service-name] [host-uniq dc 57 00 00] Jul 10 22:XX:XX maverick pppd[22492]: PADS: Service-Name: '' Jul 10 22:XX:XX maverick pppd[22492]: PPP session is REDACTED Jul 10 22:XX:XX maverick pppd[22492]: Connected to REDACTED via interface red0.7 Jul 10 22:XX:XX maverick pppd[22492]: using channel 2 Jul 10 22:XX:XX maverick pppd[22492]: Using interface ppp0 Jul 10 22:XX:XX maverick pppd[22492]: Connect: ppp0 <--> red0.7 Jul 10 22:XX:XX maverick pppd[22492]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xc15c2203>] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xc15c2203>] Jul 10 22:XX:XX maverick pppd[22492]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xc15c2203>] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xc15c2203>] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [LCP ConfReq id=0x2 <mru 1492> <auth pap> <magic 0xc2d6cfac>] Jul 10 22:XX:XX maverick pppd[22492]: sent [LCP ConfAck id=0x2 <mru 1492> <auth pap> <magic 0xc2d6cfac>] Jul 10 22:XX:XX maverick pppd[22492]: sent [LCP EchoReq id=0x0 magic=0xc15c2203] Jul 10 22:XX:XX maverick pppd[22492]: sent [PAP AuthReq id=0x1 user="REDACTED" password=<hidden>] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [LCP EchoRep id=0x0 magic=0xc2d6cfac] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [PAP AuthAck id=0x1 ""] Jul 10 22:XX:XX maverick pppd[22492]: PAP authentication succeeded Jul 10 22:XX:XX maverick pppd[22492]: peer from calling number REDACTED authorized Jul 10 22:XX:XX maverick pppd[22492]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>] Jul 10 22:XX:XX maverick pppd[22492]: sent [IPV6CP ConfReq id=0x1 <addr fe80::REDACTED>] <<<<< Jul 10 22:XX:XX maverick pppd[22492]: rcvd [IPCP ConfReq id=0x1 <addr REDACTED>] Jul 10 22:XX:XX maverick pppd[22492]: sent [IPCP ConfAck id=0x1 <addr REDACTED>] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [LCP ProtRej id=0x1 80 57 01 01 00 0e 01 0a 6c 99 70 54 2e ec 75 2f] <<<<< Jul 10 22:XX:XX maverick pppd[22492]: Protocol-Reject for 'IPv6 Control Protocol' (0x8057) received <<<<< Jul 10 22:XX:XX maverick pppd[22492]: rcvd [IPCP ConfNak id=0x1 <addr REDACTED> <ms-dns1 REDACTED> <ms-dns2 REDACTED>] Jul 10 22:XX:XX maverick pppd[22492]: sent [IPCP ConfReq id=0x2 <addr REDACTED> <ms-dns1 REDACTED> <ms-dns2 REDACTED>] Jul 10 22:XX:XX maverick pppd[22492]: rcvd [IPCP ConfAck id=0x2 <addr REDACTED> <ms-dns1 REDACTED> <ms-dns2 REDACTED>] Jul 10 22:XX:XX maverick pppd[22492]: local IP address REDACTED Jul 10 22:XX:XX maverick pppd[22492]: remote IP address REDACTED Jul 10 22:XX:XX maverick pppd[22492]: primary DNS address REDACTED Jul 10 22:XX:XX maverick pppd[22492]: secondary DNS address REDACTED Jul 10 22:XX:XX maverick pppd[22492]: Script /etc/ppp/ip-up started (pid 22541) Jul 10 22:XX:XX maverick pppd[22492]: Script /etc/ppp/ip-up finished (pid 22541), status = 0x0 After applying this patch, these log lines are missing: Jul 10 22:XX:XX maverick pppd[26870]: Plugin rp-pppoe.so loaded. Jul 10 22:XX:XX maverick pppd[26870]: PPPoE plugin from pppd 2.4.9 Jul 10 22:XX:XX maverick pppd[26870]: pppd 2.4.9 started by root, uid 0 Jul 10 22:XX:XX maverick pppd[26870]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12 Jul 10 22:XX:XX maverick pppd[26870]: dst ff:ff:ff:ff:ff:ff src REDACTED Jul 10 22:XX:XX maverick pppd[26870]: [service-name] [host-uniq f6 68 00 00] Jul 10 22:XX:XX maverick pppd[26870]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 30 Jul 10 22:XX:XX maverick pppd[26870]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[26870]: [service-name] [host-uniq f6 68 00 00] [AC-name REDACTED] Jul 10 22:XX:XX maverick pppd[26870]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12 Jul 10 22:XX:XX maverick pppd[26870]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[26870]: [service-name] [host-uniq f6 68 00 00] Jul 10 22:XX:XX maverick pppd[26870]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 30 Jul 10 22:XX:XX maverick pppd[26870]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[26870]: [service-name] [host-uniq f6 68 00 00] [AC-name REDACTED] Jul 10 22:XX:XX maverick pppd[26870]: Recv PPPOE Discovery V1T1 PADS session 0xba2c length 12 Jul 10 22:XX:XX maverick pppd[26870]: dst REDACTED src REDACTED Jul 10 22:XX:XX maverick pppd[26870]: [service-name] [host-uniq f6 68 00 00] Jul 10 22:XX:XX maverick pppd[26870]: PADS: Service-Name: '' Jul 10 22:XX:XX maverick pppd[26870]: PPP session is REDACTED Jul 10 22:XX:XX maverick pppd[26870]: Connected to REDACTED via interface red0.7 Jul 10 22:XX:XX maverick pppd[26870]: using channel 3 Jul 10 22:XX:XX maverick pppd[26870]: Using interface ppp0 Jul 10 22:XX:XX maverick pppd[26870]: Connect: ppp0 <--> red0.7 Jul 10 22:XX:XX maverick pppd[26870]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xeeb8dc98>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xeeb8dc98>] Jul 10 22:XX:XX maverick pppd[26870]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xeeb8dc98>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xeeb8dc98>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [LCP ConfReq id=0x2 <mru 1492> <auth pap> <magic 0xd72b5643>] Jul 10 22:XX:XX maverick pppd[26870]: sent [LCP ConfAck id=0x2 <mru 1492> <auth pap> <magic 0xd72b5643>] Jul 10 22:XX:XX maverick pppd[26870]: sent [LCP EchoReq id=0x0 magic=0xeeb8dc98] Jul 10 22:XX:XX maverick pppd[26870]: sent [PAP AuthReq id=0x1 user="REDACTED" password=<hidden>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [PAP AuthAck id=0x1 ""] Jul 10 22:XX:XX maverick pppd[26870]: PAP authentication succeeded Jul 10 22:XX:XX maverick pppd[26870]: peer from calling number REDACTED authorized Jul 10 22:XX:XX maverick pppd[26870]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [IPCP ConfReq id=0x1 <addr REDACTED>] Jul 10 22:XX:XX maverick pppd[26870]: sent [IPCP ConfAck id=0x1 <addr REDACTED>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [IPCP ConfNak id=0x1 <addr REDACTED> <ms-dns1 REDACTED> <ms-dns2 REDACTED>] Jul 10 22:XX:XX maverick pppd[26870]: sent [IPCP ConfReq id=0x2 <addr REDACTED> <ms-dns1 REDACTED> <ms-dns2 REDACTED>] Jul 10 22:XX:XX maverick pppd[26870]: rcvd [IPCP ConfAck id=0x2 <addr REDACTED> <ms-dns1 REDACTED> <ms-dns2 REDACTED>] Jul 10 22:XX:XX maverick pppd[26870]: local IP address REDACTED Jul 10 22:XX:XX maverick pppd[26870]: remote IP address REDACTED Jul 10 22:XX:XX maverick pppd[26870]: primary DNS address REDACTED Jul 10 22:XX:XX maverick pppd[26870]: secondary DNS address REDACTED Jul 10 22:XX:XX maverick pppd[26870]: Script /etc/ppp/ip-up started (pid 26919) Jul 10 22:XX:XX maverick pppd[26870]: Script /etc/ppp/ip-up finished (pid 26919), status = 0x0 Basically, this debug looks looks pretty much the same as it did with pppd 2.4.8 before. While this is not a really authenticate test case, would you accept it as being sufficient? If not, I would write a short "call for testers" mail and seek for people sitting behind Otenet or British Telecom. Thanks, and best regards, Peter Müller > >> >> Fixes: #12651 >> >> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >> --- >> src/initscripts/networking/red | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/initscripts/networking/red b/src/initscripts/networking/red >> index ca0a8ae58..56f8ebb66 100644 >> --- a/src/initscripts/networking/red >> +++ b/src/initscripts/networking/red >> @@ -410,7 +410,7 @@ case "${1}" in >> ### Standard PPP options we always use >> # >> PPP_STD_OPTIONS="$PLUGOPTS usepeerdns defaultroute noipdefault noauth" >> - PPP_STD_OPTIONS+=" default-asyncmap hide-password nodetach" >> + PPP_STD_OPTIONS+=" default-asyncmap hide-password nodetach noipv6" >> PPP_STD_OPTIONS+=" noaccomp nodeflate nopcomp novj novjccomp" >> PPP_STD_OPTIONS+=" nobsdcomp user ${USERNAME} lcp-echo-interval 20" >> PPP_STD_OPTIONS+=" lcp-echo-failure 5 ${AUTH}" >> -- >> 2.26.2 >
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-configuration-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 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-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' internet connectivity. :-/
diff --git a/src/initscripts/networking/red b/src/initscripts/networking/red index ca0a8ae58..56f8ebb66 100644 --- a/src/initscripts/networking/red +++ b/src/initscripts/networking/red @@ -410,7 +410,7 @@ case "${1}" in ### Standard PPP options we always use # PPP_STD_OPTIONS="$PLUGOPTS usepeerdns defaultroute noipdefault noauth" - PPP_STD_OPTIONS+=" default-asyncmap hide-password nodetach" + PPP_STD_OPTIONS+=" default-asyncmap hide-password nodetach noipv6" PPP_STD_OPTIONS+=" noaccomp nodeflate nopcomp novj novjccomp" PPP_STD_OPTIONS+=" nobsdcomp user ${USERNAME} lcp-echo-interval 20" PPP_STD_OPTIONS+=" lcp-echo-failure 5 ${AUTH}"