It completely bricked my kvm, however I was able to recover via usb OTG. uboot recovery did not work.
Do you believe that the problem was the script? Many users have stopped this service for avoiding pinging dns servers without problem.
Maybe the Gl.Inet team could add an option to configure the ping interval, either in the GUI or through the glkvm.com portal if that is needed. Just an idea!
The LED program will be modified on version 1.8 to ping the gateway instead of public IP addresses such as 8.8.8.8.
2 Likes
That will be nice
1 Like
An interesting change in behavior for the LED, it no longer indicates cloud access but instead that an IP has been configured (assuming the local gateway responds to pings). Personally, I'd rather:
- If cloud access is disabled but we receive a valid DHCP lease assume it's all good (pinging a configurable IP on the network would be nice, but that's a configuration issue that adds complexity).
- If cloud access is enabled, ping a GLiNet-owned hostname once a second. If more than 5(?) consecutive pings fail assume the Internet is down and flash the LED. If more than 2(?) consecutive pings succeed assume the Internet is up and turn it solid.
However, in 2018 ago 8.8.8.8 was handling over a trillion DNS requests a day (a quick search doesn't show more recent data). Since the router advertising the AnyCast address is probably responding to ICMP instead of the DNS infrastructure I think a GLiNet-based DDoS would mean that you've got a pretty massive sales volume 
This maybe anecdotal but I was getting major artifacts on my screen every once in a while, this totally stopped after I disabled the LED. Since I’ve blocked internet access perhaps the heavy traffic was casing these issues?