EyezOn Forum

Need some help troubleshooting to solve the following problem:
My log is filled with many daily (sometimes hourly) "Network Supervision Fault" and "Network Supervision Restore" notices.

It makes remote access to the EvisaLink 2DS unreliable and difficult because commands queue-up during the fault, then execute after the restore. This resulted in the police arriving at the house once because the disarm commands seemed to stack up, then actually just toggle the alarm on/off/on/off...

Envisalink support looked at the log and agreed there are serious network communication errors, suggesting the likely causes of:
1) “Flakey” ethernet switch
2) “Flakey” router
3) WiFi link
4) Powerline Ethernet link

Since there is no WiFi link or Powerline Ethernet, I can eliminate 3 & 4. The 2DS had been plugged into a Switch, so I plugged it directly into the router, but still see the error pattern described above.

Not sure what to try or how to identify and fix the problem from here, which leaves me at #2, above. Any suggestions would be appreciated. Also, if anyone has experienced other causes besides the 4 above, please share the solution.

The router is the latest version Airport Extreme Simultaneously Dual Band and the 2DS is not plugged directly into it.

Do you also have a TL-250 or any other IP monitoring devices installed? I only see those entries in my logs when the TL-250 fails to communicate with the central (FTC errors). Since the 2DS doesn't need to resolve DNS, it really should not have communication issues, even if your router has DNS resolution issues. Are other IP based devices on the network having issue with communications?

stevew wrote:Do you also have a TL-250 or any other IP monitoring devices installed?

No.

Are other IP based devices on the network having issue with communications?

None of the other devices on my network are having issues, as far as I can tell from the end user perspective.

Cable issue to the 2DS perhaps?

stevew wrote:Cable issue to the 2DS perhaps?

Thanks. Worth trying. I'll swap the cable.

I have had this same issue over the last 3 days or so. I know the cabling is good, because I ran a full qualification test using a Fluke DTX1800 analyzer. The cable passed extended cat 6 tests, and since the 2ds only needs 100mbit/s there should be zero issue.

Eventually I rebooted the 2ds. I haven't had an issue since. My (pure guess) is a cumulative slow memory leak or corruption.

If you reboot your 2ds, do your issues dissapear too ?

Swapped the cable, rebooted the routers, rebooted the 2DS by clicking the "reboot" button via the web portal. Is there a reset/reboot button on the device?

Having swapped and checked just about everything I can imagine, tonight, I"ll try to plug the 2DS directly into the cable modem for a night, then check the log in the morning.

I've been having the same issues. (and everything's checked except for using a Fluke...)

Honestly, with the faults that I'm getting, it looks to be more than common tech-support issues.

When I get some time, I'll start some pcaps w/Wireshark to see if I can better analyze where things are dropping. Eyez-on, are you actually looking into this more than the simple ideas being offered? Looks like it has been a repeat topic.

Sometimes the best way to 'fix' something like this is to realize that anomalies exist and account for them in your code. It'd be great if you could spare some cycles to look into this a bit deeper even though for me, it's more of an annoyance than something that's causing queue backup.

Other than this issue, loving the Envisalink - thanks for a great product.

-Bonez

In addition to our own labs, Envisacor has roughly 50 BETA test sites around the world that run all our candidate firmware before it has been released. This gives us a good cross-section of network components and topologies.

Please believe me when I say that we cannot repoduce this behaviour at any site. The only evidence we have, albeit anecdotal, is that be switching out network components, or changing network topology, it has mitigated the problem. We have certainly expended way more than a few cycles on this issue.

If you could provide wireshark captures during an "event" that would be fantastic! Non-event traffic to the alerting servers run on port 4025 and provide heartbeats every 30 seconds. If there have been no heartbeats within the last 10 minutes, you get a Network Supervisory Fault.

PM me when you have the captures.

K-Man wrote:In addition to our own labs, Envisacor has roughly 50 BETA test sites around the world that run all our candidate firmware before it has been released. This gives us a good cross-section of network components and topologies.

Please believe me when I say that we cannot repoduce this behaviour at any site. The only evidence we have, albeit anecdotal, is that be switching out network components, or changing network topology, it has mitigated the problem. We have certainly expended way more than a few cycles on this issue.

If you could provide wireshark captures during an "event" that would be fantastic! Non-event traffic to the alerting servers run on port 4025 and provide heartbeats every 30 seconds. If there have been no heartbeats within the last 10 minutes, you get a Network Supervisory Fault.

PM me when you have the captures.

Fantastic, K-Man - I'll do so when I'm back home (on international travel for a few weeks still). It actually sounds like your code is already pretty tolerant of network inconsistencies much more than I thought (10 minutes is a long time). The events are happening a few times/day all of a sudden so it certainly could be that my internet provider has gone unstable. I'll give an equal amount of weight to pursuing details on that front.

best,
Bonez