On 04/17/2018 03:04 PM, Jouni Malinen wrote:
On Wed, Jun 14, 2017 at 11:29:22AM -0700, greearb@xxxxxxxxxxxxxxx wrote:
I wanted a way to start wpa_cli, have it do the keep-alive ping,
and print events as they are received. I do not want an action file,
and I do not need interactive mode, and I want to run
this in a way where stdin may not be open.
So, introduce '-m' monitor mode.
wpa_cli -m -g /var/run/wpa_supplicant_if_wiphy0
This and the related (I'd assume) "wpa_cli: Don't buffer stdout." patch
were left in my queue for more consideration and I did not really ever
find time to go through the details before now.. It looks like this is
used to enable wpa_cli to be used by some other program to receive
wpa_supplicant messages. That sounds quite complex compared to simply
using wpa_ctrl.c or wpaspy.py (or similar implementation of socket
communication in other programming languages). I'm not really convinced
that wpa_cli should have such mode and instead, I'd recommend
implementing direct wpa_supplicant socket access in whatever the program
is that would be using this no-buffering-stdout from wpa_cli.
I do want to receive events, such as notification of when 4-way auth
completed so I could know when to start the dhcp client process ('iw event'
doesn't seem to offer an event for this, so that is why I was using
supplicant).
I don't want to poll, as that would be inefficient in my setup where I have
lots of virtual stations, so it seemed that wpa_cli in a monitor mode
would be a good option, and it seemed less work to tweak wpa_cli than
to re-write something similar.
Maybe I am missing your point, but how would I use wpa_ctrl.c or wpaspy.py in this
case?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
