Improved error handling for wpa_supplicant interactions

[mycognosist]

Relates to this issue for the peach-probe diagnostic tool.

Problem

The peach device can operate in client or access-point mode (WiFi). The wpa_supplicant process is stopped when access-point mode is enabled and the hostapd process is started (allowing management of the ap0 interface which is a virtual interface utilising wlan0). Since several peach-network RPCs make use of wpa_supplicant, these calls fail when access-point mode is active. Some RPC calls currently panic when client mode is active but there is no active connection.

Example behaviour for the status(iface) RPC:

Access-point mode is active:

RPC Request:

curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "method": "status", "params" : {"iface": "wlan0" }, "id":1 }' 127.0.0.1:5110

RPC Response:

{"jsonrpc":"2.0","error":{"code":-32013,"message":"Failed to open control interface for wpasupplicant: No such file or directory (os error 2)"},"id":1}

WPA_CLI output (sudo wpa_cli -i wlan0 STATUS):

Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory

Client mode is active but no credentials have been entered for wireless access-points:

RPC Request:

curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "method": "status", "params" : {"iface": "wlan0" }, "id":1 }' 127.0.0.1:5110

RPC Response:

curl: (52) Empty reply from server

Binary stderr:

thread 'http.worker00' panicked at 'None value unwrap for pairwise_cipher in get_status', src/network.rs:442:14

WPA_CLI output (sudo wpa_cli -i wlan0 STATUS):

wpa_state=INACTIVE
p2p_device_address=26:35:dc:0e:6a:88
address=b8:27:eb:9b:5d:5f
uuid=a768e933-064d-5417-b613-ca2de4a29095

Client mode is active but no wireless connection is active:

RPC Request:

curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "method": "status", "params" : {"iface": "wlan0" }, "id":1 }' 127.0.0.1:5110

RPC Response:

curl: (52) Empty reply from server

Binary stderr:

thread 'http.worker00' panicked at 'None value unwrap for pairwise_cipher in get_status', src/network.rs:442:14

WPA_CLI output (sudo wpa_cli -i wlan0 STATUS):

> STATUS
 wpa_state=DISCONNECTED
 p2p_device_address=c6:c2:20:c3:3c:60
 address=b8:27:eb:9b:5d:5f
 uuid=a768e933-064d-5417-b613-ca2de4a29095

Client mode is active and connected to an access-point:

RPC Request:

curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "method": "status", "params" : {"iface": "wlan0" }, "id":1 }' 127.0.0.1:5110

RPC Response:

{"jsonrpc":"2.0","result":"{\"address\":\"b8:27:eb:9b:5d:5f\",\"bssid\":\"e4:95:6e:40:bd:89\",\"freq\":\"2462\",\"group_cipher\":\"CCMP\",\"id\":\"0\",\"ip_address\":\"192.168.8.193\",\"key_mgmt\":\"WPA2-PSK\",\"mode\":\"station\",\"pairwise_cipher\":\"CCMP\",\"ssid\":\"shadow\",\"wpa_state\":\"COMPLETED\"}","id":1}

WPA_CLI output (sudo wpa_cli -i wlan0 STATUS):

bssid=e4:95:6e:40:bd:89
freq=2462
ssid=shadow
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.8.193
p2p_device_address=c2:f1:9a:ba:46:dc
address=b8:27:eb:9b:5d:5f
uuid=a768e933-064d-5417-b613-ca2de4a29095

---

Solution

The first step is to prevent peach-network from panicking. This can be achieved by checking the wpa_state value returned from the status call and acting accordingly, instead of assuming a COMPLETED state and simply iterating through the lines of output to harvest field values (as is currently the case). Once this initial solution has been implemented, it might be worthwhile trying to improve the error message for status() RPC calls made when access-point mode is active.

Another potential solution is to add an additional wireless interface to the peach device so that a client and access-point can each be run on dedicated devices. This will increase the cost of producing the device but will ultimately simplify the networking and probably make for a more stable system.