Posting this partly as a bug report and partly to ask whether anyone has seen this failure mode before, since it took me a week to isolate and the symptoms pointed everywhere except the actual cause.
Summary: My C-8 Pro (platform 2.5.1.152, purchased April 2026) has an Ethernet interface that passes small packets normally but drops the majority of full-size frames. The result is that ICMP and TCP handshakes succeed while nothing that requires a full-size frame ever completes — which produces a very confusing symptom set.
Symptoms as they first appeared:
- All outbound HTTP from the hub failed with "connect timed out," with occasional "Network is unreachable (connect failed)." This included the Sonos integration and a bare Rule Machine "Send GET" to a LAN device.
- The hub's web UI on 8080 and 8081 accepted TCP connections (Test-NetConnection returned True) but pages hung indefinitely, from multiple clients and browsers.
- Meanwhile the hub pinged fine at default packet size, populated the mDNS device list normally, and ran all Zigbee/Z-Wave automations without a hiccup. The diagnostic tool on 8081 was equally unreachable, so the usual repair paths were closed.
How I isolated it:
ping <hub>with default packets: 0% loss.ping <hub> -l 1472 -f(full size, don't fragment): 75% loss. This is the defining signature.- Reproduced with two cables (cat-5e and cat-6, both verified at gigabit on a laptop) and two switch ports. The laptop ran clean on the same cable and port where the hub failed — the fault follows the hub.
- The switch port links amber (100 Mbps fallback) with the hub, but gigabit with the laptop on the identical cable and port, suggesting the hub's port can no longer use all four pairs. Large-frame loss persisted even at the 100 Mbps fallback, across cold power cycles.
- Conclusive test: I dropped my client PC's interface MTU to 576, and
curl http://<hub>:8080/immediately returned HTTP 200 with the complete login page. The web server had been healthy the entire time — only large frames were dying in the hub's Ethernet path. - A network reset via the recessed button, several cold power cycles, and toggling between DHCP and static made no difference.
Current state: The hub runs on Wi-Fi and behaves perfectly — snappy UI, no timeouts — which further confines the fault to the Ethernet interface.
What I'm asking:
- Has anyone seen a C-8 Pro Ethernet port fail this way — partial, frame-size-dependent, rather than an outright dead link? I'd expect either a clean link or no link, not this.
- Is there anything at the platform level worth trying that I haven't (link speed forcing, an interface reset that goes deeper than the button), or is this settled as hardware?
- If a staff member wants MAC addresses, order number, or engineering logs, I'm glad to provide them by DM, and I can enable remote support access.
The hub is a few months past the 90-day window, but given the nature of the defect I'd be grateful if Hubitat would consider a replacement. In any case, if this frame-size failure mode is of interest to Hubitat, I'm happy to help characterize it further.
The MTU-576 trick is the part I'd flag for anyone else hitting mysterious "connect timed out" errors: if small packets work and pages hang, test with -l 1472 -f before you spend a week suspecting your network config.