Search Linux Wireless

Re: [PATCH v4] mac80211: keep sending peer candidate events while in listen state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 12, 2014 at 12:41:30PM +0100, Johannes Berg wrote:
> On Fri, 2014-11-21 at 11:24 +0000, Nishikawa, Kenzoh wrote:
> > Instead of sending peer candidate events just once, send them 
> > as long as the peer remains in the LISTEN state in the peering 
> > state machine, when userspace is implementing the peering manager.
> > Userspace may silence the events from a peer by progressing 
> > the state machine or by setting the link state to BLOCKED.
> > 
> > Fixes the problem that a mesh peering process won't be fired 
> > again after the previous first peering trial fails due to 
> > like air propagation error if the peering is managed by 
> > user space such as wpa_supplicant.
> > 
> > This patch works with another patch for wpa_supplicant described 
> > here which fires a peering process again triggered by the notice 
> > from kernel.
> > http://lists.shmoo.com/pipermail/hostap/2014-November/031235.html
> 
> Can any of the mesh folks comment on this?

I think it's fine.  It's not strictly necessary: userspace could
run its own timers to restart peering with any unpeered candidates
periodically, but doing it based on beacon arrival is a little better
since it indicates the peer is still alive, and this is also exactly
how the in-kernel MPM operates.

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux