Search Linux Wireless

Re: [PATCH 2/3] mac80211: reset TSF to 0 when joining a mesh

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

 



2013/12/17 Thomas Pedersen <twpedersen@xxxxxxxxx>:
> On Mon, Dec 16, 2013 at 1:55 PM, Sergey Ryazanov <ryazanov.s.a@xxxxxxxxx> wrote:
>> 2013/12/16 Thomas Pedersen <twpedersen@xxxxxxxxx>:
>>> On Mon, Dec 16, 2013 at 4:33 AM, Sergey Ryazanov <ryazanov.s.a@xxxxxxxxx> wrote:
>>>> Hello Thomas,
>>>>
>>>> 2013/12/16 Thomas Pedersen <twpedersen@xxxxxxxxx>:
>>>>> diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
>>>>> index 330d1f7..1174157 100644
>>>>> --- a/net/mac80211/mesh.c
>>>>> +++ b/net/mac80211/mesh.c
>>>>> @@ -802,6 +802,8 @@ int ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata)
>>>>>                 return -ENOMEM;
>>>>>         }
>>>>>
>>>>> +       /* next beacon will be DTIM-1, so TSF=0 was DTIM=0 */
>>>>> +       drv_set_tsf(local, sdata, 0);
>>>>>         ieee80211_bss_info_change_notify(sdata, changed);
>>>>>
>>>>>         netif_carrier_on(sdata->dev);
>>>>
>>>> What happen with AP interface on the same radio if we configure mesh
>>>> portal? Clients could be confused by such TSF jump.
>>>
>>> Like Johannes said; either the driver supports per-vif TSF, or well,
>>> it doesn't. Anyway wouldn't clients reset their own TSF when the new
>>> beacon is received?
>>>
>> Yeah, IEEE 802.11 says that stations must blindly use AP time, but it
>> says nothing about the situation when time is accidentally reset to
>> zero. I can't predict reaction of each chip/firmware/driver to such
>> situation.
>>
>> Another one unclear situation is the reaction of peers of mesh STA,
>> which share the same radio (and same TSF). If we silently reset its
>> time, what happens to the time synchronization with neighbors?
>
> Peer mesh STAs will notice an overly large TSF difference since last
> measurement, and reset Toffset to this new value.
>
Hm, I missed that. Thanks.

>> Why could not we calculate DTIM counter value on basis of known TSF
>> and Beacon/DTIM interval, instead of primitive time reset?
>
> Yeah this sounds like  a nicer solution. So drv_get_tsf() on mesh
> join, then calculate the right dtim_count? I'll give this a try.
>
I must confess that my question was inspired by Felix patch for ath9k
[1], which removes the TSF reset at each reconfiguration. Maybe we
could add the necessary functions to mac80211 or cfg80211 and all
drivers could benefit from that?

1. http://www.spinics.net/lists/linux-wireless/msg116087.html

-- 
BR,
Sergey
--
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