Hub 4.0 reboot bug - resets custom 2.4ghz SSID/security values when channel optimisation is enabled
24-03-202114:15 - edited 24-03-202114:27
I have discovered a bug with the Hub 4.0. Mine is running the most 'up to date' firmware as of 24/03/21 (01.02.065.21.EURO.PC20).
The bug resets any custom 2.4ghz SSID / Password back to VM defaults when the device is rebooted for any reason.
I have reported this to CS and apparently it is being passed to the team who works on the Hub 4.0 firmware to fix in a future release, however I wanted to post something here in case it helps other users who might run into this issue.
Things to note / prerequisites: - This will only affect people who use their own SSID name and password rather than the VM default. It will also occur regardless if you run a single SSID or if you have them split. If you use the default VM SSID and Password on the bottom of the hub, this bug will not affect you. - In addition to the above, this bug will only occur if you have "Advanced Settings > Wireless > Wireless Signal > Smart WiFi 'Channel Optimisation'" enabled (enabled is the default).
So what happens?
Well, if like me, you have a custom SSID and password set on your Hub 4.0 and at any point you reboot your router (or VM reboots it for you to update itself or otherwise - which was the case for me....random 6am reboot), you will find that your 2.4ghz SSID and password settings are reset to their default values (so the 2.4ghz SSID will change back to VMxxxxxxxx, and the password will be set to what is on the bottom of the hub).
5ghz is unaffected and should continue to work.
As a result of 2.4ghz values being reset, it means anything you previously had running on 2.4ghz will no longer be able to connect.
If you go to Advanced Settings > Wireless > Security, you can correct the settings, save the changes, and the devices should reconnect.
However, if you reboot the router again for any reason, these settings are reset once again. For reference, these settings are the ones which are reset:
This can be replicated every time, with 100% reliability.
Factory resetting the router does nothing to fix this, in case anyone is curious.
So what's the fix?
Well, fortunately the workaround is quite easy.
Go to "Advanced Settings > Wireless > Wireless Signal" and DISABLE Smart WiFi 'Channel Optimisation'.
Save the changes.
Now, if you reboot your Hub 4.0, the custom SSID and password you had set for the 2.4ghz network is retained.
TLDR - Leave this option DISABLED if you use an SSID and password different to the defaults. If you re-enable channel optimisation, expect your custom 2.4ghz settings to reset to default on the next reboot, dropping your 2.4ghz devices off the network until corrected.
Virgin Media need to get this fixed with a future firmware upgrade. This is obviously an implementation issue with the 'Smart Wifi' channel optimisation option. I spent a while testing this and over an hour on the phone to get this logged with CS.
Anyway, I hope this helps some other users who may run into this issue.
@Forum team, although CS should have passed this on already, can you ensure this thread is passed to the firmware developers for the Hub 4.0, just in case they need more detailed information.
Re: Hub 4.0 reboot bug - resets custom 2.4ghz SSID/security values when channel optimisation is enabled
29-03-202111:21 - edited 29-03-202111:22
Thanks for the additional info! I'm only running the Hub 4.0 with a single SSID - unfortunately i'm not using any of the intelligent WiFi pods so cannot test.
However it makes sense that those might break if they rely on the WiFi Optimisation setting being turned on. So thanks for adding that to the thread 👍
If that is indeed the case, for people with the additional pods using their own SSID/password - as a workaround they would either need to revert their custom SSID and password to VM defaults (which then means updating all client devices), or just live with manually correcting the 2.4ghz values when the hub is rebooted.
Hopefully it'll be fixed with a future firmware release. I imagine even if this only affects a relatively small amount of users, it will still be a fair few and there could be a lot of troubleshooting that ends up going down the wrong path (eg. assumption of faulty hardware, or client side/user issue).