Failed connection to EnvisaLink 4 - resolved

[jamesfpb]

Purchased Envisalink 4 and have been struggling with intermittent connectivity, really slow local access, packet loss and firmware update failure.
Envisalink is directly connected to Ubiquiti switch with Ubiquiti USG providing DHCP.

For reasons that I still don't understand, situation was fully resolved by disabling STP (Spanning Tree Protocol) and LLDP Med for the switch port where my Envisalink 4 connected. From assessing packet loss, I believe both settings are affecting connectivity but it's possible that one or other of the 2 is much more important.

Real PITA to work this out so wanted to share for the benefit of others.
I am curious if anyone can explain why these settings matter.

[Anarchy2007]

thanks jamesfpb, made my life much easier.

I just bought an EdgeRouter X and had the same micro packet drop issues. Disabling LLDP for switch0 seemed to resolve the issue for me.

Just as a side note I seemingly had the same issue years ago with a TP-Link MR200 (I think, I know it wasn't the MR400).

Here's a link to the issue mentioned above:
http://forum.eyez-on.com/FORUM/viewtopi ... 0&start=20

"Anyhow, I personally looked at your problem and looking some archival entries in our KB I found your issue. TP-LINK has a long-standing problem relating to an old version of Linux they use in their routers. This affects about 5 different models. The exact issue is that small UDP datagrams, like the encrytped Envisalink Event Packets, get their checksums corrupted by the router and dropped by subsequent network equipment. The Envisalerts firewall and load balancing servers drop all improperly formatted packets just like any other public service would."

[ChirpyTurnip]

So glad I found this post! Had been tearing my hair out trying to figure out what was going on as I couldn't get the firmware updates to work. I have a LGS528 switch and a pfSense firewall and I could see dropped packets to the EVL4, including CRC/Align and Fragment errors for a surprising number of packets....and was at a loss as to why this was happening and why the firmware wouldn't download. Support could tell me it was trying to download and would get about 25% of the way through before aborting...but couldn't see why anymore than I could. Just before I set up port mirroring to do a packet capture I found this post....turned off STP/LLDP on the port that the EVL4 is connected to and boom! Now on the latest firmware...still seeing some pack loss....

Bytes Received: 75065
Drop Events: 1
Packets Received: 430
Broadcast Packets Received: 1
Multicast Packets Received: 0
CRC & Align Errors: 1
Undersize Packets: 0
Oversize Packets: 0
Fragments: 1
Jabbers: 0
Collisions: 0
Packets of 64 Bytes: 16301
Packets of 65 to 127 Bytes: 583
Packets of 128 to 255 Bytes: 314
Packets of 256 to 511 Bytes: 900
Packets of 512 to 1023 Bytes: 176
Packets of 1024 and More Bytes: 0

and still cannot get a steady ping trace:

Reply from 192.168.1.15: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.15: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.15: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.15: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.15: bytes=32 time<1ms TTL=128
Request timed out.
Reply from 192.168.1.15: bytes=32 time<1ms TTL=128

But at least I've made progress....

[LordNelson1805]

Thank you SO much for posting this. I just migrated from a Linksys Velop mushed network to Unifi and all of the sudden my Hubitat <-> Envisalink integration stopped working. I struggled for a day thinking this was some sort of obscure problem I would never figure out, and then decided to google Envisalink and Unifi. To my delight I found your post.