From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZnqTG3B52z339k for ; Wed, 30 Apr 2025 21:05:22 +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) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZnqTB6d1Nz2xw9 for ; Wed, 30 Apr 2025 21:05:18 +0000 (UTC) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 4ZnqT9507DzCD for ; Wed, 30 Apr 2025 21:05:17 +0000 (UTC) Authentication-Results: mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=K7xuPIVg; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org; dmarc=pass (policy=reject) header.from=disroot.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1746047117; 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:dkim-signature; bh=bJOYsPAR+qh0GNb6+ZpBbiPhmXtMTfURS9y1yc2+RtA=; b=vmAJFoX1jaseWyVyx97kSI8qrNTEr4YSztdaoyWW3epdX8X4ViFF1GR9/ZfV3X3yLqFf7S RoWvGfgYKiwIc7v3Kb1Nxf4mP7PFtvNlQDTb5hJO5M0Xjncn4bArLNDa0S1k3GmlZIw1U9 Pmf/UaGK7E6Nvi0vH4qX2tyW3X18icVInz8u32/Qj0egll5n0kICEahvmPCmmGtyMZIauB 99ySZ2P0g4vO5lW29p+c9zF1DGojEiS+3pOOkwV7C9dAzrmEQ3cv5PJpd5ZA4fXqXJxnZB CoMHKbkEyJc5z8LRvAnDSYKoAHIquY0xpM84FZeVfKguExGIUcOUPfEu/bPkWQ== ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1746047117; a=rsa-sha256; cv=none; b=gKMdw5lYC9/As9MgkVc2Iq2OD5tbUjkCrT6GABy8asllFKiWi6PzJA4Dg705Jf0KHPDRIv 4oic9Ghc4mqpZKPA1T0WVFzL1pwCreJ2xS3APi74sAT5ECy0Qs1qDwPNnb9dBTSzPvoEwf N+KPWe2W/9ccMUPmopXI7FACz6Kt1JuLNFvzb6npqyh6KZBS6et0dUnKZ9jE0Hcf4JA/1X lGNRiDRp2YXMNqUL1xhFGPQZMmxuRqAN5is6MGhk+V5PWofb38BGmOm76k9YhJRoLrz7CU 7zj6EApc5muzIWnOHAPN6I4tbMbL32zr01TQuVzjbPRH/gcMomMJffVvdJUM3A== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=K7xuPIVg; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org; dmarc=pass (policy=reject) header.from=disroot.org Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 2B76C25D54 for ; Wed, 30 Apr 2025 23:05:17 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id SIBildL50_Je for ; Wed, 30 Apr 2025 23:05:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1746047086; bh=bJOYsPAR+qh0GNb6+ZpBbiPhmXtMTfURS9y1yc2+RtA=; h=Subject:From:To:Date:In-Reply-To:References; b=K7xuPIVgd2FXmi/MPoN/UEecy7hvzFwItP13c8H/z5QGV4Vuu8pa+ZJsmUJmaqeCX hUx5rNevC6DHYNiCUoGBMkHPEC88F1Sj/2OV4PqRY9+4j5MHAAMB/+/9rUtjN5yqvw WeQ0AaWcKixcgLFq6mXANiGrK1v7JTkwzyTQFa6a7QxoNDof/MeL/izIgN6h9FVO8Y nx3gi4lhW5nC9UDlr395cHKlPJ0FMcmOawqTVNWsqpQNiwTGGPLf5NhgcfZdpXgtm7 wnbZjynLUqKwsW2qOIWOPK8dVJjMAfK87lA1rA6++WskWoylaaw9J0qQvbyjnMGXVM esYg1/S7+UBdg== Received: from Chojin.roevenslambrechts.be (Chojin.roevenslambrechts.be [192.168.0.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (no client certificate requested) (Authenticated sender) by hachiman (MailScanner Milter) with SMTP id DBBFC32EB69 for ; Wed, 30 Apr 2025 23:04:43 +0200 (CEST) Message-ID: <8adbd09e56f45934de702c00a295fbd13c6c343e.camel@disroot.org> Subject: Re: ARP ping instead of ICMP ping for gateway latency check ? From: Robin Roevens To: development@lists.ipfire.org Date: Wed, 30 Apr 2025 23:04:43 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.1 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 X-RoevensLambrechts-MailScanner-ID: DBBFC32EB69.A0AED X-RoevensLambrechts-MailScanner: Found to be clean X-RoevensLambrechts-MailScanner-From: robin.roevens@disroot.org X-RoevensLambrechts-MailScanner-Watermark: 1746651885.13868@lLhbZgpn2HBfJfMSvHLRDA X-Rspamd-Action: no action X-Rspamd-Server: mail01.haj.ipfire.org X-Rspamd-Queue-Id: 4ZnqT9507DzCD X-Spamd-Result: default: False [-1.90 / 11.00]; SPF_REPUTATION_SPAM(2.61)[0.86939488606897]; R_DKIM_ALLOW(-1.64)[disroot.org:s=mail]; BAYES_HAM(-1.16)[88.77%]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM(-1.00)[-0.999]; DKIM_REPUTATION(-0.91)[-0.90597817656835]; DMARC_POLICY_ALLOW(-0.50)[disroot.org,reject]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; ASN(0.00)[asn:50673, ipnet:178.21.23.0/24, country:NL]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[development@lists.ipfire.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RBL_SENDERSCORE_REPUT_BLOCKED(0.00)[178.21.23.139:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; DKIM_TRACE(0.00)[disroot.org:+] Hi Michael Michael Tremer schreef op di 22-04-2025 om 15:35 [+0100]: > Hello Robin, >=20 > > On 20 Apr 2025, at 23:52, Robin Roevens > > wrote: > >=20 > > Hi All > >=20 > > I recently changed my internet provider and I noticed that both the > > gateway graph on cgi-bin/netother.cgi and my Zabbix gateway ping > > check > > no longer work. >=20 > Yes, some ISPs don=E2=80=99t respond do ICMP echo requests to the gateway= . I > have no idea why really, but it is not uncommon. >=20 > > It seems that my current provider blocks ICMP pings on the gateway > > address. > > So I was wondering if it wouldn't be better to use arping instead > > of > > normal ping to check the latency of the gateway? This should always > > works regardless of firewalls of the provider.. I think? >=20 > This is a good idea. An ARP ping should always work, because > otherwise there is no way to discover the layer 2 address of the > gateway. But that obviously only applies to internet connections that > actually use ARP. PPP connections don=E2=80=99t use ARP for example. I was already not aware that PPP connections don't use ARP :-) Then PPPoE probably also doesn't use ARP for the gateway? For the Zabbix agent gateway.ping check I was currently thinking about /usr/sbin/fping -q -r 3 gateway || /usr/sbin/arping -q -c 3 gateway; [ ! $? =3D=3D 0 ]; echo $? which should return a 1 whenever either ICMP ping or ARP ping gives a reply and 0 if neither reply, meaning that the gateway is down. This should cover most situations, except when PPP is used and the gateway is not replying to ICMP ping. =20 >=20 > We are also using collectd which is using liboping and that only > supports ICMP. So it seems.. there is also no arping plugin available for collectd. So it will have to icmp ping something.. or someone should write an arping plugin; but glancing at the source of the current ping plugin, I'm afraid that won't be me.. >=20 > > I can quite easily change this Zabbix check. But I'm not sure about > > the > > graph on netother.cgi; I can look into that if you all think that > > change would be a good idea? Or if anyone could give me some > > pointers > > on where to start looking? >=20 > I think so. It could be an option for the future. >=20 > If the gateway does not respond to pings, you should automatically > fall back to ping.ipfire.org though. So the > graph should always have some data to show. >=20 That is a good indication of the internet connection being alive. But I assume, depending on where you are in the world and what path the packets have to travel, it could have quite high ping timings possibly causing people to wrongly conclude that their internet connection is slow while that may not be the case (for servers geo-located closer to them). So I'm not sure if it is a good idea to transparently fall back to ping.ipfire.org when gateway does not reply. In Zabbix I can instead add ping.ipfire.org as a separate check to check if, independent of the availability of the gateway, there is an active internet connection. And I assume for people in Europe the timings can indeed be a valuable indication when gateway pings are not possible. But probably not very relevant in other parts of the world ?=20 In collectd it could also simply be added as a separate graph by adding the host ping.ipfire.org in the ping plugin config. I don't think collectd is able to 'fall back', at least not without some script that regularly checks on gateway pings and changes the collectd config whenever the gateway is not pingable and vice-versa when pingable (again) and then restarts collectd. But I do think it could be valuable to just add a ping.ipfire.org graph, even when gateway is pingable, to check on the difference in timings between those two (at least in Europe)? Regards Robin > Best, > -Michael >=20 > >=20 > > Regards > > Robin > >=20 > > --=20 > > Dit bericht is gescanned op virussen en andere gevaarlijke > > inhoud door MailScanner en lijkt schoon te zijn. > >=20 > >=20 >=20 >=20 --=20 Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.