I recently upgraded one of my C7 hubs from 2.3.4.148 to 2.3.5.152. After doing that, the hub did not come back online and after many false diagnoses described in thread IP address reverted to old address on software update, I realized that the problem is that the hub was no longer being recognized by my router (a Ubiquiti "Dream Router"). It was as if the cable wasn't connected at all. I inserted a switch between the Hubitat hub and the router, and the connection worked fine. The connection also works fine when connected to a Motorola cable router (which is what I'm using currently).
Both ends are set for automatic negotiation, although I did try 100 MHz FDX as well and still no success.
Did something change in the Ethernet negotiation between these versions that might account for this behavior?
Note that this C7 hub is at our vacation home, and I'm currently not so I can't unplug things but can check settings remotely on both the router and hub.
While theoretically possible, it seems unlikely because:
To the best of my knowledge, platform updates alter the JVM instance that the Hubitat platform runs on, and not the underlying Linux OS. Ethernet negotiation would be an OS function.
The release notes do not indicate any such change.
There are lots of hub owners with Ubiquiti equipment, including beta testers. I haven’t seen anyone else mention a sudden loss of connectivity.
Any change of the underlying OS would be a very major change. It would be incongruent for such a major change to be rolled into a minor version platform update (2.3.5.146 -> 152).
Based on the symptoms you describe, if I had to guess, there’s an IP address conflict.
@user4390 As said, based on you saying you were double natting, I'd say that your DHCP servers were duking it out and DHCP is not being allowed to pass from your old router to the ubiquity. Though I would need to see things diagrammed.
As long as the two networks are on different IP ranges, I don't see anything wrong with double nat and having DHCP services on both. The "outer" router
dhcp would service it's devices, including the wan address of the "inner" router. The inner router dhcp service would service the devices on the LAN side, with no passthru between.
I do this all the time in my home lab. As long as the WAN and LAN sides are on different subnets, works fine.
I would agree with @aaiyar that it's likely IP conflict with both networks being on the same ranges.
This was a 2.3.4 to 2.3.5 upgrade, so not just a maintenance thing. I don't know Hubitat's version numbering criteria, so it's hard to say whether a change of this sort might have happened. I have read some of the release notes, but not all of them.
Yes, Ubiquiti equipment is common, but this is a relatively new product. I'm not ruling out the possibility that the problem is on that end, but the fact that it happened when I upgraded the Hubitat tends to point here.
The two routers are NATing to different subnets: 192.168.0/24 and 192.168.1/24. I'm fairly certain there isn't an address conflict there. Rough diagram:
One thing that the address conflict and DHCP conflict theories don't explain is that the UDR doesn't show an Ethernet connection to the Hubitat when it is connected as shown above, but if I insert an Ethernet switch between the UDR and Hubitat it does, and the Hubitat works fine using an IP address obtained from the UDR. That to me points to a physical/link layer problem rather than something IP-related.
