From patchwork Wed Apr 13 08:00:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adolf Belka X-Patchwork-Id: 5506 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) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4KdZlS18XQz3x1Y for ; Wed, 13 Apr 2022 08:00:36 +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) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4KdZlN1NhKzjC; Wed, 13 Apr 2022 08:00:32 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4KdZlN0LnVz2xZr; Wed, 13 Apr 2022 08:00:32 +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) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4KdZlL5SL9z2xCV for ; Wed, 13 Apr 2022 08:00:30 +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) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4KdZlK26jrzdM; Wed, 13 Apr 2022 08:00:29 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1649836829; 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=QJs6EF8bzF7D0mtQs4DPBtrJ/UR7RsBHfdq8Ujn1Hg8=; b=gRYUKZPfGegjFacOMzZ6SYK1DX0fFuitHXaa+UtZ83vGs+dVE+s94Nh3Z4QTC7gqSq3few qqGObYF/5X0ScoAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1649836829; 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=QJs6EF8bzF7D0mtQs4DPBtrJ/UR7RsBHfdq8Ujn1Hg8=; b=UrDgHwHzUkY9/cDaLYDXihzp/V0TzwKUp9DapMnik843Sm8CTJht2Msd6nIZNzbl20HQfm SqCJKgcRjVG4XWryla5r/Jk+vB28/GXmpUIPn+AXUoKxDbKwj1tVDIs0FGXx2vpsg5LV82 3XNlyV6b/AKX7Q3IviJ8fE1X4MVoelOs6Xbw98vsr2dgHnerafuol+dapWnpz3Y/rhAhIJ DMlb9+Jr06q9bYvLKsF4ju3OZUhzPRywslrbOOB9+HyP/Ggw3t+YKeRRfrPcYwrKfA8r1u HUlfSnpNCCsyOSrgOL/dO0I6jixNmx3CZTbfhcgHEEk0Qn6SRSE57yft05m8SQ== From: Adolf Belka To: development@lists.ipfire.org Subject: [PATCH 1/2] wio.pl: Fix bug 12799 - Remove code scanning for all potential IP's on RED interface Date: Wed, 13 Apr 2022 10:00:19 +0200 Message-Id: <20220413080020.3664760-1-adolf.belka@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: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" - The lines to scan the red interface were introduced at the time of a patch to remove the IPFire start/stop function from wio. These lines are not related to that change but were included in the patch with no commit message. The same lines were also added into wio.cgi in the same patch set but in that case the lines were all commented out. - These lines look like they were most likely added to the code for investigation or debugging purposes. Looking at the lines in wio.pl the results obtained are not used elsewhere in wio for obtaining info on the status of the red interface. Deleting the lines did not affect anything related to the scanning, setup or monitoring of systems by wio. - The lines were wasting space but generally not creating a huge impact on pertformance. On my production system it scans my red and comes up with a list of 1022 IP's because of the subnet my ISP uses - xxx.yy.216.0/20 - Scanning those 1022 IP's and sorting them takes my system about 3 seconds. Without sorting it is around the same level. - In Bug#12799 the originator has an ISP that is using a private network that has a defined subnet of 10.0.0.0/8 This is 16,777,214 IP's to be scanned. Even without sorting my system would end up taking around 13 hours to do that. The bug originator found that on certain machines that he had IPFire on wio just never stopped scanning. - As these lines just seem to collect a large amount of IP's on red that are not related to the actual running red IP, as there was no commit message related to their introduction and as removing the lines on vm's running dhcp and static red interfaces and also on my running production system for 4 weeks has shown no impact on the monitoring capability this patch is being submitted to remove these lines from wio Fixes: Bug#12799 Tested-by: Adolf Belka Signed-off-by: Adolf Belka Reviewed-by: Bernhard Bitsch --- src/wio/main/wio.pl | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/wio/main/wio.pl b/src/wio/main/wio.pl index 91c6c1494..78c91eeb9 100644 --- a/src/wio/main/wio.pl +++ b/src/wio/main/wio.pl @@ -98,9 +98,6 @@ my ( $ping_i, $ping_t, $ping_ib, $ping_tb, $ping_iv, $ping_tv, $pingmode ) = ''; my ( @tmp, @arptmp, @myarray, @status, @arpclients ) = ''; my @ifaces = ('GREEN','BLUE','ORANGE'); -if ( $netsettings{'RED_TYPE'} eq 'STATIC' || $netsettings{'RED_TYPE'} eq 'DHCP' ) { - push (@ifaces, "RED"); -} if ( $mailsettings{'USEMAIL'} eq 'on' ) { $mailen = 'on'; } else { $mailen = 'off'; }