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 4Znp7v3xZMz339m for ; Wed, 30 Apr 2025 20:05:15 +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 4Znp7r0Cfyz2xw9 for ; Wed, 30 Apr 2025 20:05:12 +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 4Znp7p5xH6zDh for ; Wed, 30 Apr 2025 20:05:10 +0000 (UTC) Authentication-Results: mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=hkmrzXZc; 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=1746043511; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=svqjQF2707LzUPBymKxmK0GFaDZcHd6m2WTdQvPJ9VY=; b=WdT3djsD/xFvGwztMW/CmVHXSs5DdPHrv7zmkN2YCxZn4z9aEStkl1mu6nwqryD9oLq2SZ XM3npbGn06F4BVKQbwpJQBwNFWspXV2PxkHjTWIG30y/jYQFDjQMBYd8UBNkMIuvdy4PNj mV+GFMAKwTqzd0zHDfofVhablq0tL5Vfj2nmJADJyZF92PjEdtRm6CAOmPz2Ku3Kwn9h1t LvUyXl3uLyo5Z9inSd61r+KgWzBILSy48hiIWyAVyReXt70gnzdRWKvVwmmIMojtqJMa8D gnq8nuY0W9jdBg+yi81+8KymupTTjHVOZg0/TuOvB6XgVt852hNAwm7R8vnijA== ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1746043511; a=rsa-sha256; cv=none; b=jWrovARdkeJf0A3CgaE/AseggWDqmEwR7fPhY44Oun8wLht74+L+dwPKQVj/OP8/m2JDJc 66lobYLpyz9eKLTucKucy4UWAKhFAMIJbeE58g+5MTyPLOztBtvBn8J1eTsv45MdK1sMeE sJG8uiZetIH0KAhNFKuJksYMKeWxjMNwkQb03OVUymLz+ewFcXUoECsjFM8hW3EkVVR2mQ NwgT8z4iQfoWB+YB69MAIABbURWl6jxegJ/P3QIL+FOT5u/Xh9ZSjfRGvRcOEhG/AEaP3p i0SUgMH0Yt/6H3DRry8Qak1I0SDRAB9pPdpezcKwxVj1qi0Rtfd8kegHBVYAVA== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=hkmrzXZc; 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 3361A25A48 for ; Wed, 30 Apr 2025 22:05:10 +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 phStsuZi3pAd for ; Wed, 30 Apr 2025 22:05:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1746043509; bh=tZ3fTDxTPjJow0KV5/DqZn68pz/e4OHfZzOBmHdT9wM=; h=Subject:From:To:Date:In-Reply-To:References; b=hkmrzXZc8qaV6FtaFL/pwO4Heh2XpVMZ07jsnHbYfrrmh7UzrL1quUh+2ycj/gHuk Ykm0QFMyb9x5qtdQ2kJ8kVPHw6iii7qxIfreBgm40PUoPmQYkk19tJCv1qO0VIgOnk tdhanpsCtZ03YKfBVEdX1xMTkyuhW67i/ID/g41W4hjCBC5z/3DFUn/cBlzTQjKLvL Hd/QtPAoRRXUnGd2aqbuPh2LtzHflTWAc1y7cvh33oN2wN/7olSWHIQI8BcEIbTfsT fSv+WLJ6kZenkoOlrD/zPYudYQdN1RhVUU16oiyrrFBuU6aidps8Y4OhKj6m8WX6/N Tj26viX8iqRIA== 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 4E20D32EA55 for ; Wed, 30 Apr 2025 22:05:03 +0200 (CEST) Message-ID: <122a43b09bc36cb391916169194aa5bdc731fdd5.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 22:05:03 +0200 In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-/eVNsxwSS8rw2bRzts/v" 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: 4E20D32EA55.A0AED X-RoevensLambrechts-MailScanner: Found to be clean X-RoevensLambrechts-MailScanner-From: robin.roevens@disroot.org X-RoevensLambrechts-MailScanner-Watermark: 1746648303.95014@AajF1WBf5PzQvVQFuquGag X-Rspamd-Action: no action X-Rspamd-Server: mail01.haj.ipfire.org X-Rspamd-Queue-Id: 4Znp7p5xH6zDh X-Spamd-Result: default: False [-0.84 / 11.00]; SPF_REPUTATION_SPAM(2.62)[0.87456549618734]; R_DKIM_ALLOW(-1.68)[disroot.org:s=mail]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM(-1.00)[-0.999]; DKIM_REPUTATION(-0.95)[-0.95494033530895]; DMARC_POLICY_ALLOW(-0.50)[disroot.org,reject]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; BAYES_HAM(-0.01)[50.42%]; MX_GOOD(-0.01)[]; PREVIOUSLY_DELIVERED(0.00)[development@lists.ipfire.org]; ASN(0.00)[asn:50673, ipnet:178.21.23.0/24, country:NL]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RBL_SENDERSCORE_REPUT_BLOCKED(0.00)[178.21.23.139:from]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[disroot.org:+] --=-/eVNsxwSS8rw2bRzts/v Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tracepath returns a few bogon IP's and then no-reply for the gateway address. And TCP ping is not available on IPFire, I think. tcptracepath of lft comes to mind, but none of those are available on IPFire. Robin fairmont schreef op vr 25-04-2025 om 08:57 [-0600]: > Have you tried tracepath since it=C2=A0uses UDP? >=20 > tracepath -4 -b > or > tracepath -6 -b > or even > tracepath -b www.google.com >=20 > TCP ping would be another method. >=20 >=20 > On Tue, Apr 22, 2025 at 8:35=E2=80=AFAM Michael Tremer > wrote: > > 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 gatew= ay. > > 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 exampl= e. > >=20 > > We are also using collectd which is using liboping and that only > > supports ICMP. > >=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 > > 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 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud doorMailScanner [1] en lijkt schoon te zijn. [1] MailScanner http://www.mailscanner.info/ --=20 Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. --=-/eVNsxwSS8rw2bRzts/v Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi

