From patchwork Thu Dec 1 17:23:11 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Tremer X-Patchwork-Id: 6253 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 4NNNG92k6cz3xl3 for ; Thu, 1 Dec 2022 17:23:45 +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 4NNNFs6txbz2t5; Thu, 1 Dec 2022 17:23:29 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4NNNFp3PDcz30FB; Thu, 1 Dec 2022 17:23:26 +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 4NNNFl3pw4z30BT for ; Thu, 1 Dec 2022 17:23:23 +0000 (UTC) Received: from michael.haj.ipfire.org (michael.haj.ipfire.org [172.28.1.242]) (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 "michael.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4NNNFl2wfLz2PK; Thu, 1 Dec 2022 17:23:23 +0000 (UTC) Received: by michael.haj.ipfire.org (Postfix, from userid 0) id 4NNNFl2j85zTjlB; Thu, 1 Dec 2022 17:23:23 +0000 (UTC) From: Michael Tremer To: development@lists.ipfire.org Subject: [PATCH 22/29] network: dhcpcd fails to check link state for QMI interfaces Date: Thu, 1 Dec 2022 17:23:11 +0000 Message-Id: <20221201172318.3166615-22-michael.tremer@ipfire.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20221201172318.3166615-1-michael.tremer@ipfire.org> References: <20221201172318.3166615-1-michael.tremer@ipfire.org> MIME-Version: 1.0 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: , Cc: Michael Tremer Errors-To: development-bounces@lists.ipfire.org Sender: "Development" When acquiring an IP address, dhcpcd seems to think that the interface is down or does not work properly for some reason. It will subsequentially decide to exit which is not what we want here. Therefore this patch tells dhcpcd to ignore the link state and keep happily running. Signed-off-by: Michael Tremer --- 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 053b38405..2d68c1685 100644 --- a/src/initscripts/networking/red +++ b/src/initscripts/networking/red @@ -227,7 +227,7 @@ case "${1}" in ip link set "${RED_DEV}" up &>/dev/null # Start the DHCP client - dhcpcd_start "${RED_DEV}" + dhcpcd_start "${RED_DEV}" --nolink # Done exit 0