Is there any tool to monitor and log internet quality?
Last month I recognized problem with internet (speed and not availability). Some time it is enough to restart operator device (OH-735) via internal web page (http://192.168.9.1/). But I already get in situation where I need to plug-out device from power because even internal page was not accessible (this week there was evening when I need to do it 3x).
The first question is what connection do you have (cable ?)
The second question is whether you use DNS forward?
Third question - metallic or wifi connection? wifi?)
===
Scheduled Netmeter or measurement in RIPE Aatlas … reForis - Package Management - RIPE Atlas SW Probe … Create the necessary probe here - I can transfer the necessary credits to you (5,376,873)
Statistics - graph - Ping will serve similarly
I believe the NetMetr service is being shut down: CZ.NIC - SdruĹľenĂ CZ.NIC ukonÄŤĂ projekt NetMetr
NetMetr as a service which was worked on with the CZ gov is ending, the product for Turris devices continues: NetMetr končà :-( (sorry for czech, but basically → nothing changes for us).
It is internet for home O2 - Greenpacket model: OH-736 (LTE wireless).
My primary problem is not internet speed (I started to monitor it with python script running at cron every 4 hour).
What I am looking for is something like “ping each minute” to some server (google.com ?) but I am afraid I could be blocked after some time, so I am looking for some standard solution. I will try to have a look at RIPE Atlas
I guess there is one thing that actually should change: in the current code the ICMP latency measurement does not work reliably on full dualstack access links:
root@turris:~# netmetr
Checking uuid on the control server...
Requesting test config from the control server...
Starting ping test...
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
Starting speed test...
==== rmbt 027abd174 ====
connecting...
connected with 3 flow(s) for dl; 3 flow(s) for ul
pretest downlink start... (min 1s)
pretest downlink end.
rtt_tcp_payload start... (11 times)
rtt_tcp_payload end.
downlink test start... (5s)
downlink test end.
pretest uplink start... (min 1s)
pretest uplink end.
uplink test start... (5s)
uplink test end.
disconnecting.
dl_throughput_mbps = 94.044562
ul_throughput_mbps = 33.159306
Exiting.
uci: Parse error (invalid command) at line 5, byte 0
Your Sync code is: a67836dcbdb9
root@turris:~# ping -c 3 ipv6.speed.netmetr.cz
ping: unknown host ipv6.speed.netmetr.cz
root@turris:~# ping6 -c 3 ipv6.speed.netmetr.cz
PING ipv6.speed.netmetr.cz(speed.netmetr.cz) 56 data bytes
64 bytes from speed.netmetr.cz: icmp_seq=1 ttl=59 time=23.6 ms
64 bytes from speed.netmetr.cz: icmp_seq=2 ttl=59 time=23.4 ms
64 bytes from speed.netmetr.cz: icmp_seq=3 ttl=59 time=23.3 ms
--- ipv6.speed.netmetr.cz ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 23.325/23.478/23.666/0.226 ms
root@turris:~#
The issue exists for some years now, so maybe, if netmetr is going to stay with us, it is time now to fix that?
Did you submit the issue to the issue tracker? Issues · websites / netmetr.cz · GitLab
I don’t think anyone is actively hunting for bugs in such forums.
I sent an email to tech-support with the following ID [turris-rd #1114438]. And got the response that this would be solved by the next netmetr version, but that was end of 2020…
There was
indicating that the proper solution would be to upgrade netmetr, but by now, I am also fine with a gross hack to make it limp along until netmetr 2 will be deployed, if ever… 
II I am not wrong, Netmetr will stay with us only till we find the replacement with a different measurement technology that will be more suitable for you guys.
This version is already present in the development branches such as HBL and HBD. 
Great, so one more reason to make the jump
But everyone, getting back to topic:
If you want to check “quality” → netmeter (lets ignore the whole going to be removed / upgraded whatever). This right now can do a check how your network is running which includes ping / download / upload speed.
If you want to check “availability”, e.g. is my internet working? → do the ping in the statistics against a public endpoint.
Problem with both of these solutions is that you probably won’t get a notification when this happens out of the box, you would have to think about how to do it.
in this file /etc/cron.d/leds_control I call connCheck.sh which checks the gateway, DNS server and selected IP address on the internet. The connection problem is signaled by a change in the color of the LED
# zmena intensity svetla den - noc - maximum je 100
# WINTER
#00 07 * * * root rainbow intensity 3
#00 08 * * * root rainbow intensity 5
#00 09 * * * root rainbow intensity 9
#00 18 * * * root rainbow intensity 6
#00 19 * * * root rainbow intensity 3
#00 20 * * * root rainbow intensity 1
# SUMMER
00 06 * * * root rainbow intensity 3
00 07 * * * root rainbow intensity 5
00 08 * * * root rainbow intensity 9
00 19 * * * root rainbow intensity 5
00 20 * * * root rainbow intensity 3
00 21 * * * root rainbow intensity 1
# -------------------------------------
# check every 3 minute
*/3 * * * * root /root/connCheck.sh > /dev/null 2>&1
xx
#!/bin/sh
# výše je deklarace scriptu
# umĂstÄ›nĂ
# /root/conncheck.sh
# aktivovat následujĂcĂm pĹ™Ăkazem
# chmod +x /root/connCheck.sh
# check the connection to the Internet
# --- indications of activity befor test
# 1 blick
rainbow pwr disable
sleep 1s
rainbow pwr d000f0 enable
sleep 1s
# 2 blick
rainbow pwr disable
sleep 1s
rainbow pwr d000f0 enable
sleep 1s
# 3 blick
rainbow pwr disable
sleep 1s
rainbow pwr d000f0 enable
sleep 1s
rainbow pwr disable
sleep 1s
rainbow pwr 4d0000 enable
# --- check connection gateway, dns, internet ---
# "93.91.1.200-2" non-existent IP for testing functions
# check gateway ... wan, lan, pci = RED
if !(ping -W 1 -c 1 10.48.210.229)
# testovaci pozice
# if !(ping -c 1 93.91.1.200)
then
rainbow pwr b50000 auto
rainbow wan b50000 auto
rainbow lan b50000 enable;
# poziti pci narusuje trigger blikani
# -------------
# rainbow pci2 b50000 enable
# rainbow pci3 b50000 enable;
# -------------
# check DNS ... wan, lan = ORANGE
elif !(ping -W 1 -c 1 10.255.255.10) && !(ping -W 1 -c 10.255.255.20)
# testovaci pozice
#elif !(ping -c 1 93.91.1.200) && !(ping -c 93.91.1.201)
#elif !(ping -c 1 10.108.10.108) && !(ping -c 93.91.1.200)
then
rainbow wan db4e00 enable
rainbow lan db4e00 enable;
# check internet - wan, pci = PURPLE
elif !(ping -W 1 -c 1 77.75.74.172) && !(ping -W 1 -c 1 46.255.231.42) && !(ping -W 1 -c 1 216.58.205.228)
# testovaci pozice
#elif !(ping -c 1 93.91.1.200) && !(ping -c 1 46.255.231.42) && !(ping -c 1 216.58.205.228)
then
rainbow pwr d000f0 enable
rainbow wan d000f0 enable;
# if all ready - standard color
else
rainbow pwr b50000 auto
rainbow wan 0118e4 auto
rainbow lan 4e4d0e auto;
fiow that is really smart, totally forgot about the leds (I have them off 
).
The only thing what I am not sure of is if the originator of the post mentioned that he has speed issue and not availability.
So he would need to replace the ping with something like speedtest-cli / iperf / something.
But really cool solution you pasted.
Yes, the speed can be tested automatically every hour using Netmetr = it will be affected by the location of the server in the Czech Republic.
The optimal solution is, I think, to set the necessary on your own probe in the router - RIPE Atlas measurement
As I wrote above, it can use ping in Statistics as an indirect measurement
I guess the question is, do you intend to supply the servers yourself (then iperf2, iperf3 or netperf, seem to be the hottest contenders) or not. If not then Ookla’s speedtest.net infrastructure seems like a decent option giving its wide spread and high number of nodes (but there certainly is the risk of hitting an underperforming server).
I recommend smokeping … Im not running on turris, but on rpi box
https://oss.oetiker.ch/smokeping/