Managed Wifi Network using Raspberry Pi, Help?

[pomtom44]

Hey all
I think this is the right place to put this thread, but feel free to move if iv put it in the wrong place.

If you know of Ubiquity's managed wifi, and zero handoff, allowing for roaming between access points without loosing connection.
Alot of other WiFi controllers have similar ideas, cisco etc.
The common factor is all the access points are controlled by a central controller which manages all the AP's

Now my question
I know this isnt the most optimal way of doing things, so please leave out the comments of "Dont use R-Pi's" or "Why not buy one of these..."
Im doing this as a learning experiment and for a bit of fun.

I know how to turn a raspberry pi into an access point, using a usb wifi and onboard ethernet, and how to set it so DHCP is managed by the network and not the R-PI
But what im looking into now is a way to set a few pi's up and use them as a managed network with a central control pi managing the roaming, ssid's passwords etc.

Iv tried to google it, but everything I find is talking about how to setup the Rpi as a wifi ap, or setting it up as a wifi repeater using two usb wifi adaptors. Which is not what im wanting.
Any input or direction would be great.
OR if you have no idea what im going on about, let me know and I can try re-explain myself.

Thanks in advance

[brwainer]

• Setting up a R-Pi as an AP - see here: https://elinux.org/RPI-Wireless-Hotspot - except don't do the udhcpd or NAT steps, just the hostapd and turning off the normal wireless connection via the wpa-supplicant. Since you aren't going to be doing NAT, you'll probably have to bridge the ethernet and wireless interfaces together, just google set up a bridge on linux
• Making this AP "centrally managed" with "roaming" and "config management" - this is going to be basically impossible. I'm not aware of any hardware-agnostic AP management system, so you'd have to write it all yourseld

[pomtom44]

10 hours ago, brwainer said:

• Setting up a R-Pi as an AP - see here: https://elinux.org/RPI-Wireless-Hotspot - except don't do the udhcpd or NAT steps, just the hostapd and turning off the normal wireless connection via the wpa-supplicant. Since you aren't going to be doing NAT, you'll probably have to bridge the ethernet and wireless interfaces together, just google set up a bridge on linux
• Making this AP "centrally managed" with "roaming" and "config management" - this is going to be basically impossible. I'm not aware of any hardware-agnostic AP management system, so you'd have to write it all yourseld

Yeah setting up as an AP is fine, I have done it lots and can almost do it blindfolded now, haha.

I understand that different "roaming" techniques are handled differently per hardware, as there is no real standard for it.
Cisco does it slightly different to Unifi and so on.
I dont mind buying specific wifi adapters for the Pi's if it works with some sort of roaming software.
Or if theres a guide to help me get started on writing my own, I wouldn't mind giving that a go.
I just dont know where to start or how to start.

[brwainer]

1 hour ago, pomtom44 said:

Yeah setting up as an AP is fine, I have done it lots and can almost do it blindfolded now, haha.

I understand that different "roaming" techniques are handled differently per hardware, as there is no real standard for it.
Cisco does it slightly different to Unifi and so on.
I dont mind buying specific wifi adapters for the Pi's if it works with some sort of roaming software.
Or if theres a guide to help me get started on writing my own, I wouldn't mind giving that a go.
I just dont know where to start or how to start.

I’m not aware of anyone that makes wifi adaptors that support any type of roaming with a controller. Really what you want to look for is 802.11r fast roaming, because that is a standard and doesn’t require a controller or any special software. Also important and related to roaming are 802.11k, 802.11v, which are related in some way to the APs telling the client what to do instead of just accepting what the client wants, and 802.11w which adds security to the “management frames” that are the actual data used to connect clients to APs.

 

I found these links for you:

 

general hostapd configuration
https://www.w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
how to enable wifi roaming
https://blog.fem.tu-ilmenau.de/archives/1002-HowTo-enable-WiFi-roaming-with-hostapd-and-VLANs.html
802.11r hostapd example
ftp://ftp.raspberry-pi-geek.com/pub/listings/rasp-pi-geek.com/04/AccessPoint/Listing04.txt

[Just.Oblivious]

Keep in mind that roaming decisions are ultimately made by the client devices, not by the infrastructure.

 

