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? Why could not we calculate DTIM counter value on basis of known TSF and Beacon/DTIM interval, instead of primitive time reset? -- 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
