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

[Michael Tremer <michael.tremer@ipfire.org>]

Hello Robin,

> On 30 Apr 2025, at 22:04, Robin Roevens <robin.roevens@disroot.org> wrote:
> 
> 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?

That is correct.

PPP itself encapsulates IP packets that are being sent over a PPP session. That session is being negotiated using pppd. Historically that happened over a serial line (think dial-up modem). When DSL came up PPPoE was introduced. So after the IP packet has been put into a PPP packet, an Ethernet header is being added as well to send it over the Ethernet link.

For ARP you need Ethernet, but is only a companion protocol for IP. PPP packets are not IP; the IP packet is inside them (but that could of course be anything else).

ARP is also only being used for IPv4. In IPv6 it has been merged into IP and is called neighbour discovery.

So, was much as I liked your idea. Typing out all of this leaves us with a zoo of options. Therefore it makes sense to attempt a simple ping :)

> 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.

For IPv4, yes. This would actually be absolutely okay for most users.

But since we are thinking about it, I would love to have a plan for an IPv6-only link.

>> 
>> 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 would be happy to do this. This should not be very hard, but we should check if there any interest upstream for this. It might be very niche.

>> 
>>> 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.

I believe this is just to keep the graph colourful. It probably does not say a lot.

In the past I had plans to maybe distribute a couple of ping targets around the world, but what is the point? There are so many huge countries in the world that even if a target would in that country, the IPFire box might still be thousands of kilometres away.

Therefore I like your idea and I would like to explore this all a litte bit further :)

I like the test on layer 2. That should always work, but we have a lot of different scenarios to cover:

* Classic Ethernet (run ARP or ND)

* PPP (in flavour of 5G/4G/etc.) - well there is no layer 2 here really. ICMP might be the only option and there is no other option if the gateway does not respond.

* PPPoE - We could send a PADI packet (https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet#Client_to_server:_Initiation_(PADI)) but I am not sure how much the ISPs would like this. Could this break anything?

Did I forget anything?

I would like to be very consistent so that these checks are actually comparable. We don’t want to test the CPU power of the gateway on the other side, but we want to test the latency of the link.

> 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 ?

No, from Australia you might be close to a second. The actual latency of the IPFire box to the ISP probably cannot be extracted from that.

That being said, if that would be possible the graph could actually show the deviation from the average or median. Then the actual distance does not really matter so much.

> 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)?

I don’t mind. The firewall in HAJ still has a couple of free CPU cycles to deal with those packets and if not we will find another solution. However, we could never load-balance because pinging two different hosts will probably break this all again…

I am happy to have a solution implemented with the current system and collectd. In IPFire we would have a different solution and therefore I am trying to think a little bit wider. Any code written could probably be parted between those two solutions.

The IPFire 3 approach is having a daemon that manages all things networking. It would be able to send any packets we want (ARP requests, ND, PADI, etc.) and once there has been a response send the data over dbus to broadcast it to other services that are interested in this data. We are currently doing this with interface statistics from all interfaces. That way, collecty (our collectd replacement) does not have to know which network interfaces exist or even have privileges to talk to them.

The code for that is here: https://git.ipfire.org/?p=network.git;a=blob;f=src/networkd/stats-collector.c;h=c10602ec0fe7c22531f4444869fa6c902539791e;hb=HEAD

-Michael

> 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.