On Mon, Dec 16, 2013 at 1:55 PM, Sergey Ryazanov <[email protected]> wrote: > 2013/12/16 Thomas Pedersen <[email protected]>: >> On Mon, Dec 16, 2013 at 4:33 AM, Sergey Ryazanov <[email protected]> >> wrote: >>> Hello Thomas, >>> >>> 2013/12/16 Thomas Pedersen <[email protected]>: >>>> 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. > 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. Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
