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 54.192.146.150 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms pfsense.localdomain [192.168.1.1]
2 12 ms 11 ms 10 ms 68.146.192.1
3 11 ms 15 ms 10 ms rc3no-tge0-11-0-32-1.cg.shawcable.net [64.59.132.69]
4 26 ms 33 ms 30 ms rc2wt-be100.wa.shawcable.net [66.163.75.233]
5 46 ms 48 ms 49 ms rc1wt-be60.wa.shawcable.net [66.163.75.89]
6 47 ms 57 ms 50 ms rc3sj-be60.cl.shawcable.net [66.163.75.90]
7 46 ms 46 ms 46 ms equinix01-sfo5.amazon.com [206.223.116.177]
8 48 ms 46 ms 48 ms 52.93.70.206
9 51 ms 58 ms 48 ms 54.240.242.155
10 46 ms 46 ms 45 ms 205.251.229.67
11 48 ms 48 ms 58 ms 205.251.231.116
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 48 ms 47 ms 57 ms 54.192.146.150
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! 
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.
