Update Failed, Please Try Again on brand new hub

Just rolled back and updated to latest available… Sorry to get you too excited… Soon…

Also, a cool website to test your speed to all of Amazon services is this: Amazon Web Services Network Test | CloudHarmony

Takes awhile to run all the tests.

No VLANs or groups, but I am running CODELQ traffic shaper to manage bufferbloat.

Tracing route to over a maximum of 30 hops

1 <1 ms <1 ms <1 ms pfsense.localdomain []
2 12 ms 11 ms 10 ms
3 11 ms 15 ms 10 ms rc3no-tge0-11-0-32-1.cg.shawcable.net []
4 26 ms 33 ms 30 ms rc2wt-be100.wa.shawcable.net []
5 46 ms 48 ms 49 ms rc1wt-be60.wa.shawcable.net []
6 47 ms 57 ms 50 ms rc3sj-be60.cl.shawcable.net []
7 46 ms 46 ms 46 ms equinix01-sfo5.amazon.com []
8 48 ms 46 ms 48 ms
9 51 ms 58 ms 48 ms
10 46 ms 46 ms 45 ms
11 48 ms 48 ms 58 ms
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 48 ms 47 ms 57 ms

Trace complete.

Can you try and disable CODELQ shaper temporarily for the hub’s ip address and see if it will complete the download.

Speedtests would also fail so, curios the outcome of those.

The CODELQ shaper didn’t seem to affect those speedtests, or at least, there were no failures!

I removed the shaper and same result: update failed.

Try some simple things… Swap network cable and a different known good network port?

If you can bring up the port 8081 interface and ping it, its up and running and network card is working. So it has to be something between the hub and AWS that is interrupting the download.

Yup already swapped port and used a different cable than the one bundled in the package. I can ping the Hubitat, and can see that it is sending NTP (time sync) requests when monitoring the firewall. If I point the browser to :8081 it gives me an empty list of firmware updates and a Submit button.

So are you blocking NTP requests? The download will fail because time can’t be set automatically.

No, it isn’t blocking NTP from what I can see. Although the Hubitat seems to be sending lots of requests to different NTP servers (port 123 I assume). Weird.

If it can’t set the time, it will keep trying. My assumption is that the response from the NTP server is being dropped or blocked via pfsense.

Hmmm. PfSense can act as an NTP server - which I may have enabled. The documentation so far doesn’t mention it will block outgoing NTP requests. I will continue to dig.

The repeated attempts out 123 for NTP indicate something blocking the time set request. If time is off, the hub will not authenticate for the firmware download due to a cert error because times aren’t synced.

Depending on your NAT settings, firewall rules, services settings (dhcp and ntp) traffic shaping, and more can effect connections.

Keep in mind, changing anything in pfsense typically requires a full reboot for it to take effect or at least dropping all the states and reseting all existing connections, reloading the tables, etc. Rebooting is easier.

Ok. I noticed this in the description of the NTP Service:

" By default the NTP server will bind to and act as an NTP server on all available IP addresses. This may be restricted using the Interface(s) selection on Services > NTP ."

So I disabled the NTP service and rebooted pfsense.

It still fails, but seems to go further - it made it to 13%. Maybe the time sync has to settle?

Did you reboot after disabling the traffic shaper? Something is dropping the connection, most likely its that.

If it got to 13% then the time sync should have already occurred.

Any traffic queues set up? Those have packet dropping options as well.

No traffic queues defined. Even disabling the NTP service (ntpd) has no effect. Still fails. Traffic shapers removed. I rebooted pfsense and power cycled the hubitat.

At this point, my only suggestion left is to wait till a less congested time, like tomorrow morning and try. Since it is downloading all the way to 13% that indicates the hub is working and trying. Something external is dropping the connection.

I’m pretty much out of ideas beyond dmz’ing or trying another connection without pfsense and see if it downloads.

Ok, thanks for the suggestions. Maybe I can find an old (dumb) router somewhere…

Appreciate your willingness to keep trying.

Hmmmm…it seems some people have ISPs that actually block outgoing UDP coming from port 123. Looking at the pfsense state logs, the Hubitat is doing that. It is possible that my ISP is blocking that too, and in that case, I have a brick! :frowning:

Reference: Need to map source NTP (UDP port 123) traffic to another port

On second thought, that shouldn’t be possible with pfsense hmmm…

If that is the case you should be able to route all outbound requests for NTP to pfsense internal NTP server to respond.