3

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:

#!/bin/sh
CON_NAME="XXYY"
IF_NAME="wlan0"

case "$1" in 'down') 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!

Considering:

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

2 Answers2

1

Did you try disable Protected Management Frames? After that, connecting to the AP on Android 11 started working for me:

nmcli c modify $CON_NAME wifi-sec.pmf 1
Fialot
  • 11
0

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.

===============================

UPDATE:

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.

ASBai
  • 121