[PATCH 4/4] hostapd: terminate hostapd when no channel is available
Mon Feb 17 02:18:49 PST 2014
> On Wed, Feb 05, 2014 at 06:10:10PM +0100, Simon Wunderlich wrote:
> > Until hostapd is able to restart service on a channel (e.g. by reacting
> > to an event that a DFS non-occupancy period is over), better shut down
> > hostapd when no channel is available anymore.
> > The current behaviour, disabling the interface, will just lead to
> > hostapd hanging without recovering frmo this state. If hostapd shuts
> > down, userspace can at least work around and restart hostapd when
> > channels are available again.
> Shutting down an interface sounds reasonable. Terminating the process
> does not, e.g., if there are multiple radios controlled by a single
> hostapd process.
Shutting down is not my preferred solution either, but at least that would be
consistent compared to starting hostap, which willl also terminate when no
channels are available.
It would be better to wait for the channel to become available again and
automatically re-select the channel. As explained in my cover mail, I don't
know how to do that since the disabled interface won't parse events anymore.
Therefore we can't react to the NOP event telling that a channel is usable
again - this is some kind of chicken-and-egg problem here. Do you have any
BTW, I don't know even think re-enabling the interface is possible via the
control interface, since the channel list update events lost and thus all
channels stay "blocked" in this case. (Haven't checked that though)
If you agree, please merge the the other patches (1-3/4). I'd love to find a
solution for the event problem explained above and send a proper patch for
More information about the Hostap