Google Nest Wifi - Devices connect to wifi points that are far away and not the closest one -- REDUX

[stevecoh1]

In this closed topic : https://www.googlenestcommunity.com/t5/Nest-Wifi/Google-Nest-Wifi-Devices-connect-to-wifi-points-tha... "Diamond Product Expert" Michael P. says the following:

WiFi devices are responsible for deciding which access point (and which band – 2.4GHz, 5GHz, etc.) to connect to, and when to switch between them. In a system where multiple access points are advertising (like a Google/Nest WiFi mesh network), well-designed clients should do a full scan and selection procedure when they start up, collecting all of the advertised access points and comparing their signal qualities to pick the best one. Some devices do a better job of this than others.

But I would like to understand how Google Mesh Wifi "advertises" a secondary point.  I never see the secondary point appear on any list of possible networks to connect to, I only see the Network name of the router network.  I am using a device that may well NOT be "well-designed", but I need to use it.  It's a Raspberry Pi device to which my outdoor telescope is connected. Even though the point is 30 feet away and within eyesight of the Pi, In all honesty, it seems a bit lame for Google to disclaim any responsibility for "poorly defined" WiFi interfaces.  How convenient (for Google).

To make a Mesh network work, users need a way to connect a device to the desired closest point.  If this can't be made to  work, I'm going to have to get something else.

[MichaelP · Accepted solution]

@MplsCustomer is correct - devices decide which access point and band to connect to, and when to switch between them. I can provide a little more detail on how some of this stuff works if you're interested, though. The network "name" is technically the "service set identifier", or SSID. It is humanly-readable, and what you see when browsing for available networks. But, each access point that provides connectivity to that network has a "base service set identifier", or BSSID, which is a 48-bit number that looks like a MAC address. In fact, each access point has a unique BSSID for each band that it supports (so, it would have one BSSID for 2.4GHz, and one BSSID for 5GHz, etc.). So, when you have multiple access points and they each support multiple bands, they are all "advertising" (beaconing) the same SSID (human-readable network name). In short, you won't see each one separately.

