thanks for the very interesting research topic
I am not quite sure whether the hostapd ubus interface would be sufficient to achieve the goal, or if this behaviour needs to be implemented in mac80211 and/or even the particular wireless driver.
In case of Raspberry Pi, you are probably dealing with a Cypress SDIO wifi chipset, which is running its own (proprietary closed-source) firmware. I would expect things like dealing with Probe Requests etc. could be offloaded to run in hardware, i.e. would happen within that firmware, but there might also be ways around that.
Regarding wireless chipsets, one of the best supported drivers in Linux is probably
ath9k for the Qualcomm Atheros 802.11n chips, which do not have any code run on the hardware itself, but it's basically just a huge set of radio registers, giving the kernel driver full control over the hardware.
So, regardless of the system components to be modified for the implementation (hostapd/mac80211/driver!?), it might be a good idea to acquire some ath9k-based router for testing (you probably also find developers around here knowing that driver more easily), which would basically include all hardware from the
ath79 OpenWrt target (preferably those without .ac on 5GHz, since ath10k chips run closed-source firmware again).
As far as I understand, you only need this behaviour for detecting Probe Requests (considering most of them will be unsuccessful while the user is out of the network's reach), and upon a match, the Probe Response would be followed by a regular Association procedure (which would then disclose the SSID, but at least this does not happen in public situations far away from the actual network)?
I think this might be a good question to ask on the
openwrt-devel mailing list (maybe even linux-wireless, if there is no solution using hostapd), but you should try to craft your question carefully to attract wireless developer's interest (e.g. include a concise summary of the solution proposed in your paper, like in your last post)
By the way, what does the station side look like, did you have any success on implementing the hashed probing on a real wireless client yet?
I have never truly understood the need for the dualism of Beacons vs. Probe Responses in 802.11, like why they could not agree on the specification of a single frame type that would serve both needs.
Considering that other technologies like e.g. DECT have been implementing power save mechanisms for decades now, even sparse wifi networks with only a few clients occasionally connected will pollute the precious channel capacity with a few hundred megabytes of beacons per day, transmitted at the lowest MCS index.
For sparse networks, I've been dreaming of some kind of "probe to beacon" mode, which would monitor the channel for incoming (probably non-wildcard only) Probe Requests, and only startup the "full" AP after a match, and disable it a few minutes after the last client disconnected. This could probably even be done in userspace, by setting the card to monitor mode and filtering frames with airpcap while the AP is off. This would not send a valid Probe Response frame initially, but the client should eventually find the network after some time. Of course this would be cooler to be implemented right in the driver, but unfortunately I don't have the skill and insight to the wireless drivers to implement this.
For your scenario, passive scanning would probably not work since you need this behaviour even while other clients are already connected; very few drivers (like ath9k) should however support parallel monitor and AP mode as well as packet injection, but you would still have to craft your own Probe Responses, which would not be a perfectly clean solution either (but then again, why wouldn't the client find the network from the beacon eventually, even without a proper Probe Response? assuming a non-hidden SSID)