Ignore_broadcast_ssid an alluring parameter

What I want is not to hide the SSID, but just to ignore broadcast probe requests

I'm thinking that parameter is not well named in hostapd, and better named in openwrt

hide_ssid sets ignore_broadcast_ssid to 1 in hostapd... so there is a type 2 for that parameter but I think it still hides ssid...

I'm in a busy area, and got an esp8266 running a probe sniffer and can see, at times, absolute floods of probes... most of them broadcast probes, well about 10,000 cars a day pass within 10 metres of the access point, and already a crowded wifi area.

Now, I am a high traffic user, lots of nodes, grabbing lots of images and data and streams (swiss radio and their 192kbit/s streams eh) across wifi, so part of the problem to an extent is my devices so been working to minimise my impact.

So, I got the pi's to passive scan, but with hide_ssid, those devices cannot see their own network and so do not connect, the reason I have them passive scanning is because if I take the wifi down overnight I discovered all my pi's are probing permanently and a lot... so can do scan_ssid in supplicant but still if the wifi is down still flooding probe requests. (up to 12 pi's on at once)

So what I would like is ignore broadcast probes but keep sending out the ssid in broadcasts, that way passive scanning on the client stops the probes until it sees a broadcast.

So could be a ignore_broadcast_ssid=3 type added to hostapd to just ignore broadcast_ssid probe requests, and leave the ssid in your own broadcasts.

But, I discovered you can pass extra hostapd parameters using

uci add_list wireless.radio1.hostapd_options="ignore_broadcast_ssid=2"

but when I checked it adds this at the top of hostapd, and it is then redefined again by the default openwrt set up of hostapd based on hide_ssid

(I have a hunch there is some trick involving probes to jack your connection on outlying weak signal nodes, so also why been looking into it... the raspberry pops up as wifi direct unless you physically disable the option in wpa_supplicant (though that should be default), so spotted and fixed that, but may still be a window of opportunity, because still seeing probe requests when you would not expect them, and observing with my esp8266 device rssi of some probes different to suspicious probes.... so working on a wifi guard chip idea for esp-01 which are quite good little devices)

but anyway, just to ignore broadcast probes would save some traffic...

I mean I have not really got time for this "Spy vs. Spy" crap, but makes you realise how dependent on wi-fi you are.... and as that seems to be the name of the game... war for the nature of the world eh!

an interesting dichotomy, either your nodes start announcing here I am looking for this AP when the AP is not available with scan_ssid set in wpa_supplicant or they are quiet when AP not available with passive_scan but you cannot ignore broadcast probes to the AP on the AP

So, seems to me there are a few optimums depending on what devices you are trying to support and the hostility level of the area you are in... number of corporat-king spooks/script-kiddies in proximity... like spy-rock signal override proximity eh!

So openwrt kind of optimised for general purpose, more roaming based, walking round with your mobile-phone spy-in-your-hand devices optimised...

I'm more high hostile-level all stationary devices situation... and the devices running proprietary drivers... reflections on trusting trust eh!

The guard-chip concept seems sound... with my test device just observing probes noticed some big signal differences, so with guard device cm away from target can easily detect odd signals.. getting like -10db about 10cm away, but probably a spook can use transmitters above -20db legal limit of transmitter eh! probably reading my mind using satellite ECG now eh! the elons and their satellite arrays eh!

If they are reading my mind they will probably be picking up "I really like beer" signals a lot!

funny, definition of paranoia is awareness of possibilities....

latest openwrt update seems quite solid...

OK after doing some work on the guard chip concept using an ESP-01 of which I have a few, after doing some calibration and discovering not all ESP-01's are equal, running two quite closely matched in parallel just displaying signal strength and packet types on a channel only I am using...

Looked like someone injecting a beacon with a low power, which I would guess may trigger a station to reassociate, which is what was happening a lot, less so with latest openwrt perhaps. But thats more an attack on the station firmware I guess. The internet eh! double edged sword, dark tricks available if you want to look for them. Really do need to run with your own local administered macs on your nodes so no info given to observers about the actual chipset eh! Too late for that as attacker is also in stationary vicinity so already got the info.

(I say that because I could see the beacon that was due arrive with the right signal strength)

What I want is hostapd to ignore any probe request that does not specify my ssid in the request. I do not mind boadcasting the ssid in the beacons, apparently a whole mapping system available based on ssid names and maybe macs. And broadcasting the ssid allows nodes to be silent when not getting a broadcast from the correct ssid in range. As I said, an odd conundrum that seems an opening.

Is that possible? i Could not see how.

(funny the possibility exists to spam people with your devices requesting an ssid name in the probe request that is a 32 character marketing phrase like your website address or business name... on any mobile device... I guess on your phone with only user level access you have to temporarily actually create an ssid with that name to get one succesful connect and then it's spam away wherever you go eh!)

One funny one that made me think, "Ninja they are not" and then later made me think, "maybe they were trying to be intimidatory"... a probe request for "police surveillance van" popped up, so time matched it to the road cam I have up and... well, two possibilities really... or it was a car all along LOL!