Smart Hub 7 Pro 5 GHz failure reproduced on two hubs - channel/firmware issue?

[Mellman]

Hi all,

I am starting a separate thread for this because although the problem originally came to light while troubleshooting repeated YVM102/connectivity problems with our EE TV boxes, the testing we have done since then appears to have uncovered a wider Smart Hub 7 Pro 5 GHz issue.

We are on EE Full Fibre using an Openreach ONT and a Smart Hub 7 Pro. We also have an EE TV main box downstairs, an EE TV Mini upstairs and an EE WiFi extender.

The original symptoms were intermittent connectivity problems with the TV boxes and other devices. Eventually I noticed that our gaming laptop could still see the normal EE WiFi network but would sometimes be unable to connect to it over 5 GHz. If I changed the wireless adapter back to dual band it would immediately connect using 2.4 GHz.

After extensive troubleshooting with EE, including a factory reset of the original Smart Hub, Executive Complaints arranged for a replacement Smart Hub 7 Pro to be sent.

I deliberately installed the replacement in a very controlled way. The EE extender was left completely powered off and initially nothing else was connected to the replacement apart from the Openreach ONT. I connected my desktop directly to the new hub over WiFi.

The desktop uses an Intel WiFi 6E AX210 adapter. On initial setup it connected normally to 5 GHz with a strong signal and no packet loss. At one stage the replacement hub was using channel 36 and everything was working as expected. The gaming laptop, which uses a separate Intel AX200 adapter, also worked normally.

The replacement hub then remained apparently fine for around four days.

Unfortunately the same problem returned.

The gaming laptop lost its 5 GHz connection again. When its adapter was restricted to 5 GHz only, it could see the EE SSID but Windows reported "Unable to connect to this network". Returning the adapter to dual band allowed it to connect immediately over 2.4 GHz.

I then repeated the same test independently on the desktop. When I restricted the AX210 to 5 GHz only, it also could not connect.

At this point the EE WiFi extender was still completely powered off, so the extender or mesh roaming can be excluded from these tests.

Hub Manager showed the main 5 GHz radio as enabled and Smart Channel had selected channel 100.

I ran:

netsh wlan show networks mode=bssid

on the desktop. Initially the only BSSID being shown for our EE network was the 2.4 GHz BSSID. The Smart Hub's 5 GHz BSSID had disappeared completely from the scan even though Hub Manager continued to report 5 GHz as enabled on channel 100.

I then used the 5 GHz Smart Channel Rescan option in Hub Manager. It remained on channel 100 and did not resolve the problem.

Next I switched only the Smart Hub's 5 GHz radio off, saved the setting, waited around 30 seconds, switched it back on and saved again.

After doing that, the 5 GHz BSSID became visible again on channel 100 with a strong signal of around 80 percent.

However, neither the desktop nor the gaming laptop could actually connect to it.

This was particularly useful because it showed that simply making the 5 GHz radio broadcast again did not restore the ability of clients to associate/authenticate successfully.

I generated a Windows WLAN report on the desktop while the fault was live.

One failed connection attempt is particularly interesting. Windows recorded that wireless association with the Smart Hub's 5 GHz BSSID succeeded. WPA3-Personal security then started, but approximately five seconds later the security stage failed.

The reported reason was:

"Dynamic key exchange did not succeed within configured time"

Windows also logged:

"PSK mismatch suspected"

The WiFi password was definitely correct. The same SSID/profile/password continued to work on 2.4 GHz and had previously worked normally on 5 GHz on the same replacement hub.

The WLAN report also confirms that the Intel AX210 supports WPA3, SAE and H2E, so this is not simply an adapter which lacks WPA3 support.

As a further test, I enabled the Smart Hub's Compatible WiFi network on 5 GHz. This uses WPA2-Personal rather than WPA3.

Hub Manager showed Compatible WiFi 5 GHz as enabled on channel 100.

However, when I restricted the AX210 to 5 GHz only, the Compatible WiFi SSID disappeared from the available network list completely. The normal EE 5 GHz SSID remained visible but could not be joined.

That makes me less convinced that this is simply a WPA3 problem. It seems possible that the failed WPA3 key exchange is one symptom of a wider 5 GHz radio, virtual AP, Smart Channel or firmware state problem.

At this stage I performed a normal restart of the Smart Hub through Hub Manager. This was not a factory reset.

After the restart, Smart Channel selected channel 149 rather than channel 100.

The result was immediate.

The desktop automatically connected successfully to 5 GHz again on channel 149 using WPA3-Personal.

