Capturing wpa_supplicant -dd output?

The Wanderer wanderer at fastmail.fm
Fri Apr 26 14:52:08 EDT 2013


On 04/26/2013 01:31 PM, Dan Williams wrote:

> On Thu, 2013-04-25 at 00:37 +0300, Jouni Malinen wrote:
> 
>> On Wed, Apr 24, 2013 at 11:44:33AM -0400, The Wanderer wrote:
>> 
>>> The full command line being run is:
>>> 
>>> wpa_supplicant -B -P "/var/run/wpa_supplicant.wlan1.pid" -i "wlan1" -D nl80211,wext -t -dd -c "/etc/wpa_supplicant/wpa_supplicant.conf"
>> 
>> You cannot fork the process to background (-B) and record the log
>> to stdout. stdout is closed whenever -B is included in the command
>> line and this will stop any logging. If you want to get the stdout
>> stored to a file, you would need to either keep the process on
>> foreground or use a command like "wpa_supplicant .... > /tmp/log
>> &".
> 
> Or how about "-f /tmp/log" instead?

As I mentioned in the original mail, this doesn't stop logging after
capturing the initial launch-time messages, which are what I'm after.
 From what I could tell when I tried it, it also seems to present
additional information interspersed with the information from those
initial messages, making it harder to filter out just the ones I had in
mind as being relevant.

I did ask whether I was barking up the wrong tree and should just fall
back to this logging type, but since that subsidiary/fallback question
wasn't addressed, I've proceeded with my original goal.

However, in the course of testing and pursuing that, I've discovered
that the problem I wanted to report doesn't seem to be quite what I
thought it was - and may not be in wpa_supplicant after all. I've got
some more things to pursue in that line, and if it does seem to be
relevant to wpa_supplicant in the end, I'll post about it separately.

-- 
    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger


More information about the HostAP mailing list