On 12/02/2017 02:26 AM, Jouni Malinen wrote:
On Fri, Dec 01, 2017 at 04:41:43PM -0800, Ben Greear wrote:
While debugging some strange issues, I noticed that my wpa_cli
in monitor mode was disconnecting because the PING failed.
It looks like the reason it fails goes something like this:
wpa_cli: ping
wpa_supplicant: do things, post logging message to wpa-cli
wpa_supplicant: read ping & reply with pong
wpa_cli: reads 'logging message', decides PONG fails, and disconnects.
Looks like wpa_cli -a<script> case is not using two control interface
sockets like the interactive case does to avoid this.. I guess that
should be fixed.
So, nasty race I guess?
Yeah.. wpa_ctrl_request() tries to avoid this with the msg_cb() design
based on reply starting with '<', but that is not really perfect and
everything that really matters from robustness view point should use a
separate socket for receiving messages (registered with "ATTACH") and
for commands (like this "PING" case) to avoid any chance of interpreting
an unsolicited event message as a response to a pending command.
Back in to 2013, a change went in to add IFNAME=foo before the <, so that is probably
the primary reason this fails.
I think this patch might help:
diff --git a/src/common/wpa_ctrl.c b/src/common/wpa_ctrl.c
index 623c2a7..1f1c9c4 100644
--- a/src/common/wpa_ctrl.c
+++ b/src/common/wpa_ctrl.c
@@ -540,7 +540,8 @@ retry_send:
res = recv(ctrl->s, reply, *reply_len, 0);
if (res < 0)
return res;
- if (res > 0 && reply[0] == '<') {
+ if ((res > 0 && reply[0] == '<') ||
+ (res > 6 && strncmp(reply, "IFNAME=", 7) == 0)) {
/* This is an unsolicited message from
* wpa_supplicant, not the reply to the
* request. Use msg_cb to report this to the
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
