The initial situation is quite simple:

  • I create a hotspot in a Linux machine: nmcli dev wifi hotspot con-name "John" (see below for the complete script)

  • I show the password (and QR code) with: nmcli d w s (abbreviated from nmcli dev wifi show-password)

  • The hotspot appears on my (Android 11) phone, and asks for the password. I scan the QR code, but can't connect. (Just in case, I also tried typing the password).

I more or less eliminated the Broadcom BCM4313 issues I suspected previously, as I created two 'live' version of the OS (Slackware64-current) and both manage hotspots just fine (at least without passwords).

In case of the live-versions, I can't find how to password protect the Hotspot. Even after specifying a PW (and restarting the hotspot), the Access Point remains open (and connectable without password).

Also, I tried wihotspot - a script specialized in creating hotspots - but could not get it to work at all.

(A possibly related: Quite frequently, the Android QR code reader reports formatting errors. But, as mentioned, entering the password manually fails too.)

What could I be doing wrong here? Could this be a problem with certificates?

UPDATE Using the instructions on this page, I manage to get the hotspot running, but only if I don't specify a password (ie. if I don't include the two lines in Step 4)

As soon as I include a password, the phone disconnects, and asks me to enter a password. Neither using QR code nor entering the pw manually gets a connection.

Notably, the phone icon did detect that the site was now protected by changing the Wifi icon. (To be sure, I first deleted the previous definition using nmcli c del xxx)

UPDATE 2 A few data asked for in the comments:

  • I tried several passwords - with and without special characters. Ultimately even tried 'password'
  • I made Android forget any of the registered records
  • Even made the phone reset the networking completely
  • journalctl doesn't get installed in Slackware, but I check /var/log syslog, .../messages etc, no indications of problems.

ACTUAL STATE: I have this script:


case "$1" in
        nmcli c down $CON_NAME
    nmcli c down $CON_NAME
    nmcli c del $CON_NAME
    nmcli c a type wifi ifname $IF_NAME con-name $CON_NAME autoconnect y ssid $CON_NAME
    nmcli c m $CON_NAME 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared
    #nmcli c m $CON_NAME wifi-sec.key-mgmt wpa-psk
    #nmcli c m $CON_NAME wifi-sec.psk SimplePassword
    nmcli c up $CON_NAME

If the script as ./start_ap.sh, the hotspot runs, is connectable, but is 'open'. If I run ./start_ap.sh down, the hostspot is disabled. If I uncomment the two lines near the end and put the SimplePassword in the phone, I can't connect anymore.

Yet more strangeness

Friday, while I was at the university, I asked a student of mine

  • to connect with his Android 9 phone to the hotspot (which had a password set), and he connected without problems!
  • as he had his notebook, he also tried to connect from there, and it failed.

So, these two cases indicate just about the opposite from my experience.

Not a solution!


  • The errors occur with some Android phones, but not all (v9 worked, v10 and v11 failed, but only one phone of each version tested),
  • The errors occur with some laptops as client, but not all (a Windows client failed),
  • All tests were done with (or without) the same (simple) password, with the hotspot on the same laptop, using the same Broadcom chip,

I seem to have to have to conclude that:

  • It is not a direct hardware problem
  • It is not driver compatibility problem - not as far as driver seems to 'drive' the hardware.
  • There is still some possibility that there are timing issues, but not really protocol problems.
  • What does your phone say, just "bad password"? What kind of thing are you using as a password? There are requirements for wpa-psk to be "8 to 63 characters" and certain symbols could get eaten by the shell. Also make sure to delete/forget the SSID in android. Maybe try and check if anything is getting written to the networkmanager logs like: journalctl -u NetworkManager.service
    – Cpt.Whale
    May 16, 2022 at 17:27
  • @Cpt.Whale, added an UPDATE 2 to the original post. Thanks for the suggestions
    – jcoppens
    May 17, 2022 at 17:08
  • Try the following method1 and method2 for creating the hotspot. What is your distro?
    – harrymc
    May 19, 2022 at 18:58
  • @harrymc, Thanks - had already tested both methods. Couldn't really list them all in the original post, but have been at this for a time now! Just to be clear, I can connect if no password is set in the hotspot.
    – jcoppens
    May 19, 2022 at 19:13
  • What is the exact error you get when a password is defined?
    – harrymc
    May 19, 2022 at 19:16

1 Answer 1


We also encountered this problem, the troubleshooting steps are as follows:

  1. vi /lib/systemd/system/wpa_supplicant.service, add the -dd parameter to the wpa_supplicant command line, and refresh the configuration with systemctl daemon-reload && systemctl restart wpa_supplicant.

  2. vi /var/log/syslog can see that after executing nmcli con up SSID, there are several prompts such as "Failed to clear default encryption keys (ifname=xxx keyidx=n)", indicating that the driver layer cannot perform the necessary cleanup on the keys stored in the ram of the wlan network card.

We had this problem on an armbian 20.04 system, the same hardware works fine on OpenWRT 19.07. So it should be a linux kernel or driver problem.

Temporary solution: Completely power off and restart (cold boot) the device (this ensures that the WLAN card memory is initialized to an clean state), and then execute nmcli con up SSID, then enter the password on the phone to connect to the AP normally.

Completely solve this problem may need to wait for bug fixes at the Linux kernel or driver level.



We have this problem with two identical hardware boxes (NanoPi R1), one of the boxes has armbian installed, and the other has the official Uubntu 20.04 from the hardware manufacturer.

We tried disabling Network Manager (nmcli dev set wlan0 managed no) on both systems and then starting hostapd to take over the WLAN device (hostapd -dd /etc/hostapd/wlan0_ap.conf):

  • On armbian, hostapd fails to start and exits with an ioctl error.
  • On ubuntu provided by the box manufacturer, hostapd can be started normally, and the password problem of nmcli is perfectly solved.

Further observation found that on the ubuntu provided by the box manufacturer, there is an additional daemon named brcm_patchram_plus, whose startup command line is something like: /bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212 ..... We suspect that this daemon is responsible for the difference in performance between the two systems.

  • Thanks for the suggestion and info! I think you mean 'Completely power of and restart the device' you mean the cell phone (I can't reboot the PC - it's in use for routing). I checked the syslog, but did not find any references to encryption.
    – jcoppens
    Jun 15, 2022 at 20:45
  • I mean you need to power off and restart (cold boot) the AP device. You need to add the -dd argument to the wpa_supplicant service to see the log output.
    – ASBai
    Jun 15, 2022 at 21:58
  • Ok... The 'AP device' is NM, on my home computer, which also runs as a router for other users, so I cannot switch the machine off at any time. At the beginning of my experiments I did this a couple of times but didn't notice any difference. I did not use the -dd option, so maybe I'll do a few more tests over the weekend.
    – jcoppens
    Jun 16, 2022 at 1:19
  • @jcoppens I updated my answer, maybe you can try hostapd?
    – ASBai
    Jun 17, 2022 at 19:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .