HostAP Digest, Vol 70, Issue 9

[Annie Rota]

> Date: Wed, 4 Feb 2009 22:11:29 +0200
> From: Jouni Malinen <j at w1.fi>
> Subject: Re: [PATCH] suggestion : flush outputs in wpa_printf
> To: hostap at lists.shmoo.com
> Message-ID: <20090204201129.GG28563 at jm.kir.nu>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Feb 03, 2009 at 05:23:48PM +0100, Annie Rota wrote:
>
> > In order to improve interprocess readability between wpa_supplicant and
> > clients of the control interface,
> > I propose to fflush the outputs of wpa_printf more often (especially
> > stdout).
>
> This is likely to increase latency and make debug mode differ more from
> non-debug as far as timing is concerned which could, at least in theory,
> make it more difficult to reproduce some timing issues. Could you please
> describe the use case where there are multiple sources producing output
> to stdout? Is it clear that the other sources are flushing output as
> well? What about the debug-to-a-file option? If it is really going into
> a file writing into the same file from another process at the same time
> may not be that good of an idea..
>
> If a better ordering of events is desired, it could be done more
> reliable by using timestamps on the event messages from all sources and
> then merging the separately generated outputs together and sorting the
> result based on the timestamps.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
>
>
>
> Hi Jouni,
Thanks for your answer,
I suspected this could cause possible performance issues (not observed, but
not really tested from my side).

My use case is simpler than what you imagined, I guess. I just needed to
retrieve the information from wpa_supplicant, and noticed that some outputs
were never displayed in the clients (wpa_cli stdout, or debug-file output)
when produced messages do not fill the output buffer, as Dan Williams
explained in his previous mail.
Of course, when you enable debug mode (-d -dd), the flow is more important
and the buffer flushes naturally, but with low traffic output messages, some
outputs are displayed very late, and the client analysing it can't take any
decision based on wpa_supplicant feedback, when asynchronous messages are
involved (eg: when is the pairing done ?).
Probably I should directly interface to the control interface, but this was
an easy and simple patch to solve my problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20090205/bc8cc7e0/attachment.htm