802.11r speeds up the key renegotiation process during a hand off (mostly relevant for WPA2-enterprise networks with slower 802.1X authentication).

802.11k and 802.11v are ways to inform the client about the network infrastructure and nearby access points.

 

None of these standards force the client to do anything, they're just there to help the client make better roaming decisions.

 

Sure, the infrastructure can "help" the client roam by using one of many (often vendor specific) "hacks"; ranging from a simple kick when the signal strength gets too low, to a fully virtualized wifi system that 'moves' with the client.

 

Ubiquiti's Zero-Handoff (a feature that never came out of beta and has long been deprecated) is basically that: a poorly executed hack that presents all access points as one single system to the client. It never scaled very well (as all AP's had to be on the same channel), and the roaming performance was spotty to say the least.

 

The least-worst way to "force" roaming in a home enviroment is by implementing a rule that kicks a client ones its signal strength drops below a certain threshold. Kicking the client forces it to do another scan and (hopefully) select a different AP.

 

There are a few major issues with the signal strength (RSSI) kicking method:

• Your coverage and AP overlap have to be damn near perfect for it to work reliably.
• Signal strength measurements done by the AP are one sided and often very inaccurate.
• It's far from seamless: it can take a good 100~500 ms before a client reconnects, it it tries to reconnect at all
• Random drops may occur near the edge of the coverage area.

 

Moral of the story: leave the roaming up to the clients, unless you're willing to invest in a highly regarded fully managed vendor backed wireless solution (the complete opposite of Ubiquiti's Zero-Handoff).

 

You can still help the clients out by implementing 802.11k, 802.11r and 802.11v (if it's possible with the hardware you have). Just don't expect stellar results from a homebrew access point.

[pomtom44]

3 hours ago, Just.Oblivious said:

Keep in mind that roaming decisions are ultimately made by the client devices, not by the infrastructure.

 

802.11r speeds up the key renegotiation process during a hand off (mostly relevant for WPA2-enterprise networks with slower 802.1X authentication).

802.11k and 802.11v are ways to inform the client about the network infrastructure and nearby access points.

 

None of these standards force the client to do anything, they're just there to help the client make better roaming decisions.

 

Sure, the infrastructure can "help" the client roam by using one of many (often vendor specific) "hacks"; ranging from a simple kick when the signal strength gets too low, to a fully virtualized wifi system that 'moves' with the client.

 

Ubiquiti's Zero-Handoff (a feature that never came out of beta and has long been deprecated) is basically that: a poorly executed hack that presents all access points as one single system to the client. It never scaled very well (as all AP's had to be on the same channel), and the roaming performance was spotty to say the least.

 

The least-worst way to "force" roaming in a home enviroment is by implementing a rule that kicks a client ones its signal strength drops below a certain threshold. Kicking the client forces it to do another scan and (hopefully) select a different AP.

 

There are a few major issues with the signal strength (RSSI) kicking method:

• Your coverage and AP overlap have to be damn near perfect for it to work reliably.
• Signal strength measurements done by the AP are one sided and often very inaccurate.
• It's far from seamless: it can take a good 100~500 ms before a client reconnects, it it tries to reconnect at all
• Random drops may occur near the edge of the coverage area.

 

Moral of the story: leave the roaming up to the clients, unless you're willing to invest in a highly regarded fully managed vendor backed wireless solution (the complete opposite of Ubiquiti's Zero-Handoff).

 

You can still help the clients out by implementing 802.11k, 802.11r and 802.11v (if it's possible with the hardware you have). Just don't expect stellar results from a homebrew access point.

Ah okay
Im new to WiFi management, and as such, assumed it was the controller which managed it all, wasnt aware it was the client.
I knew Zero handoff was a new concept and it died in beta, but didnt know why or the technical details.

So if I understand correctly, the best way would be to setup mulitple AP's on the same SSID, but different channels, and let the client decide which signal is best? and help it with K V and R Standards for 802.11

I guess what I was wanting to setup was as you said, "fully virtualized wifi system"
As id like to manage the multiple wifi's from a single point, One central password, view active devices no matter which AP they are connected to, etc.
Like you can do in an enterprise setting.

If its possible at all?