> i can see now how you could interpret this as only applying to timers, but i > think that does just not make sense - why would you want to sync timers and > adapt beacon intervals if you don't share the same BSSID? Hmm. Well I thought that was pretty much just for optimising performance but now that I think about it again... > i agree that the standard is quite ambigious when it comes to IBSS, but > practically speaking, it is necessary to merge IBSS cells most of the time if > you want to have IBSS working as expected. therefore i tend to interpret the > ambigious parts of the standard in a way that will improve functionality. I think "working as expected" is stretching it a bit ;) How do you expect IBSS to work? I'd expect only the simplest use case from it: start IBSS on one station and have another one in the vicinity find it while scanning and join it. That works regardless of merging or not. > please see my last post where i suggest to use: > > + if (rx_status->flag & RX_FLAG_TSFT) > + /* in order for correct IBSS merging we need mactime*/ > + mactime = rx_status->mactime; > + else if (local && local->ops && local->ops->get_tsf) > + /* second best option: get current TSF */ > + mactime = local->ops->get_tsf(local_to_hw(local)); > + else > + /* can't merge without knowing the TSF */ > + mactime = -1LLU; > > instead. Not sure. That's a bit on a fine line, if you have a slow device get_tsf() might be well off and this could trigger a BSSID change in both stations. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
