Just as an added information, providing the switch `-s /run/wpa_supplicant` with the network-control interface connected should work.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/2074070 Title: unable to get WPA supplicant status via wpa-cli utility from a snap Status in wpa package in Ubuntu: Confirmed Bug description: Hi As a developer, while trying to get the wpa_supplicant status by using wpa_cli, it always returns a timeout from the snap context on Ubuntu Core 20. The problem is not reproducible with Ubuntu Classic. I did some further analysis to get strace output of `wpa_cli` as well as `wpa_supplicant` for the good (running wpa_cli from host terminal) and bad (running from snap context) cases. Here is the strace output of the wpa_cli; Good case: ``` bind(3, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_29279-1"}, 110) = 0 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/wpa_supplicant/wlp0s20f3"}, 110) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 sendto(3, "STATUS", 6, 0, NULL, 0) = 6 pselect6(4, [3], NULL, NULL, {tv_sec=10, tv_nsec=0}, NULL) = 1 (in [3], left {tv_sec=9, tv_nsec=999998877}) recvfrom(3, "bssid=68:a0:3e:93:47:2f\nfreq=526"..., 4095, 0, NULL, NULL) = 316 newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}, AT_EMPTY_PATH) = 0 write(1, "bssid=68:a0:3e:93:47:2f\n", 24bssid=68:a0:3e:93:47:2f ) = 24 write(1, "freq=5260\n", 10freq=5260 ) = 10 write(1, "ssid=SUPERBOX_Wi-Fi_472B\n", 25ssid=SUPERBOX_Wi-Fi_472B ) = 25 write(1, "id=0\n", 5id=0 ) = 5 write(1, "mode=station\n", 13mode=station ) = 13 write(1, "wifi_generation=5\n", 18wifi_generation=5 ) = 18 write(1, "pairwise_cipher=CCMP\n", 21pairwise_cipher=CCMP ) = 21 write(1, "group_cipher=CCMP\n", 18group_cipher=CCMP ) = 18 write(1, "key_mgmt=WPA2-PSK\n", 18key_mgmt=WPA2-PSK ) = 18 write(1, "wpa_state=COMPLETED\n", 20wpa_state=COMPLETED ) = 20 write(1, "ip_address=192.168.1.101\n", 25ip_address=192.168.1.101 ) = 25 write(1, "p2p_device_address=b0:a4:60:e0:0"..., 37p2p_device_address=b0:a4:60:e0:0c:91 ) = 37 write(1, "address=b0:a4:60:e0:0c:90\n", 26address=b0:a4:60:e0:0c:90 ) = 26 write(1, "uuid=962ca758-c0a7-54c0-ae01-689"..., 42uuid=962ca758-c0a7-54c0-ae01-68990801f7a0 ) = 42 write(1, "ieee80211ac=1\n", 14ieee80211ac=1 ) = 14 unlink("/tmp/wpa_ctrl_29279-1") = 0 close(3) = 0 exit_group(0) = ? ``` Bad case (running from the snap context) ``` getpid() = 58024 bind(3, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_58024-1"}, 110) = 0 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/wpa_supplicant/wlp0s20f3"}, 110) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 sendto(3, "STATUS", 6, 0, NULL, 0) = 6 fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 unlink("/tmp/wpa_ctrl_58024-1") = 0 close(3) = 0 write(1, "'STATUS' command timed out.\n", 28'STATUS' command timed out. ) = 28 exit_group(-2) = ? +++ exited with 254 +++ ``` Here is the wpa_supplicant strace output; For the good case, wpa_supplicant was able to send the message back to the wpa_cli; ``` pselect6(19, [4 5 7 9 10 11 13 14 15 16 17 18], [], [4], {tv_sec=9, tv_nsec=999997000}, NULL) = 1 (in [14], left {tv_sec=9, tv_nsec=281454971}) recvfrom(14, "STATUS", 8193, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_172293-1"}, [128 => 25]) = 6 getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(14, TIOCOUTQ, [0]) = 0 socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 19 ioctl(19, SIOCGIFADDR, {ifr_name="wlp0s20f3", ifr_addr={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.1.101")}}) = 0 close(19) = 0 getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(14, TIOCOUTQ, [0]) = 0 sendto(14, "bssid=68:a0:3e:93:47:2f\nfreq=526"..., 316, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_172293-1"}, 25) = 316 pselect6(19, [4 5 7 9 10 11 13 14 15 16 17 18], [], [4], {tv_sec=9, tv_nsec=278742000}, NULL ``` However, for the bad case (where wpa_cli is called from the snap context), the data is available but while wpa_supplicant tries to send it, the socket is probably not visible since we got a no such a file error; ``` recvfrom(14, "STATUS", 8193, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_172203-1"}, [128 => 25]) = 6 getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(14, TIOCOUTQ, [0]) = 0 socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 19 ioctl(19, SIOCGIFADDR, {ifr_name="wlp0s20f3", ifr_addr={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.1.101")}}) = 0 close(19) = 0 getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(14, TIOCOUTQ, [0]) = 0 sendto(14, "bssid=68:a0:3e:93:47:2f\nfreq=526"..., 316, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_172203-1"}, 25) = -1 ENOENT (No such file or directory) getsockopt(14, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(14, TIOCOUTQ, [0]) = 0 ``` I dont see any denial for accessing to the unix socket and the same problem also occurs within devmode. I'm assuming that since all of the snaps have their own `/tmp` directory, they may not be able to reach out to the `/tmp` of the host. Moreover, it seems like the wpa_cli also opens a unix socket that exist within the `/tmp` directory. Thus, we might be observing this behavior. Could you please suggest a potential fixes? Thanks, Bugra To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/2074070/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
