So I looked into this and the observations made in this post is correct.
It's because the default path of the wpa_cli client socket made is in
/tmp (they use AF_UNIX sockets, and UDP protocol - this means the client
socket must bind a visible place for the server)

/tmp is obviously not visible outside the snap, so the wpasupplicant
server will never be able to respond.

The good news is that wpa_cli has a -s switch where you can change the
location of the socket that the client is using. For example:

"wpa_cli -s /path/to/shared/location" should hopefully fix the issue

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

Reply via email to