From patchwork Wed Jul 7 19:49:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Peter_M=C3=BCller?= X-Patchwork-Id: 4492 Return-Path: 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 ; 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 ; 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 ; 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?= 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-Language: en-US X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" 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 --- 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}"