Use technique other than ping to assess connection status

[hugoh]

It looks like T-Mobile started blocking pings, and so the connection looks down even when it's not. This broke this tool for me – I'm assuming for others too.

We should add a different mechanism, such as DNS lookup or HTTP request.

[tarunVreddy]

I'm not seeing a block of pings on my connection. Did you make a network change? Or maybe it is happening but geographically. It would be bad network policy to do it though.

[hugoh]

It's unclear how broad it is: https://reddit.com/r/tmobileisp/comments/y3uqto/no_reply_to_pings_today/

[Thaine1690]

If it helps, this is the route-test script that I use now that I cannot get a ICMP reply on TMOHI:

#!/bin/bash
# Checks for WAN connectivity via curl6 (avoid IPv4 emulation)
# Usages: $0 <reboot_if_fail>

# add your website targets here
targets=(
'2606:4700:4700::1111'
'2620:119:35::35'
'2001:4860:4860::8888'
)

reboot_if_fail=$1 

# Print Config 
/tmo-monitor/tmo-monitor.py --skip-bands --ping-count 0

for host in $targets
do
  curl -g -6 -Is -m 1 --head --interface $intf http://[$host]:80/ 2>$1 | grep -w "200\|301"
  if [ $? == 0 ]
  then
    echo "Online"
    exit 0
  fi
done 
 
# fail
 echo "Failed"
  if [ $reboot_if_fail == 1 ]
  then
  echo "Forcing Reboot"
    /tmo-monitor/tmo-monitor.py --reboot
  fi
exit 1

[highvolt-dev]

related to #13

[highvolt-dev]

Http based connectivity tests added in https://github.com/highvolt-dev/tmo-monitor/releases/tag/v2.0.0-beta8 - still could use DNS other means of testing.

[scheblein]

http is working, but it appears to still be performing the ping test?

2023/03/27 14:16:16 [DEBUG] Enabled file logging to /var/log/tmo-monitor.log
2023/03/27 14:16:16 [DEBUG] Starting new HIT connection (1): 192.168.12.1:80
2023/03/27 14:16:16 [DEBUG] http://192.168.12.1:80 "POST /IMI/u1/auth/login HTTP/1.1' 200 403
2023/03/27 14:16:16 [DEBUG] Starting new HTTP connection (1): 192.168.12.1:80
2023/03/27 14:16:16 [DEBUG] http://192.168.12.1:80 "GET /TMI/v1/network/telemetry?get=all HTTP/1.1'
200 2356
eMB ID check passed, on <redacted>.
2023/03/27 14:16:16 [DEBUG] Starting new HITP connection (1): 192.168.12.1:80
2023/03/27 14:16:16 [DEBUG] http://192.168.12.1:80 "GET /IMI/u1/gateway?get=all HTTP/1.1" 200 1089
Camping on <redacted>.
Camping on <redacted>.
PING google.com (142.250.190.14) 56(84) bytes of data.

--- google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time Oms


2023/03/27 14:16:26 [DEBUG] Starting new HTTPS connection (1): google.com:443
2023/03/27 14:16:29 [DEBUG] https://google.com:443 "GET /generate_204 HITP/1.1" 204 0
No reboot necessary.
2023/03/27 14:16:29 [INFO] 4G: <redacted> | 5G: <redacted> | EMB ID: <redacted> | Avg Ping: -1 ms | Uptime: 43248 sec

my .env file

# Rename file to `.env` to use.
# The .env file will be loaded from the current or (recursive) parent directories.
# All settings are prefixed with `tmo_` to allow for common `.env` files at the root.

# Gateway model
tmo_model=ARCKVD21

# Trashcan login settings
tmo_username=admin
tmo_password=<redacted>

# Connectivity check
tmo_connectivity_check=http

# Reboot settings: minimum uptime (seconds) & reboot on failed check {True, False}
tmo_http_reboot=True

# General settings
tmo_logfile=/var/log/tmo-monitor.log
tmo_log_all=True

when setting tmp_connectivity_check to http, can we skip the ping test?

[highvolt-dev]

Thanks for reporting, @scheblein - I was originally going to remove the call to ping when the connectivity check is set to http, but I realized the logging behavior expects to call ping for recording the latency - so right now the connectivity check is only used for determining whether or not to reboot, not whether ping is called or not. Ideally, I'd like to call httping to measure latency and perform HTTP-based connectivity checks that way we can still record a latency but with a different provider than an ICMP ping.