wpa_cli: windows named pipe implementation doesn't handles unsolicited messages
mb.hostap-mailinglist at marco-borm.de
Tue Sep 12 07:04:32 EDT 2006
I understand that wpa_cli compiled for windows is currently unable to
receive/handle unsolicited messages while waiting for user-input, but
that isn't the problem here.
I think my question was misunderstood, because I directed it to be a
This happened because the wpa_supplicant was the lot of my colleague so
I don't knew that the wpa_ctrl.c was the official API for the
But because it is, the problem is independent from wpa_cli itself.
So to clarify the problem:
Currently wpa_ctrl_request() is broken under windows using named pipes,
because it doesn't work as it is documented.
The msg_cb is never called and the caller possibly gets unsolicited
messages in the reply-buffer.
This doesn't happened under Windows using the old UDP-Interface.
I appended a patch-file to fix that problem.
With kind regards
Jouni Malinen wrote:
> On Mon, Sep 11, 2006 at 08:26:10PM +0200, Marco wrote:
>> did I overlook something or is the handling for unsolicited messages
>> missing in the NamedPipes part?
>> There is only a single call to ReadFile() in
>> wpa_ctrl.c:wpa_ctrl_request(), so the caller possibly gets a unsolicited
>> message instead of the answer for his request.
> This is not really specific to named pipes, but a generic issue with
> using just one ctrl_iface connection for both solicited and unsolicited
> messages. In case of Windows version of wpa_cli, this issue is more
> likely to hit since wpa_cli does not have an easy mechanism for polling
> for pending messages while waiting for the user to enter the next
> command in interactive mode. Linux version uses alarm(1) to poll for
> these messages which makes it less likely to have unsolicited messages
> waiting to show up when the user has completed writing the command. On
> Windows, pending messages are processed only when user enters a new
> command (even an empty command, which will just make wpa_cli to read all
> pending unsolicited messages).
> The proper fix for this would be to use two ctrl_iface connections in
> the same way as wpa_gui is doing, but I have wanted to keep wpa_cli an
> example of the other option even though it is not really perfect for all
> In order to limit the confusing messages a bit, I added another call to
> wpa_cli_recv_pending() between the fgets() returning user input and
> wpa_request() being used to process the next command. This will greatly
> reduce the window of opportunity for unsolicited messages to be received
> while a command is being processed. The output is still somewhat
> confusing since the unsolicited messages are being printed between the
> user input and the output of that command, but at least the command
> response is being shown in most cases even if there were pending
> messages when the command was entered.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the HostAP