Re: ARP ping instead of ICMP ping for gateway latency check ?

[Robin Roevens <robin.roevens@disroot.org>]

Hi Michael

Michael Tremer schreef op di 22-04-2025 om 15:35 [+0100]:
> Hello Robin,
> 
> > On 20 Apr 2025, at 23:52, Robin Roevens <robin.roevens@disroot.org>
> > wrote:
> > 
> > Hi All
> > 
> > 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.
> 
> Yes, some ISPs don’t 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 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?
> 
> 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’t 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; [
! $? == 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.
 
> 
> 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..

> 
> > 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?
> 
> I think so. It could be an option for the future.
> 
> If the gateway does not respond to pings, you should automatically
> fall back to ping.ipfire.org <http://ping.ipfire.org/> though. So the
> graph should always have some data to show.
> 
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 ? 

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
> 
> > 
> > Regards
> > Robin
> > 
> > -- 
> > Dit bericht is gescanned op virussen en andere gevaarlijke
> > inhoud door MailScanner en lijkt schoon te zijn.
> > 
> > 
> 
> 

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.