[PATCH V2] Handle EAGAIN in wpa_supplicant_ctrl_iface_send

Jouni Malinen j
Wed Sep 25 06:32:26 PDT 2013

On Mon, Sep 23, 2013 at 10:17:05AM +0200, Pontus Fuchs wrote:
> If a burst of events are sent, the socket queue can overflow and
> sendmsg fails with EAGAIN. When this happens the monitor is silently
> detached.

> diff --git a/wpa_supplicant/ctrl_iface_unix.c b/wpa_supplicant/ctrl_iface_unix.c
> @@ -623,14 +623,21 @@ static void wpa_supplicant_ctrl_iface_send(const char *ifname, int sock,
> -				if (dst->errors > 1000 ||
> -				    (_errno != ENOBUFS && dst->errors > 10) ||
> -				    _errno == ENOENT) {
> +				if (dst->errors > 1000 || _errno == ENOENT)
> +					detach = 1;
> +				if (!(_errno == ENOBUFS || _errno == EAGAIN ||
> +				    _errno == EWOULDBLOCK) && dst->errors > 10)
> +					detach = 1;

I'm seeing quite bad issues with the control interface sockets reaching
the maximum send buffer limit and getting stuck in the previous design.
This change could make this happen even more easily, so I don't think I
can apply this now. I pushed a workaround patch to recover from this
state. It is not really nice design, but well, no easy solution for the
real issue has shown up yet and it may be necessary to do a much larger
design change to address this cleanly using connection oriented sockets
rather than a single unconnected socket.

I would also welcome a patch to figure out more reliably if a client of
the ctrl_iface socket is not available to reduce the likelihood of
messages being left in the send buffer (or a timeout to get rid of those
pending messages somehow if that is possible with a single socket). I
did not see any obvious way of doing this without using multiple sockets
and potentially changes to the control interface that would not
necessarily be backwards compatible (i.e., without requiring all clients
to be rebuilt in addition to modifying wpa_supplicant).

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list