With that as background, a well-designed WiFi client device should be prepared to operate in an environment like this, and that includes listening for multiple beacons on each channel in each band it supports, measuring the signal quality of each beacon, and using that to decide which BSSID to connect to. For typical fixed devices, this is enough. For mobile devices, they may need to do that periodically and decide whether to switch (hand off). However, there are far more complex issues involved there, and this is already getting long (and you're asking about a Raspberry Pi, which is fixed anyway).

So, what does a "poorly designed" client device do? Well, to simplify the implementation, they start listening on a channel and the first beacon they hear, just connect to it. In an old-fashioned network with a single access point, that worked fine. But, in modern networks (not just Google's, but any network that includes multiple access points), this approach doesn't work well, since they end up connecting to a random access point instead of the "best" one. [Note: the phrase "poorly designed" is my own, not Google's – I don't work for them, but I am a computer engineer with 3+ decades in wireless and wireless-adjacent engineering].

But, what of your Raspberry Pi? It's not poorly designed – it should be doing a proper scan and selection on startup. So, does it connect to the nearest access point when it is restarted? Or does it connect to a more distant point when the network is restarted?

The reason for the question is, when the network is restarted, the clients are all sitting there scanning for beacons, waiting for the network to become available. But, the primary unit in the network comes up first, and starts sending beacons before the secondary/point units come up and start sending their own beacons. This can easily lead to client devices connecting to the distant primary, and then just staying there (because they are fixed devices that don't attempt to hand off, and don't support 802.11k + 802.11v, which are the standards Google WiFi and many other multi-AP networks use to help client devices make better hand-off decisions).

So, I would try restarting the Raspberry Pi after restarting your network, and if it connects to the closer access point, you'll know you just have to do that every time either the whole network is restarted or the closest access point gets restarted. I use battery backup systems for all of my access points to help survive brief power outages, and I know it helps reduce similar issues.

Whew. That was a lot, and as I mentioned above, there's a lot more. These systems are pretty complex, and I'm sometimes surprised at how well they actually do work.

[MplsCustomer]

@stevecoh1 

I'm just an amateur user of Wi-Fi networks, but have used them for a couple of decades now.

My understanding is that what @MichaelP  described in the post you mentioned is simply how Wi-Fi networks work. Wi-Fi devices--including your Raspberry Pi device--decide on their own which access point and which band they connect to. When I walk around our home with my iPhone or iPad, the iPhone or iPad decides which access point--and which band--to connect to.

[MichaelP · Accepted solution]

@MplsCustomer is correct - devices decide which access point and band to connect to, and when to switch between them. I can provide a little more detail on how some of this stuff works if you're interested, though. The network "name" is technically the "service set identifier", or SSID. It is humanly-readable, and what you see when browsing for available networks. But, each access point that provides connectivity to that network has a "base service set identifier", or BSSID, which is a 48-bit number that looks like a MAC address. In fact, each access point has a unique BSSID for each band that it supports (so, it would have one BSSID for 2.4GHz, and one BSSID for 5GHz, etc.). So, when you have multiple access points and they each support multiple bands, they are all "advertising" (beaconing) the same SSID (human-readable network name). In short, you won't see each one separately.

With that as background, a well-designed WiFi client device should be prepared to operate in an environment like this, and that includes listening for multiple beacons on each channel in each band it supports, measuring the signal quality of each beacon, and using that to decide which BSSID to connect to. For typical fixed devices, this is enough. For mobile devices, they may need to do that periodically and decide whether to switch (hand off). However, there are far more complex issues involved there, and this is already getting long (and you're asking about a Raspberry Pi, which is fixed anyway).

So, what does a "poorly designed" client device do? Well, to simplify the implementation, they start listening on a channel and the first beacon they hear, just connect to it. In an old-fashioned network with a single access point, that worked fine. But, in modern networks (not just Google's, but any network that includes multiple access points), this approach doesn't work well, since they end up connecting to a random access point instead of the "best" one. [Note: the phrase "poorly designed" is my own, not Google's – I don't work for them, but I am a computer engineer with 3+ decades in wireless and wireless-adjacent engineering].

But, what of your Raspberry Pi? It's not poorly designed – it should be doing a proper scan and selection on startup. So, does it connect to the nearest access point when it is restarted? Or does it connect to a more distant point when the network is restarted?

The reason for the question is, when the network is restarted, the clients are all sitting there scanning for beacons, waiting for the network to become available. But, the primary unit in the network comes up first, and starts sending beacons before the secondary/point units come up and start sending their own beacons. This can easily lead to client devices connecting to the distant primary, and then just staying there (because they are fixed devices that don't attempt to hand off, and don't support 802.11k + 802.11v, which are the standards Google WiFi and many other multi-AP networks use to help client devices make better hand-off decisions).

So, I would try restarting the Raspberry Pi after restarting your network, and if it connects to the closer access point, you'll know you just have to do that every time either the whole network is restarted or the closest access point gets restarted. I use battery backup systems for all of my access points to help survive brief power outages, and I know it helps reduce similar issues.

Whew. That was a lot, and as I mentioned above, there's a lot more. These systems are pretty complex, and I'm sometimes surprised at how well they actually do work.

[MplsCustomer]

@MichaelP 

Thanks for the explanation.

[stevecoh1]

Well, thanks for that detail.  It DOES interest me and it explains many things,  But my Pi is almost ALWAYS restarted after the network so the eventuality of the Network being restarted after the Pi doesn't apply.

I have also heard that the Pi5, particularly with a covered case, does not have a particularly strong WiFi receiver, worse than the Pi4.  I don't know if that's actually true.

But since we've eliminated the possibility of the Pi running when the network is restarted, I am wondering if I would be better served by placing some kind of WiFi extender, with a different SSID, in the spot where my Google Nest Point now sits.  Is that a workable configuration?  Is there something I should look for in choosing such a device?

[MichaelP · Accepted solution]

I have a number of Pi units of various vintage around here, but the most recent is a Pi 4. I do tend to use Ethernet to connect them, but I had an old model 3 connected via WiFi for awhile, and never really had much trouble with it. On the other hand, it was indoors and one room away from the nearest access point. I do think their antennas are pretty simple, so it would not surprise me at all if they weren't super powerful. Have you confirmed in the Google Home app that the RPi is, in fact, not connecting to the nearby access point after a power up (or WiFi disable/enable cycle)?

Have you run a mesh test recently? I want to make sure that nearby access point is also close enough to the primary to get a "great" rating for itself.

It looks like recent RPi models support both 5GHz and 2.4GHz bands – can you tell which band yours is connecting to?

The idea of a WiFi extender is an interesting one. I generally don't care for them, but in this case, it might be worth a try – just keep the packaging and receipt in case you aren't happy with the result and want to return it.

However, since this is a Raspberry Pi with, presumably, an installation of a typical Linux on it, you do have more control. You may be able to force it to only connect to the access point by adding the BSSID to the wpa_supplicant.conf file. Getting this to work is a little tricky, since the PSK has to be generated first. I haven't tested this myself, but if you feel comfortable tinkering, it might be worth a try – here's a help article with a few more details: https://unix.stackexchange.com/questions/741486/force-connect-wifi-to-a-specific-bssid 

[stevecoh1]

Thank you.

>> Have you confirmed in the Google Home app that the RPi is, in fact, not connecting to the nearby access point after a power up (or WiFi disable/enable cycle)?

yes

>> Have you run a mesh test recently? I want to make sure that nearby access point is also close enough to the primary to get a "great" rating for itself.

yes, the connection to the point shows as “great”

>> Thanks. I will definitely try this.

[stevecoh1]

I meant to write this;

>>However, since this is a Raspberry Pi with, presumably, an installation of a typical Linux on it, you do have more control. You may be able to force it to only connect to the access point by adding the BSSID to the wpa_supplicant.conf file. Getting this to work is a little tricky, since the PSK has to be generated first. I haven't tested this myself, but if you feel comfortable tinkering, it might be worth a try – here's a help article with a few more details: https://unix.stackexchange.com/questions/741486/force-connect-wifi-to-a-specific-bssid 

thanks, I will definitely try this -(editing the wpa_supplicant.conf file.

[stevecoh1]

I have tried messing with this and wound up making my pi inaccessible via WiFi.  I had to flash another micro-SD card to get the system back up and running.  Don't know what I did wrong, but I guess there is a reason this solution is not recommended more.  I am looking at getting some powerline connectors so that my network would have a wired outlet out to the window, at which a wiFi would be set up but I have no idea how that would play with the rest of my Nest network, which, aside from this, is working well.

[MichaelP]

Sorry to hear you ran into trouble with the RPi. You can always grab it and connect it via Ethernet inside to get it back without reflashing it from scratch. It's definitely low level stuff, and it could go wrong while you're working your way through the details. Powerline adapters are... ok. Not great, but they can be ok. Some can run spanning tree protocol, which can make life a lot more complicated. Keep the packaging and receipt for that. Honestly, though, if you're going to install powerline adapters, just put one out there and connect the RPi to it via Ethernet directly instead of using WiFi at all.

[stevecoh1]

WiFi connection to the pi is a requirement, unfortunately. I can’t have cables going from the inside to the outside.

one possibility is a powerline connection from the modem to the router, moved to near the window. But I don’t know if powerline nodes have to be on the same connection circuit breaker subsystem or not. I’ve heard two different stories on that. And I don’t know how much degradation there is through the power line.

[MichaelP]

Powerline adapters will talk across the two phases, but it will reduce the performance. Generally, powerline is slower than Ethernet. Whether it's also slower than WiFi depends on a lot of things.

[stevecoh1]

What does "phases" mean in this context?  Does it mean from one circuit-breaker to another?

[MichaelP]

Regarding phases in an electrical system, this applies to only 110V systems, and is, unfortunately, a little technical, but still interesting. Imagine you only needed 110V power. You'd have a "hot" wire and a "neutral" wire coming in to your house, with alternating current (AC) power oscillating at a frequency of 60Hz. Think of the neutral wire as being at zero volts, and the "hot" wire oscillating between zero and 110V (well, actually, it's more than that, but I don't want to get too deep into that).

So, now, what if you also want to power a few appliances that run on 220V? Things like your air conditioner or an electric dryer?

To do that, instead of sending only one "hot" wire, we have two – both are at 110V compared to neutral, but one of them is oscillating between zero and plus 110V, and the other is oscillating between zero and negative 110V. This is the other "phase".

Once you have both of these phases, if you measure the voltage across the two directly (not compared to neutral), it's 220V. Now you can power half your 110V circuits from one phase, half from the other, and your 220V circuits using both phases.

Inside your breaker box, the two phases are available in a sort of zig-zag pattern, so breakers on one side of the box are on both phases, every other breaker, and the same pattern on the other side of the box. The reason for this is, by putting a double-wide breaker that spans two slots, you are connecting to both phases. That's why 220V circuits use double-wide breakers.

Ok, with all of that as context, how do powerline networking devices work? They basically transmit a high frequency signal on the hot and neutral wires. But, since there are phases, there are two hot wires, and they aren't really connected to each other. So, two powerline devices on the same circuit, will be able to talk to each other pretty well, and even two powerline devices on two different circuits, but on the same phase, will also talk to each other pretty well, But, two powerline devices on two different circuits that are on different phases will only share the neutral wire. They can still talk, but more slowly.

Whew – that turned out long (and I glossed over a lot of details). But, I hope it answers your question.

[stevecoh1]

Uhhh, never mind.  Thank you a million times @MichaelP for pointing me at that Stack Exchange Link.  It was simplicity itself once I figured out how to apply the first answer's lesson.  Here is my completion of what the original answerer began.  This solution is available to anyone else with a little Linux skills in my situation

[MichaelP]

So glad to hear you got the instructions from Stack Exchange to work!

[stevecoh1]

And this is the URL to my answer which I meant to include but didn't:

https://unix.stackexchange.com/a/774969/106105 

I don't know how common my problem is.  As you said the device ought to know how to find the best access point, but as I found, it's not always the case. For anyone in this maddening situation, this is a solution.  It depends on Linux, but I imagine there must be a set of commands in Windows/OSX, etc. which produce the encrypted password, which should then be enough to set things right.

You would not believe how many hardware solutions I investigated before this worked.