I am looking for a simple solution to indicate (e.g. with an additional LED) if a host on the other side of the VPN is accessible or not.
I was looking at the GPIO pins made available on the board. However they are bound as I2C (GPIO 16 and 17) and TX/RX (GPIO 10 and 9) interfaces and it seems that a new build of the firmware would be necessary to release them and make them a simple digital output. I don’t want to touch the original firmware other than adding a script.
Another idea i followed was to use the I2C or serial Interface as such. Obviously it requires a bit more than a LED and a resistor. I found a 8x8 led dot matrix module with an integrated I2C controller. Problem is, it requires Vcc 5V and the pinout of the AR 750 only provides 3.3V…
I am using now an ESP (NodeMCU), connected via Wifi to the AR750 running a simple sketch to enable the blue onboard led, if the remote host behind the vpn tunnel is reachable. This is a bit unreasonable.
I have not found a simple solution, maybe you have any idea?
You can use the built in LED, if you want. I have mine set to blink when vpn is transferring data. You go into the advanced settings, and look for LED.
Thanks for your feedbacks. I set aside the original 2G and 5G wlan status indication and use them for my purposes now to indicate internet and vpn connectivity (led 2G is on, if internet is available and led 5G is on, if vpn is up and the remote network is reachable). And here is, how it works:
set LED functions to „none“ in the glinet admin web tool. The leds should then be switched off.
upload the two scripts below (e.g. to /usr/bin/). If sftp does not work you can use in your ssh console: cat > full-path-and-filename and simply copy and paste the content of the script (use ctrl-d to get back to your prompt). Be careful, the cat > command overwrites everything of the file. Check better twice the correct spelling of the filename before you enter into the command
chmod u+x full-path-and-filename
now you can check the scripts by calling them without arguments.
to let them call frequently by the system add the cron configuration with the glinet admin web tool or crontab -e
Note: the vpn check also restarts the openvpn process and reloads the network configuration. Maybe not necessary in a stable and static vpn environment but I have faced vpn problems, after the remote side has changed their IP address.
The scripts are modifications from what I have found this in this forum. And I am not sure, if the 8.8.8.8 (google dns) actually works worldwide.
And here are the scripts:
inet_check.sh
#!/bin/sh
#
# crontab -e
# */1 * * * * test -x /usr/bin/inet_check.sh && /usr/bin/inet_check.sh
#
inet_led=/sys/devices/platform/leds-gpio/leds/gl-ar750:white:wlan2g/brightness
nc -z -w 5 8.8.8.8 53 >/dev/null 2>&1
online=$?
if [ $online -eq 0 ]; then
logger -t inet_check internet is online.
echo 1 > $inet_led
else
logger -t inet_check internet is offline.
echo 0 > $inet_led
fi
vpn_check.sh
#!/bin/sh
#
# crontab -e
# */1 * * * * test -x /usr/bin/vpn_check.sh && /usr/bin/vpn_check.sh
#
vpn_led=/sys/devices/platform/leds-gpio/leds/gl-ar750:white:wlan5g/brightness
# Should openvpn already be in operation? If not, nothing to do, exit.
enabled=$(uci get glconfig.openvpn.enable)
vpn_client=$(uci get network.ovpn) # removed when startvpn stopped explicitly
if [ "$enabled" != "1" ] || [ "$vpn_client" != "interface" ]; then
echo 0 > $vpn_led
exit 0
fi
# First hop should be to the internal VPN gateway (10.8.0.1) if VPN up. You might have a different first hop.
# If we're going through VPN then all is well, do nothing.
first_hop=$(traceroute 8.8.8.8 2>&1 | head -2 | tail -1 | awk '{print $2}')
if [ "$first_hop" == "10.8.0.1" ]; then
logger -t VPN_check VPN is fine.
echo 1 > $vpn_led
exit 0
fi
echo 0 > $vpn_led
#restart
logger -t VPN_check RESTART openvpn
killall openvpn 2>/dev/null
ovpn=$(uci get glconfig.openvpn.ovpn)
/usr/sbin/openvpn "$ovpn" &
(sleep 1; /etc/init.d/network reload) &
used this script on ar750 v3.1 and it worked fine with the wan ethernet port for internet access. when using wwan/wlan-sta and no wan/ethernet the vpn light would not work.
update; bad testing on my part. It works but it was having some issues with gettting a * * as a response from traceroute rather than 10.8.0.1. I thank you so much for this. I think I will rely on gli scripts to keep connecting so I chose to comment out the lines for re-establishing the network. thank you.