Can I just say kudos to you guys for getting in this thread and providing some real solutions and helping to determine problems.
7 Likes
Yes, the "fix" is to turn off the auto-negotiation. This also can be resolved by plugging the hub into a network switch that handles the link better.
1 Like
I told you I had an unmanaged D-link gigabit switch. I was wrong. It's an unmanaged TopLink switch. And FWIW, I haven't seen a consistent slowdown since then.
Using @bptworld's new Hub Watch Dog, there are occasional slow responses from test zigbee and z-wave devices, but these are very rare.
I wish I had some benchmarks from before I applied the auto-negotiation patch. Without that, my claims are subjective and anecdotal - and in my profession, we are trained to ignore such data points 
1 Like
I would imagine Cisco 2960s don’t exhibit this problem right ?
Jesus, I would hope not...
2 Likes
Lol okay. That’s what I’m using. 
Why does turning off auto-negotiate fix these Asus and Netgears? are their ports shipped set to fixed 1G, or 100M/full or something?
Here is the laundry list of switches (1 of each are connected to the router) -
Tenda 8-port desktop gigabit model G1008D
TP-Link 8-port gigabit switch model TL-SG108
Linksys 8-port gigabit switch SD2008 ver 3.0
Tenda 5-port gigabit switch SG105
I actually have one of those where it doesn’t work... no, they are not set to a fixed speed. Setting it to a fixed speed actually works around this problem.
It happens, sometime things that supposed to be “auto” or “smart” are not such thing. Chip incompatibilities, fluctuation in power or wrong protocol implantation are just a few possibilities. But I don’t think we will ever know unless we get someone from the switch/router manufacture hooked on Hubitat and troubleshoot the issue for us....
Fixing such issues is just so hard for Hubitat since there is no common approach you can take for all devices.
1 Like
You would think if Asus and Netgear are shipping routers with ports that dont negotiate properly, there would be mass outcry, and firmware updates to fix it....is this issue publicly documented anywhere else?
I have my Hue Bridge plugged into one of these. Could that cause any problems? My HE is directly connected to a Netgear X6S. Not that I am having any issues atm, just that I have been considering moving the Hue to be directly connected to the router since it is in a central location in the house.
@bobbyD Any plan to just push the "fix" to everyone to save some potential headache for some people?
BTW, is the US-8-60W a concern?
Honest to god, I didn’t care to look.... I have a fairly easy solution and I learned to chose my battles since I have kids.....
Out of experience I can say that sometimes you can come across a NIC that has a problem with a particular switch. Years ago that was much more common and it is less now but that still doesn’t mean that it doesn’t exist. The chips on both ends don’t like to play with each other.
Don’t get me wrong, not trying to blame Asus, Hubitat or NetGear here
1 Like
The problem is isolated and strictly related to C-5 hubs plugged in certain network switches, that likely are running outdated firmware, because not every model of a certain switch experiences this issue.
2 Likes
It’s not the firmware age, I promise you that. Running the latest that is available
2 Likes
So how much info about our hubs can you actually see?
How much control do you actually have over them?
Pushing a config to change low level network parameters which are generally kernel settings means you have a lot of remote access and power.
3 Likes
A lot less than you think. The "fix" is dormant in every hub. I can trigger it, if the hub is connected to the cloud. In @waynespringer79's case, for example, the cloud failed, so he had to run it from local network.
Makes me curious what else is "dormant"....
1 Like
5 Likes
Wikipedia:
The first version of the autonegotiation specification, in the 1995 Fast Ethernet standard IEEE 802.3u, was open to different interpretations. Although most manufacturers implemented this standard in one way, some others, including network giant Cisco, implemented it in a different way. Autonegotiation between devices that implemented it differently failed. Problems like this with autonegotiation led many network administrators to manually set the speed and duplex mode of each network interface card. However, the use of manually set configuration may also lead to duplex mismatches, in particular when two connected devices are:
One manually set to half duplex and one manually set to full duplexOne set to autonegotiation and one manually set to full duplexDuplex mismatch problems are difficult to diagnose because the network is apparently working, and simple programs used for network tests such as ping report a valid connection; however, the network is much slower than expected.
Basically any Auto-Negotiate at 100M or less can fail to negotiate properly. At 1gig and above, Auto-Negotiate works correctly and should always be used.
Therefore Hub C-6 * should use the 1gig chips
(*) no such thing.. yet.
5 Likes
