[2/2] Tell pppd not to ask for IPv6 addresses during dial-up

Message ID 47f6b552-e533-2e20-3d0b-c7bad78c88ac@ipfire.org
State Accepted
Commit 52764dbe7f6439045040ab35719953cf178063b9
Headers show
Series [1/2] Revert "Revert "ppp: update to 2.4.9"" | expand

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

Michael Tremer July 8, 2021, 10:34 a.m. UTC | #1
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
Peter Müller July 10, 2021, 9:13 p.m. UTC | #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
>
Peter Müller July 13, 2021, 7:41 p.m. UTC | #3
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. :-/

Patch

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}"