My vera is in some sort of error state right now. I can load it’s interface via local IP on my lan, but the app has stopped working. Support tunnels won’t come up. And it’s looping over some weird network traffic that looks to me like some script someone wrote to check “is the internet working”:
[root@GW-Primary named]# tcpdump -i enp3s0 host 192.168.35.100 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:53:01.085279 IP 192.168.35.100.46375 > 192.168.0.1.53: 3+ A? 1.openwrt.pool.ntp.org. (40)
21:53:01.169201 IP 192.168.35.100.34342 > 192.168.0.1.53: 6+ A? vera-us-oem-authd12.mios.com. (46)
21:53:01.341960 IP 192.168.35.100.50473 > 192.168.0.1.53: 7346+ A? vera-us-oem-authd11.mios.com. (46)
21:53:01.697183 IP 192.168.35.100.35921 > 192.168.0.1.53: 11+ A? wikipedia.org. (31)
21:53:03.565313 IP 192.168.35.100.43645 > 192.168.0.1.53: 3503+ A? 0.openwrt.pool.ntp.org. (40)
21:53:03.802491 IP 192.168.35.100.45070 > 192.168.0.1.53: 12+ A? yahoo.com. (27)
21:53:03.964957 IP 192.168.35.100.47118 > 192.168.0.1.53: 7+ A? www.facebook.com. (34)
21:53:04.281012 IP 192.168.35.100.52664 > 192.168.0.1.53: 12+ A? vera-us-oem-authd11.mios.com. (46)
21:53:06.088840 ARP, Request who-has 192.168.32.1 tell 192.168.35.100, length 46
21:53:06.088921 ARP, Reply 192.168.32.1 is-at 00:0d:b9:40:07:4e, length 28
21:53:06.090669 IP 192.168.35.100.51528 > 192.168.0.1.53: 4+ A? 1.openwrt.pool.ntp.org. (40)
21:53:06.173270 IP 192.168.35.100.48232 > 192.168.0.1.53: 7+ A? vera-us-oem-authd12.mios.com. (46)
21:53:06.347408 IP 192.168.35.100.53367 > 192.168.0.1.53: 7347+ A? vera-us-oem-authd11.mios.com. (46)
21:53:07.992551 IP 192.168.35.100.33875 > 192.168.0.1.514: SYSLOG user.notice, length: 183
21:53:08.105518 IP 192.168.35.100.33875 > 192.168.0.1.514: SYSLOG user.notice, length: 181
21:53:08.168065 IP 192.168.35.100.33875 > 192.168.0.1.514: SYSLOG user.notice, length: 104
21:53:08.570525 IP 192.168.35.100.48272 > 192.168.0.1.53: 3504+ A? 0.openwrt.pool.ntp.org. (40)
21:53:08.991144 IP 192.168.35.100.34604 > 192.168.0.1.53: 2+ AAAA? www.amazon.com. (32)
21:53:09.286301 IP 192.168.35.100.38933 > 192.168.0.1.53: 13+ A? vera-us-oem-authd11.mios.com. (46)
21:53:11.130787 IP 192.168.35.100.55100 > 192.168.0.1.53: 2+ A? 2.openwrt.pool.ntp.org. (40)
21:53:11.694633 IP 192.168.35.100.38169 > 192.168.0.1.53: 8+ AAAA? vera-us-oem-authd11.mios.com. (46)
21:53:11.864379 IP 192.168.35.100.45913 > 192.168.0.1.53: 7348+ AAAA? vera-us-oem-authd12.mios.com. (46)
21:53:13.534836 IP 192.168.35.100.46358 > 192.168.0.1.53: 2+ A? google.com. (28)
21:53:13.574994 IP 192.168.35.100.40783 > 192.168.0.1.53: 3505+ A? 0.openwrt.pool.ntp.org. (40)
21:53:13.995095 IP 192.168.35.100.53885 > 192.168.0.1.53: 3+ AAAA? www.amazon.com. (32)
21:53:15.952507 IP 192.168.35.100.56189 > 192.168.0.1.53: 2+ A? google.com. (28)
21:53:16.135975 IP 192.168.35.100.39295 > 192.168.0.1.53: 3+ A? 2.openwrt.pool.ntp.org. (40)
21:53:16.697297 IP 192.168.35.100.47390 > 192.168.0.1.53: 9+ AAAA? vera-us-oem-authd11.mios.com. (46)
21:53:16.869307 IP 192.168.35.100.44267 > 192.168.0.1.53: 7349+ AAAA? vera-us-oem-authd12.mios.com. (46)
This mess all started when I changed my home lan from 192.168.0.0/24 to 192.168.32.0/22 because… every appliance needs an IP address now…
I think I can probably work around this by adding the old IP back on my gateway, so it can answer to dns there, but I was just curious, what is the vera trying to do??? (if anyone recognizes these dns queries) What script is it running?
the Vera isn’t answering on it’s ssh port any more either which is a pain in the butt. I thought it had survived the re-ip just fine before, because it’s a dhcp client and I just updated all the reservations at once. But something broke.
Hello!
You got it right, Vera constantly tries to verify if it has a stable connection by sending requests to those very common sites and checking their response.
In this case, what you can try is by setting a standard DNS address like Google’s and see if it improves, this can be done by going to Settings → Net & Wi-Fi and setting up the DNS accordingly, if it still giving you trouble please let us know.
I was stepping on my own feet apparently…
There is a disturbing quantity of hosts on my home networks these days. I use DHCP reservations and maintain and internal only DNS zone to name these hosts in a meaningful way consistent no matter what phone or laptop or device is referencing the names.
So I cannot use public DNS servers for things like the Vera in my home or they will not be able to resolve internal names for other network costs which are often home automation related anyway.
Many years ago, I thought I was having trouble getting the Vera to recognize and use the DNS server referenced by my DHCP server. I think the Vera was putting 8.8.8.8 then it’s resolv.conf despite being given my local DNS server via DHCP. So I put a line in rc.local to overwrite resolve.conf manually with the right IP.
When I re-subnetted the house last week, the “right IP” for DNS changed, but I had long forgotten about my sullying rc.local.
I was pulling my hair out yesterday after my post and decided to search the entire file system of the Vera for the string 192.168.0.1, and found humble little rc.local waiting for me to fix it. That seems to have satisfied the connectivity checks.
It does concern me a little bit though. I thought Vera was supposed to be capable of operating without the cloud. And yet my Vera was continuously rebooting I think when it was failing these connectivity checks. A number of my devices were using the Wi-Fi provided by the Vera and they were having a hell of a time staying connected.
I was depending on that Wi-Fi to be a simple transparent ethernet bridge from wired ethernet to wireless. But of course it’s provided by the kernel, which isn’t working during a reboot so devices were going up and down like crazy.
It’s looking much more stable now. And I’ve written a couple programs to identify devices that aren’t behaving right on the network. Anything requesting a DHCP address more often than it’s lease time would imply for example.
I also use Arpwatch on the lan and I think that the vera was doing some sort of arp proxying because I would get bogon alerts for the Mac addresses of devices that were using the Vera’s Wi-Fi and those Mac addresses were transmitting from 0.0.0.0. It could have been the DHCP discover packets but I doubt that. I’m sure our watch ignores those by default otherwise everything would throw bogons.
1 Like
I was about to say I wish it didn’t automatically reboot when the connectivity check failed. But I can also totally see the reasoning for that. You wanted to just start working again automatically for people who don’t know what an IP address is.
What would you think about changing the behavior of those automatic reboots so that instead of happening instantly they happen after a certain delay and that delay is exponential in nature.
So the first reboot happens immediately and if it comes back up and there is no connectivity and then it waits 1 minute and then reboots. If it comes back up and still no connectivity and then it waits 2 minutes. Then for 8, 16 etc maxing out at a couple hours or maybe 12?
Immediately before shutdown the very good right the delay it wants the next boot to take to a file on disk. And during boot up that file is red and stored in memory and then deleted from disk so if a reboot is caused by a user power cycling it the delay does not apply and it starts over fresh.
If connectivity didn’t fix itself in the first 10 minutes chances are it’s probably not going to fix itself in the next 10.
An exponential back off like this will decrease stress on already broken networks.
And let’s face it and end user is going to know to power cycle the device by hand if it’s not working, after they fix their ISP.
I understand, this could probably be done by modifying the script that checks that, however, the team is now focusing on the newer eZLO Platform for those firmware related changes, I will share that information with my manager and hopefully this will be checked, for now what we can do is add your desired DNS to one of the files the information is being requested from., for that you will need to enable remote access, let me know if you want me to continue and if so, you can PM me the DNS.