From patchwork Thu Apr 11 15:01:00 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adolf Belka X-Patchwork-Id: 7725 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 (secp384r1) server-digest SHA384 client-signature ECDSA (secp384r1) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4VFjZT570zz3wwD for ; Thu, 11 Apr 2024 15:01:21 +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 (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4VFjZR14nMz1Gx; Thu, 11 Apr 2024 15:01:19 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4VFjZQ5vR3z32qd; Thu, 11 Apr 2024 15:01:18 +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 (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4VFjZP2FbJz2ytM for ; Thu, 11 Apr 2024 15:01:17 +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 (secp384r1) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4VFjZL1Db1zGf; Thu, 11 Apr 2024 15:01:14 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1712847675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=66YX4ivmE8elh5U7OcoyYT61bgAdyKwQSDqkC8RvJV8=; b=6m3+5vh4a9rJ9FqsSUIA5e8uSyYF1rpuEJhiuFYaNsNVv57QqyB0Mtoh8bc872+xpEQm98 M1ddOYVsx6jCvdBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1712847675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=66YX4ivmE8elh5U7OcoyYT61bgAdyKwQSDqkC8RvJV8=; b=h5j5eJ8Q6SeBoyn/1svQyD4YWnJy0/m7ZJiBPZt7PYry0QzKJ7yuabDHA6phtrOpcCWSqX wFfUX+MNQ0S8auFB7ltnsyNJu9p9njGiQzRTuinmAyv5fwN9XmUY3YRLxIY2419kgjCqQT pjXetDYtGmBePQ40HFY2kQXUNDPZkd1q4I2zFkb9lP4CXosFUZO1lC9V290htVCEBbjTK9 9UeP5pOf4p7nZrbzs6OQoHViFh22HRjgeEwF+72V2K/yNQ6aJ/6ID5QUdizH7JUZSrUBbU 1Tyrw0GS7c/XGMVX/cKNgw+TU+3WSse34brwoAV7Mw4OgPhhVcU9tNJTU0YDzw== From: Adolf Belka To: development@lists.ipfire.org Subject: [PATCH 1/9] ipsec-interfaces: Fixes bug12763 Date: Thu, 11 Apr 2024 17:01:00 +0200 Message-ID: <20240411150108.21573-1-adolf.belka@ipfire.org> MIME-Version: 1.0 Message-ID-Hash: YLD54XA555MWPWV6ZVZFEYV3353MR73A X-Message-ID-Hash: YLD54XA555MWPWV6ZVZFEYV3353MR73A X-MailFrom: adolf.belka@ipfire.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: IPFire development talk Archived-At: <> List-Archive: <> List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: - Some of the ip route commands are not redirected to null. This causes the "FIB table does not exist" message from bug12763 - This patch makes all ip route commands get redirected to null, preventing the error message from being seen at boot. - One of the ip rule commands is not redirected to null. This causes the "RTNETLINK answers: no such file or directory" message. - This patch makes all ip rule commands get redirected to null, preventing the error message from being seen at boot. - Additional patches in this set ensure that all ip route and ip rule commands in all IPFire code is redirected to null unless the output of the ip route or ip rule command is used in a variable for use elsewhere in the code. - Tested on my vm system and confirmed that the fix in ipsec-interfaces stops the "FIB table does not exist" and "RTNETLINK answers: no such file or directory" messages during boot. Fixes: Bug#12763 Tested-by: Adolf Belka Signed-off-by: Adolf Belka --- src/scripts/ipsec-interfaces | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/scripts/ipsec-interfaces b/src/scripts/ipsec-interfaces index 23512b9bd..974d3ac84 100644 --- a/src/scripts/ipsec-interfaces +++ b/src/scripts/ipsec-interfaces @@ -107,15 +107,15 @@ main() { local interfaces=() # Flush IPsec routes - ip route flush table "${ROUTE_TABLE}" + ip route flush table "${ROUTE_TABLE}" >/dev/null 2>&1 # Remove lookups - ip rule del lookup "${ROUTE_TABLE}" + ip rule del lookup "${ROUTE_TABLE}" >/dev/null 2>&1 # We are done when IPsec is not enabled if [ "${ENABLED}" = "on" ]; then # Enable route table lookup - ip rule add lookup "${ROUTE_TABLE}" prio "${ROUTE_TABLE_PRIO}" + ip rule add lookup "${ROUTE_TABLE}" prio "${ROUTE_TABLE_PRIO}" >/dev/null 2>&1 while IFS="," read -r "${VARS[@]}"; do # Check if the connection is enabled @@ -158,7 +158,7 @@ main() { log "Creating route to ${rightsubnet} (via ${address} and ${RED_INTF})" ip route add table "${ROUTE_TABLE}" "${rightsubnet}" proto static \ - dev "${RED_INTF}" src "${address}" + dev "${RED_INTF}" src "${address}" >/dev/null 2>&1 done # No interface processing required