Steering Clients via Probe-Exchange

I made a dumb question, if it is possible to suppress beacon frames.

Actually, I wanted to have control which stations sees which AP. I had some trouble with that approach by stations which are doing passive scanning and so on...

Now I wonder if steering works, if your standard config hides the SSID, but you have the ability so send probe response messages containing the SSID.
Did somebody tried to do such stuff already? Otherwise I think I will give it a try and modify the ubus hostapd calls.

It will at least see the AP once, I assume you'd then want a procedure if it were able to see both SSIDs. You'll have to program that behavior - as you noted. Be advised, all client OSes don't gracefully "steer."

As in programming, not likely. See:

1 Like

First I want to suppress everything. Then, there should be a fine granular selection which probe response message I want to send back to the client. And only one AP should answer.

I already tried this:

And I tried to suppress all probe response messages via the ubus callbacks. Still clients were able to connect... Maybe the ubus callback is to slow. Or they do passive scans...

I know. :confused:

I think I will add this to the ubus interface of the hostapd

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/hostapd/src/src/ap/ubus.c;h=3375ac49f76f7eec07640100504e01bf49ddfa56;hb=HEAD#l1037

Let's see. :slight_smile:

I found one paper exactly doing what I describe.
It is called DenseAP.

First, the passive DAPs (i.e., those that do not have clients associated with them) in the network do not send out any beacons. The active DAPs do send out beacons but with a hidden SSID. Second, each DAP maintains a local access control list (ACL) of client MAC addresses. On receiving a probe request from a client, the DAP replies with a probe response message only if the client’s MAC address is in its ACL.
Source: Murty, Rohan, et al. "Designing High Performance Enterprise Wi-Fi Networks." NSDI . Vol. 8. 2008.

Have you been working on 802.11v and 802.11k?
I am now looking into how to steer clients with 802.11v in hostapd

hostapd is already giving us the ability to send appropriate messages.
Look at my GSOC Point 5.

I did not have the time to try hostapd with 802.11v.

Most modern clients now probe with random MAC addresses to enhance user privacy.

Yeah but there are still tons of legacy clients. :stuck_out_tongue:
Of course, this is a huge problem. I have no idea how you could cope with that.

Maybe taxonomy could help?

What taxonomy?

Okay, the Cisco people released a paper called ClientMarshal: Regaining Control from Wireless Clients for Better Experience in Enterprise WLANs.
They use CSA and a third radio to scan for clients. Maybes this is the way to go... But you don't have a third radio on "off-the-shelf-hardware"...

Hostapd has taxonomy support, its like a device fingerprint.
You can even get it throught ubus

Do you think this would also work for a passive discovery? I am trying to find a solution where the AP can match his SSID with his hashed SSID which is send in a probe request. Matching hashed SSID with its own on raspberryPi and openWrt