Client mode connection to hidden SSID

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 :cry:

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 -



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.

1 Like

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 ...

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

  • 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...

I'm running FreshTomato on the R8000 and have avoided using OpenWrt due to speed issues reported here Nighthawk R8000 Throughput Speed Issues

I did restore the R8000 to stock firmware and it works fine with hidden SSID so the issue is with FreshTomato and how it handles the hidden SSID

I will log this fault with the FreshTomato developer but there still should be a way to force OpenWrt to connect using WPA_Supplicant :woman_shrugging:

It's a bit of a weird expectation to want OpenWrt to work around a Tomato bug. I hope the Tomato guys can help you, since in the end all they got access to is binary blobs as well. The Tomato community is where you should look for a solution, now that it's clear the issue is on their end.

1 Like

As you can see here it responds to the OpenWrt wireless scan but won't connect yet other devices can so I don't think you can say for certain that it's a Tomato bug

I don't know a **** of tomato but if they are similar to OWRT and they use the softmac/hostapd stack, you probably can set the "hidden option" directly in to the hostapd config file o via hostapd_cli (instead of the wireless config file or UCI equivalent they could have)

You can explore two different options, changing the default value specified as "0" to "1" or "2".

# Send empty SSID in beacons and ignore probe request frames that do not
# specify full SSID, i.e., require stations to know SSID.
# default: disabled (0)
# 1 = send empty (length=0) SSID in beacon and ignore probe request for
#     broadcast SSID
# 2 = clear SSID (ASCII 0), but keep the original length (this may be required
#     with some clients that do not support empty SSID) and ignore probe
#     requests for broadcast SSID


Source: ("THE" source)

1 Like

So I eventually figured this problem out.

My FreshTomato Netgear R8000 AP was connected to OpenWRT TP-Link Archer C50 V3 on SSID "Bridge" channel 52 (5.260Ghz) and the connection would fail when the SSID was hidden.

I found that when connected to channel 36 (5.180Ghz) or 40 (5.200Ghz) the hidden "Bridge" SSID connects without issue.

I did notice that some client devices didn't like channel 52+ so I guess that also includes the TP-Link Archer C50 V3.

Hopefully this might help someone in the future :+1:


Sounds like DFS being an issue?


When you mentioned DFS I searched the forum and found this which matches the channels I tested that hidden SSID does work, and the ones marked radar detection are the ones that don't work:

1 Like
  • I thought to mention DFS, but assumed the OP had set a non-DFS channel. The would definitely cause the issue
  • It could also be that the other device cannot use the other channels you set

Glad you got it working!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.