[0.6.x PATCH] SIGUSR1 changes debug level

Kel Modderman kel
Mon Jan 21 07:10:52 PST 2008

On Sunday 09 December 2007 14:34:32 Jouni Malinen wrote:
> On Thu, Dec 06, 2007 at 04:45:17PM -0500, Dan Williams wrote:
> > So you don't have to respawn wpa_supplicant with different debug
> > options, or fire up a control interface or something.  Many *NIX
> > programs have this functionality; bring it to wpa_supplicant too.
> The functionality itself sounds fine, but use of SIGUSR1 in
> wpa_supplicant.c is not portable and that file needs to build for all
> targets. Furthermore, hostapd is already using SIGUSR1 for something
> else (state dump into a file) which would make this somewhat conflicting
> use of signals between hostapd and wpa_supplicant.
> > --- a/wpa_supplicant/wpa_supplicant.c
> >
> > @@ -1918,6 +1934,8 @@ int wpa_supplicant_run(struct wpa_global *global)
> >  	eloop_register_signal_terminate(wpa_supplicant_terminate, NULL);
> >  	eloop_register_signal_reconfig(wpa_supplicant_reconfig, NULL);
> >
> > +	eloop_register_signal(SIGUSR1, wpa_supplicant_handle_sigusr1, NULL);
> I added those eloop_register_signal_{terminate,reconfig}() functions to
> hide the signal (etc.) details into platform specific code (eloop*.c).
> Something similar would be needed for SIGUSR1. Though, I would rather
> not change eloop interface for 0.5.x, so this may end up only in 0.6.x
> branch.
> Another option would be to use ctrl_iface to change the debug level.
> That would have the extra benefit of being able to take in the exact
> debug level instead of just switching to another level. This sounds more
> useful to me since the caller would know what the end result is
> regardless of the current state. With just SIGUSR1 available, the caller
> would not really be able to tell whether the next signal will enable or
> disable debugging (or just change the level of already enabled
> debugging).

Could the existing "level" ctrl_iface command be made to manipulate both the 
verbosity of the attached client and the wpa_supplicant process too? Or is it 
best left to another distinct command?

Thanks, Kel.

More information about the Hostap mailing list