Possible issue with Hub FW update... loss of connectivity with WiFi

My hub was just upgraded to FW HB_0_37, and now it appears that I cannot connect to my WiFi any longer. I can connect to the hub over BLE with my iPhone (iOS 11.3 beta 4 public). Whenever I try to connect to my WiFi, I get "cannot connect to WiFi, Error Code:67 (or sometimes error 1024)…


have you tried to reboot your hub manually ? (pull the usb out, wait a few seconds and re connect)

Many of us have been upped to V37 these days and we didn’t have an issue …

Also this error shows when you try to add it again via de app I guess ?

Hi, Tony. It’s good to see you post here. My only suggestion is to double check the password. You can also try powering off the Hub and router and then try to connect.

Which version on the WeatherFlow application are you using?

Hopefully @dsj and @WFstaff will see this and comment.


1 Like

Thanks Eric and Gary for the replies…

I did indeed follow the following:

Re-checked my WiFi password…
Unplugged my Hub, waited the requisite 10 seconds, plugged back in… no joy
Rebooted my WiFi router… waited then tried again… no joy.
Depressed the recessed reset button on the Hub to forget all former WiFi and tried again, no joy…

My app version is v1.80(120) updated 2 weeks ago…
My iPhone 8 Plus is running iOS 11.3 public beta 4

For what it’s worth, I borrowed my wife’s iPad and installed the app on that, it’s running iOS 10.3.3. Still, same problem.

Hi Tony, thanks for writing that ticket to us and for joining in on the discussion here. This was reported by another user today but his firmware hadn’t updated to v37 just yet - or at least we didn’t get the updated firmware status.

It seems you tried the basic troubleshooting procedure already. Please standby for more info. Thanks!


Tony, I don’t know what else try.

Maybe sacrifice a chicken. Wave your hands in the air while jumping with one leg. :slight_smile:


1 Like

I don’t think it is related to your iOS as I just jumped to ß5 and re added my hub to wifi (using the 1.90 app (beta also)

My hub was upped today normally to V37 by WF and it rebooted normally (wasn’t even home when David did the push update)
tnicholas will handle from here as Gary and me can’t really do much more

1 Like

Thanks Tim… I eagerly await your findings…

All the best


Gary, I ALWAYS enjoy your comments… are you sure you’re not from New Jersey like me? :slight_smile:


I am not. I was stationed at Ft Monmouth and I really enjoyed being there.

1 Like

Hi Tony. That error means your hub didn’t receive a DHCP address from the WiFi router for some reason. We’re not sure why that happens, but it’s usually resolved by simply trying again. Please try again a few times and let us know if you’re able to restore the connection.

1 Like

thinking in that same line

Tony, is there any filtering on your router/modem ? Like only allow certain mac addresses ?
Did you use routing tables ?

@dsj can a mac address change for the hub after an upgrade by any chance or are they hardcoded ?

I have seen a number of situations like this where the number of IP addresses allocated to DHCP is insufficient for the number of devices requesting addresses. I have even seen WiFi routers that come brand new with only 5 IP addresses allocated to DHCP. I would check the router config to see if the DHCP address space is configured properly for Tony’s situation. Could add addresses, shorten lease times or assign static IP’s to some of the devices on the network.



MAC addresses are most often assigned by the manufacturer of a network interface controller (NIC) and are stored in its hardware, such as the card’s read-only memory or some other firmware mechanism. If assigned by the manufacturer, a MAC address usually encodes the manufacturer’s registered identification number and may be referred to as the burned-in address (BIA). It may also be known as an Ethernet hardware address (EHA), hardware address or physical address (not to be confused with a memory physical address).

1 Like

that is indeed the ‘normal’ situation but I have several devices I can manually change the mac addresses, even my router allows to change it for all ports and even the wifi channels …

And since this is a custom made device by WF, maybe they decided to have access to the mac addressing to make sure each hub is unique …

Just trying to wild guess what could go wrong. Guess @dan.gealt is trying to think a bit in the same manner.
Since Tony rebooted his router, it can’t be a hanging lease …

Hope it’ll solve in the end.

I understand. My router is configured to dish out DHCP requests in the range of x.x.x.20-200

I like to have my devices get an initial IP address, then edit the IP to fit nicely within a certain block inside those values, reserving that address with the DHCP server to ensure it always gets the same one.

I’ll remove the reservation and try again.

However, this would be a good place to request a new feature… static IP addressing. Many of us with IoT devices like to lock them in place…


That is the reason to use the address assigned. The manufacturer and the governing body insure that each address is unique.

1 Like

No, it’s burnt into the hardware.

Yes, that’s on our roadmap! Let me know if removing the address reservation helps.

David, I took two different steps… 1st, I turned off, then on the DHCP server in the router, no change in trying to connect.

I also enabled a Guest Wifi on my 2.4GHz band with a different SSID and password, again, no help there either.

Ugh, I’m frustrated…

Is there any way to re-flash my hub locally? Since I can’t get on a network, I can’t check or re-check for new firmware…

Hi Tony,

Not wanting to ask trivial questions here, but . . . have you tried to connect any other new device or computer to the network to see if the other device obtains an IP address from DHCP? If a new device gets an IP address then it would point to the HUB having a network connectivity problem (could be hardware or firmware). This would be a lovely situation to have a Fluke Linkrunner AT or similar tester available to diagnose the problem.

Regarding MAC addresses, @GaryFunk and @eric bring up some good points. In my experience, MAC addresses can certainly be changed from the burned-in-address, but there would have to be a compelling reason to build that hardware/firmware capability in to a piece of hardware. Most commonly, I have seen virtual network interfaces (vNIC) in high-availability systems (eg: VMWare clusters, etc) using configurable MAC addresses so that the Ethernet packets are always transported to the virtual NIC no matter which physical machine is currently utilizing that virtual NIC. It would seem unlikely to me that the WF HUB has any need for that capability (and, of course, I could be wrong about that assumption) so I would expect that the MAC address is not changing in the HUB.

Good luck with your troubleshooting!