The gaming laptop also immediately regained proper 5 GHz connectivity. Windows shows it connected on channel 149 using WiFi 6/WPA3, with a current link speed of around 721 Mbps receive and 360 Mbps transmit.

The upstairs EE TV Mini box, which had also started having connectivity/interface problems again at approximately the same time as the 5 GHz problem returned, also began working normally again after the Smart Hub restart.

I am not claiming that this proves channel 100 itself is the cause because the restart changed two things at once. It reset the hub's internal state and also caused Smart Channel to move from channel 100 to channel 149.

However, the observed sequence on the replacement hub so far is:

5 GHz working normally while the hub was using channel 36.

5 GHz subsequently failing while Smart Channel was using channel 100.

Two completely independent computers unable to use 5 GHz.

EE extender completely excluded from the setup.

Smart Channel Rescan did not resolve the problem.

Cycling only the 5 GHz radio caused the BSSID to become visible again but did not restore client connectivity.

Windows WLAN diagnostics recorded a WPA3 dynamic key exchange timeout against the Smart Hub's 5 GHz BSSID.

The WPA2 Compatible WiFi test also failed to provide a usable 5 GHz alternative.

A full Smart Hub restart then moved 5 GHz to channel 149 and restored normal 5 GHz operation on both computers.

The EE TV Mini also returned to normal operation following the same restart.

What makes this especially concerning is that this is now the second Smart Hub 7 Pro on which we have experienced very similar 5 GHz association failures.

The replacement hub is running firmware:

r4.29.1-R-1930437-PROD-1

The previous Smart Hub was also running this firmware when we reproduced the earlier 5 GHz failure.

The desktop and gaming laptop use different adapters, Intel AX210 and AX200 respectively, and both are now behaving normally again following the hub restart. That makes a fault with one particular client considerably less likely.

The lack of manual 5 GHz channel selection on the Smart Hub also makes this very difficult to isolate further. Ideally I would like to be able to lock the hub to a known working non-DFS channel such as 36, 40, 44 or 48 for several days and see whether the fault ever returns, but as far as I can tell the Smart Hub 7 Pro does not allow this.

For now I am leaving the hub exactly as it is on channel 149 and monitoring it.

If the fault returns, I intend to capture the selected channel, BSSIDs, client behaviour and WLAN diagnostics again before restarting or changing anything.

I would be very interested to hear from anyone who has seen similar behaviour with the Smart Hub 7 Pro, particularly a situation where 5 GHz remains visible but clients suddenly cannot associate/authenticate until the hub is restarted.

I would also be grateful if someone from EE could advise whether these findings can be passed to the team responsible for Smart Hub 7 Pro wireless/firmware development. Having now reproduced similar behaviour on two separate hubs, with multiple independent clients and the extender excluded, I do not think another factory reset or replacement hub alone adequately explains what is happening.

[Mellman]

Thanks both, this is really useful.

The r5.16.1 information is particularly interesting. I've checked EE's firmware page and can see that SH40J is included in the August rollout, with improved WiFi and extender stability/performance listed in the release notes.

I'll check what version my replacement Hub is currently running. I won't factory reset or change anything for the moment, as I think it would be useful to let the firmware rollout happen naturally and see whether the behaviour changes.

If it updates from r4.29.1 to r5.16.1, that should give me a useful comparison because the 5 GHz fault has now been reproduced and documented several times on r4.29.1.

On MLO, I had wondered about that too, although the clients I've used for the controlled testing include an Intel AX210 and AX200, so they aren't WiFi 7 MLO clients. The Samsung phone and EE TV Mini have also shown correlated symptoms. Because of that I'm reluctant to start changing MLO-related settings unless EE specifically asks me to test them.

The DFS discussion is interesting. I agree that a DFS/Smart Channel event could potentially be involved in triggering the problem. The part I still find odd is that the Hub can work perfectly normally on 100(114) at 160 MHz, then later fail while still visibly broadcasting strongly on exactly that configuration, and after a full reboot can eventually return to 100(114) and work normally again.

EE Executive Complaints confirmed yesterday that the detailed report and WLAN evidence I sent have now been passed to the relevant technical team, so I'll also see what they come back with regarding the new firmware.

I've also made a bit of progress on the physical network today. It turns out one of the existing wall sockets is genuinely wired back to the router cupboard, so one of the EE TV boxes is now directly on Ethernet rather than powerline. I've moved the powerline connection to the upstairs Mini instead, so both TV boxes are now effectively wired. That at least reduces the practical impact of any further 5 GHz failure while the Hub issue is being investigated.