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