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 4ZppdQ01kRz2xw9 for ; Fri, 2 May 2025 11:30:50 +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 4ZppdL342dz2xh0 for ; Fri, 2 May 2025 11:30:46 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZppdK4Vg3zWR; Fri, 2 May 2025 11:30:45 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1746185445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GnPPfOEi4scjdyDfP413rtZh5Wb3SiGVE/rG+Ya5LTE=; b=gkYkLvVJz9F5RO0my7hT5WOLc/URU10lEX6Bt5cxThtdY8Cmcd/hvgMnt9WnH3SrE9U+EN MCOXPopMGdnSNWDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1746185445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GnPPfOEi4scjdyDfP413rtZh5Wb3SiGVE/rG+Ya5LTE=; b=KjSpE7FFB8YJlXRRkClfTCgyj5kMc5SGZnGxFM9TTvc1ymHAQBeEW+zssqE9vvujOGPdPl f+8eiMJgYcdOVKQHt2bb4Q9S51jGuuWEwt5G2ON5i4CSZVTzpR1mE5jGgm5APPEEE5hteA nclGgOC6inb2yevosC6YVXkQjtqd/I5Xe6uSN6AYS7+MBac0OwkUemf4QHRnMWsbTtV7yn zj5pajon314IxNf1/59tli20CAYNmpEpD3+sG0JIAJoY08POUhrjCUYkDfAXDQZzYk8kpA mYXkqkp+r08FiE2bOtVLRtMVY0las87qycZiE67rU3OqancNxaaK8M/LOJToFg== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: ARP ping instead of ICMP ping for gateway latency check ? From: Michael Tremer In-Reply-To: <8adbd09e56f45934de702c00a295fbd13c6c343e.camel@disroot.org> Date: Fri, 2 May 2025 12:30:45 +0100 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E6A8A6D-4607-450C-861B-B3A3C87A28B3@ipfire.org> References: <8adbd09e56f45934de702c00a295fbd13c6c343e.camel@disroot.org> To: Robin Roevens Hello Robin, > On 30 Apr 2025, at 22:04, Robin Roevens = wrote: >=20 > Hi Michael >=20 > 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. >=20 > 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; [ > ! $? =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. 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. >>=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.. 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. >>=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. 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#Clien= t_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=E2=80=99t 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=E2=80=99t 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=E2=80=A6 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=3Dnetwork.git;a=3Dblob;f=3Dsrc/networkd/stats-co= llector.c;h=3Dc10602ec0fe7c22531f4444869fa6c902539791e;hb=3DHEAD -Michael > Regards > Robin >=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 door MailScanner en lijkt schoon te zijn.