0

I just installed Raspbian on my SD card, but I cannot connect to my network initially because it is hidden. I've tried following the guide https://raspi.tv/2017/how-to-auto-connect-your-raspberry-pi-to-a-hidden-ssid-wifi-network here (and the guide it links to). I've tried modifying my wpa_supplicant.conf to look like

ctr_interfaces=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
        ssid="My Network Name"
        scan_ssid=1
        psk="secret_password"
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP
        group=CCMP
        auth_alg=OPEN
        priority=1
        id_str="raspi"
}

etc/network/interfaces looks like this:

auto lo
iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Also, I can't make the network visible.

  • Can you connect a monitor and keyboard? – goldilocks Aug 2 at 14:49
  • Unlikely to be a Pi specific problem. Not being able to connect to a hidden (no broadcast ssid) network is a common problem. – joan Aug 2 at 15:02
  • @goldilocks I can connect to a monitor and a keyboard. – Henry Westfall Aug 2 at 15:13
  • 1
    You'll need a bssid=xx:xx:xx:xx:xx:xx clause with the MAC address of the access point and scan_ssid=1. The simpler option is unhide the SSID. Hiding an SSID does precisely nothing to enhance WiFi security. – Dougie Aug 2 at 20:00
  • If you tried using normal Raspbian networking (preferably dhcpcd - but even obsolete Wheezy settings would work if you remove extraneous parameters) it would work. – Milliways Aug 2 at 22:21
0

This presumes Raspbian 10 (buster).

First stop the system dhcpcd service:

sudo systemd stop dhcpcd

Check wpa_supplicant has stopped:

ps -C wpa_supplicant

If not, kill it. Temporarily move /etc/network/interfaces and replace it with an empty file.

Then in one terminal (this will block if successful and produces output as it runs):

sudo wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

This will run in the foreground and produce output comprehensible enough to tell whether it has succeeded or not. If so, you can now (from another terminal)

sudo dhcpcd --nobackground

You should be able to see what's going on with the two components.

Note that normally, dhcpcd starts wpa_supplicant. However, if it is already running (because you started it first, as above), a second instance will not start on the same interface.

  • Dhcpcd will NOT be running because the interfaces calls DHCP – Milliways Aug 3 at 23:02
  • 1
    @Milliways Dhcpcd is normally started by directly by systemd at boot (dhcpcd.service). The stuff in /etc/network is just used by the commands ifup and ifdown, which are run by networking.service-- but only once at boot or when subsequently invoked (ie., that is not a persistent service; I think mostly what it is about is providing concrete criteria for network-online.target). Other than being run in order if they are both running, one does not require the other, and while the networking service may make use of dhcpcd, dhcpcd does not make any use of the networking service... – goldilocks Aug 4 at 12:17
  • ...If you stop the service and start dhcpcd manually, nothing in /etc/networks matters (actually, it is exactly the same if you start it via systemd start dhcpcd, but the manual foreground invocation above is simpler for debugging problems). That said, to be paranoid, it might as well be emptied first (so edited). – goldilocks Aug 4 at 12:17
  • dhcpcd is a DHCP client (among other things) If dhcpcd detects another active DHCP client it disables itself. There is a boot message to this effect if interfaces includes dhcp. All the OP has to do is pick a networking tool (anp properly configure it) rather than trying to mix incompatible tools (and not include random parameters). Mind you, the OP has provided no meaningful status information. – Milliways Aug 4 at 12:27
  • I'm not sure what your point is. The first instruction above is sudo systemd stop dhcpcd. This will stop dhcpcd and it will not be running. You can then invoke sudo dhcpcd manually. There is no "trying to mix incompatible tools" here. My point is that if there is a problem beyond the system's control -- a reason why the normal services are not working -- this is a way to check for a significant subset of such reasons. – goldilocks Aug 4 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.