My OpenWrt router is configured as a bridge using relayd connected to a tri-band router and would prefer to make the "Bridge" VAP not visible.
Is it possible to manually add the client mode connection to WPA_Supplicant because whenever the host SSID is hidden the connection is lost.
I'm not sure I understand. Is there are reason you're not configuring the client mode connection on OpenWrt with the web GUI or the relevant config files (e.g. /etc/config/wireless)?
Are you having an issue using the wireless config?
Also, I don't think there should be an issue setting up an connection to an SSID, then hiding it...perhaps there's issues with using underlying subsystems?
Maybe showing us your conifgs will help.
I have one static device that does not like hidden SSIDs.
You gain nothing security-wise by hiding SSIDs.
Strong passwords, and isolating wireless devices on guest/IoT networks is a better approach.
I am using the web UI, and also inspecting the configuration files
No, the wireless configuation works fine when the SSID is visible
Can you please confirm this works?
config wifi-device 'radio1'
option type 'mac80211'
option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option htmode 'VHT80'
option channel 'auto'
option cell_density '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option mode 'sta'
option network 'wwan'
option ssid 'Bridge'
option encryption 'psk2'
option key 'password'
option disabled '0'
As mentioned in my post, once the host SSID for the "Bridge" is hidden then the connection is lost. Is there any way to set this manually in configuration files?
This is the only documentation I can find which seems to explain the issue but doesn't explain how to overcome it https://oldwiki.archive.openwrt.org/doc/howto/clientmode#wpa_supplicant_with_hidden_aps_and_virtual_aps_vap
Regards,
Maybe this is the issue?
The device is TP-Link Archer C50 V3 connecting to Netgear R8000
This has nothing to do with security concerns
The bridged network is specifically to isolate many IoT devices away from the main AP
I would just prefer to have the "Bridge" SSID hidden
Regards,
Could very well be.
Why I mentioned it.
Instead of seeing the SSID, selecting it, and being able to connect, the clients will have to enter the "hidden" SSID.
I connected a lot of times to a hidden BSS without any diferent configuration, but, my suggestion is to apply to the set configuration the hidden bss mac address (bssid).
In your case, you can try for example by UCI:
uci set wireless.default_radio1.bssid="XX:XX:XX:XX:XX:XX" # the hidden BSSID
uci commit
wifi reload
My assumption is that probably the router which "hides" the BSSID is not only not transmiting the WiFi beacons, probably it is also not answering the probes sent by the STA.
Thanks for the suggestion, I tried this but it still doesn't connect when the SSID is hidden.
Here's the logs showing the wlan connection up and down so hopefully someone can identify what's going on:
wlan link up (SSID visible)
Tue May 10 14:58:13 2022 daemon.notice netifd: Wireless device 'radio1' is now up
Tue May 10 14:58:13 2022 daemon.notice netifd: Interface 'wwan' is enabled
Tue May 10 14:58:16 2022 kern.info kernel: [ 1631.846400] rt3050-esw 10110000.esw: link changed 0x02
Tue May 10 14:59:29 2022 daemon.notice wpa_supplicant[1217]: wlan1: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='Bridge' freq=5280 MHz)
Tue May 10 14:59:29 2022 kern.info kernel: [ 1704.791269] wlan1: authenticate with xx:xx:xx:xx:xx:xx
Tue May 10 14:59:29 2022 kern.info kernel: [ 1704.809333] wlan1: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
Tue May 10 14:59:29 2022 kern.info kernel: [ 1704.815905] wlan1: authenticated
Tue May 10 14:59:29 2022 daemon.notice wpa_supplicant[1217]: wlan1: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='Bridge' freq=5280 MHz)
Tue May 10 14:59:29 2022 kern.info kernel: [ 1704.820767] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1/3)
Tue May 10 14:59:29 2022 kern.info kernel: [ 1704.827684] wlan1: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x11 status=0 aid=1)
Tue May 10 14:59:29 2022 kern.info kernel: [ 1704.835674] wlan1: associated
Tue May 10 14:59:29 2022 daemon.notice wpa_supplicant[1217]: wlan1: Associated with xx:xx:xx:xx:xx:xx
Tue May 10 14:59:29 2022 daemon.notice netifd: Network device 'wlan1' link is up
Tue May 10 14:59:29 2022 daemon.notice netifd: Interface 'wwan' has link connectivity
Tue May 10 14:59:29 2022 daemon.notice netifd: Interface 'wwan' is setting up now
Tue May 10 14:59:29 2022 daemon.notice wpa_supplicant[1217]: wlan1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Tue May 10 14:59:29 2022 daemon.notice netifd: wwan (7474): udhcpc: started, v1.33.2
Tue May 10 14:59:29 2022 daemon.notice netifd: wwan (7474): udhcpc: sending discover
Tue May 10 14:59:30 2022 daemon.notice wpa_supplicant[1217]: wlan1: WPA: Key negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=CCMP]
Tue May 10 14:59:30 2022 daemon.notice wpa_supplicant[1217]: wlan1: CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=0 id_str=]
Tue May 10 14:59:30 2022 kern.info kernel: [ 1705.785333] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Tue May 10 14:59:31 2022 daemon.notice netifd: wwan (7474): udhcpc: sending discover
Tue May 10 14:59:32 2022 daemon.notice netifd: wwan (7474): udhcpc: sending select for 192.168.1.3
Tue May 10 14:59:33 2022 daemon.notice netifd: wwan (7474): udhcpc: lease of 192.168.1.3 obtained, lease time 4294967295
Tue May 10 14:59:33 2022 daemon.notice netifd: Interface 'wwan' is now up
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: reading /tmp/resolv.conf.d/resolv.conf.auto
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain test
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain onion
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain localhost
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain local
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain invalid
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain bind
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using only locally-known addresses for domain lan
Tue May 10 14:59:33 2022 daemon.info dnsmasq[1056]: using nameserver 192.168.1.1#53
Tue May 10 14:59:33 2022 user.notice firewall: Reloading firewall due to ifup of wwan (wlan1)
wlan link down (SSID hidden)
Tue May 10 15:03:56 2022 daemon.notice wpa_supplicant[1217]: wlan1: CTRL-EVENT-BEACON-LOSS
Tue May 10 15:03:56 2022 kern.info kernel: [ 1743.141894] wlan1: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)
Tue May 10 15:03:56 2022 daemon.notice netifd: Network device 'wlan1' link is down
Tue May 10 15:03:56 2022 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Tue May 10 15:03:56 2022 daemon.notice wpa_supplicant[1217]: wlan1: CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=7
Tue May 10 15:03:56 2022 daemon.notice wpa_supplicant[1217]: wlan1: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='Bridge' freq=5280 MHz)
Tue May 10 15:03:57 2022 daemon.notice netifd: wwan (7474): udhcpc: received SIGTERM
Tue May 10 15:03:57 2022 daemon.notice netifd: wwan (7474): udhcpc: unicasting a release of 192.168.1.3 to 192.168.1.1
Tue May 10 15:03:57 2022 daemon.notice netifd: wwan (7474): udhcpc: sending release
Tue May 10 15:03:57 2022 daemon.notice netifd: wwan (7474): udhcpc: entering released state
Tue May 10 15:03:57 2022 daemon.notice netifd: wwan (7474): Command failed: Permission denied
Tue May 10 15:03:57 2022 daemon.notice netifd: Interface 'wwan' is now down
Tue May 10 15:03:57 2022 daemon.notice netifd: Interface 'wwan' is disabled
Tue May 10 15:03:57 2022 daemon.notice netifd: Interface 'wwan' is enabled
Tue May 10 15:03:57 2022 daemon.warn dnsmasq[1056]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Tue May 10 15:06:36 2022 authpriv.info dropbear[5358]: Exit (root) from <192.168.2.66:52450>: Keepalive timeout
Regards,
reason=7 "Class 3 frame received from nonassociated STA"
Looks like it needs the SSID (ESSID) to be visible.
This event may also have occurred due to the host network being lost/restarted with the hidden SSID change?
But either way yes it certainly won't connect without the SSID being visible 
I'm not sure if this is what you want to accomplish, but I was able to hide the main 2.4 GHz wireless SSID, and connect to other 2.4 guest/IoT networks.
Let's call the main network "Network24"
It's been configured, and is working.
I checked "Hide ESSID".
There are guest/IoT 2.4 networks configured and working.
Each guest is on its own subnet.
Example -
Guest1 192.168.2.1
Guest2 192.168.3.1
The Zones are set as follows -
Guest1 ==> wan Input - Drop Output - Accept Forward - Drop
Guest2 ==> wan Input - Drop Output - Accept Forward - Drop
Each has their own DHCP and DNS traffic rules.
Each guest wireless interface is set to Isolate clients, so that clients can't talk to each other on the same subnet.
The Zone rules prevents guests from talking to each other on different subnets, and with the main network.
The guests are the only SSID's showing as available when my client device wants to connect.
The main 2.4 network (Network24) is showing as "Hidden network".
If I want to connect to it, I have to enter the SSID "Network24", and then the password.
Same principles apply for the 5 GHz band...I just happened to pick 2.4 for the test.
I have guest/IoT networks on both.
I don't think I need to isolate the clients but thanks for the advice.
I had no issues connecting in Windows 10 to the hidden SSID using the option "Connect even is this network is not broadcasting"
I've also been able to connect the OpenWRT client to a test router with hidden SSID so this is confirmed to be working.
I'm unable to connect specifically to the Netgear R8000 with hidden SSID and need an option to connect if not broadcasting.
Surely there must be a way to do this in OpenWrt ... https://oldwiki.archive.openwrt.org/doc/howto/clientmode#wpa_supplicant_with_hidden_aps_and_virtual_aps_vap
The R8000 uses the Broadcom chipset, which has very limited support in OpenWrt.
Could be why it's not working.
I have a hidden WDS setup, and that works just fine. Client device connects to it without issues. This is with an MT7905DAN (WDS) and MT7615 (client device). 22.03 branch. So looks like a driver limitation indeed.
I'm not running OpenWrt on the R8000
Years ago OpenWrt had a similar setting, called scan_ssid. It had to be set true to connect to a hidden AP. But I think that is now the default.
If you have also set bssid (AP MAC address), make sure the R8000 does not change its MAC when it is reconfigured.
Using a monitor radio to see what actually happens on the air would be useful here.
This setting is still used and default has changed from 0 to 1 (or true). You can find it in /var/run/wpa_supplicant-wlan*.conf
The functions you mention are documented in the old wiki https://oldwiki.archive.openwrt.org/doc/howto/clientmode#wpa_supplicant_with_hidden_aps_and_virtual_aps_vap
ap_scan (See the example wpa_supplicant.conf for more details)
- 1: wpa_supplicant initiates scanning and AP selection
- 0: driver takes care of scanning, AP selection, and IEEE 802.11 association parameters
- 2: like 0, but associate with APs using security policy and SSID (but not BSSID).
scan_ssid
- 0: do not scan this SSID with specific Probe Request frames (default)
- 1: scan with SSID-specific Probe Request frames (this can be used to find APs that do not accept broadcast SSID or use multiple SSIDs; this will add latency to scanning, so enable this only when needed)
I have tested scan_ssid=0 and scan_ssid=1 and there is no change. I haven't tested ap_scan
The AP MAC address is physical and does not change.
What should I be looking for? Logs don't seem to be showing anything useful ..
Look for OpenWrt to send a probe with the SSID, and for the R8000 to respond.
In the client logs do you see any activity related to connecting? Once the AP has been probed it should then associate, which is the first thing that will be logged.
This reinforce my theory about the R8000's meaning of "hidden" BSSID is something more than just not broadcast beacons. As you said the R8000 is not running OWRT, can you give it a try with OWRT or you need the stock firmware? If my assumption is right with OWRT in the R8000 this should work.
Anyway, have you tested with a diferent OWRT device as client? The behavior is the same?
That would be a good test...