wpa_cli: windows named pipe implementation doesn't handles unsolicited messages

[Marco Borm]

Hi,

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 
wpa_cli-problem.
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 
wpa-supplicant.
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
Marco


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
> uses.
>
> 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...
Name: wpa_ctrl-namedpipe.patch
Url: http://lists.shmoo.com/pipermail/hostap/attachments/20060912/1a2ffd3a/attachment.txt