Tracepath returns a f= ew bogon IP's and then no-reply for the gateway address.
And TCP = ping is not available on IPFire, I think. tcptracepath of lft comes to mind= , but none of those are available on IPFire.

Robin=

fairmont schreef op vr 25= -04-2025 om 08:57 [-0600]:
Have you tried tracepath since it uses UDP?

= tracepath -4 -b <outside ipV4 address>
or
tracepath -6 = -b <outside ipV6 address>
or even
tracepath -b www.google.com

TCP ping would be another method.


On Tue, Apr 22, 2025 at 8:35=E2=80=AFAM Michael Tremer <michael.tremer@ipfire.org>= wrote:
Hello Robin,

> On 20 Apr 2025, at 23:52, Robin Roevens <robin.roevens@disroot.org>= wrote:
>
> Hi All
>
> I recently changed my inte= rnet provider and I noticed that both the
> gateway graph on cgi-bin/= netother.cgi and my Zabbix gateway ping check
> no longer work.

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.

> It seems that my current provider blocks ICMP pings on the gate= way
> address.
> So I was wondering if it wouldn't be better to= use arping instead of
> normal ping to check the latency of the gate= way? This should always
> works regardless of firewalls of the provid= er.. I think?

This is a good idea. An ARP ping should alw= ays work, because otherwise there is no way to discover the layer 2 address= of the gateway. But that obviously only applies to internet connections th= at actually use ARP. PPP connections don=E2=80=99t use ARP for example.
=

We are also using collectd which is using liboping and that = only supports ICMP.

> I can quite easily change this Z= abbix check. But I'm not sure about the
> graph on netother.cgi; I ca= n 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= ?

I think so. It could be an option for the future.

If the gateway does not respond to pings, you should automatic= ally fall back to ping.ipfire.org <http://ping.ipfire.org/> though= . So the graph should always have some data to show.

Best= ,
-Michael

>
> Regards
> Robin
>=
> --
> Dit bericht is gescanned op virussen en andere gevaar= lijke
> inhoud door MailScanner en lijkt schoon te zijn.
>
= >



--=
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud d= oorMailScanner en lijkt= schoon te zijn.

--=20
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt sc= hoon te zijn. --=-/eVNsxwSS8rw2bRzts/v--