On Mon, Feb 11, 2008 at 9:00 PM, bruno randolf <bruno@xxxxxxxxxxxxx> wrote: > > On Friday 08 February 2008 18:22:52 Luis R. Rodriguez wrote: > > On Feb 6, 2008 10:58 PM, Jouni Malinen <j@xxxxx> wrote: > > > On Wed, Feb 06, 2008 at 03:10:35PM -0500, John W. Linville wrote: > > > > FWIW, that wouldn't be the first time we (i.e. Linux) chose to do > > > > something that did not completely comply with a standard. If it > > > > interoperates with other equipment and is good for users, I don't > > > > think picky standard compliance is worthwhile. > > > > > > Sure, there are cases where this is reasonable. > > > > > > > Please note that I am not really taking a stand in favor of this ATM, > > > > only asserting that blind standard compliance is not a good reason > > > > to NAK it IMHO. > > > > > > In this case, standard compliance is certainly not the only concern I > > > have. I'm worried about interoperability with non-mac80211 > > > implementations. If mac80211 were to hardcoded the BSSID for IBSS and > > > refuse to change it no matter what (i.e., behave against the IEEE 802.11 > > > standard), IBSS would not interoperate with any other implementation if > > > the other implementation happens to be the creator of the IBSS.. > > > > OK so you're saying that some people might actually expect that when > > using the same SSID and same channel in close vicinity they'd get > > separate BSSIDs generated? If so I don't see why people would expect > > this functionality as a feature, I think this is more of a problem > > than an expected result of how the standard is designed. > > > > > Same issues shows up (but in somewhat less frequent form) in an IBSS > > > splitting up and re-joining. In order to allow the STAs using other > > > implementation (no BSSID hacks) to join the IBSS, mac80211 will need to > > > be prepared to change the BSSID (or use some much more questionable > > > hacks to make sure it is always the mac80211-STA that wins in the > > > selection of which BSSID will survive.. ;-). > > > > How would the IBSS be split up to generate a new BSSID? If you are > > part of an IBSS and you don't see anyone generate a beacon between the > > random backoff time you simply generate it, but the BSSID would still > > be the same. > > i think the point here is that we still need to be prepared to merge IBSS > (i.e. switch to another BSSID when we receive a beacon with an older TSF) no > matter how we generate our own BSSID in the first place. Well that is still possible. > using a hash of the BSSID and channel would reduce the necessity to merge IBSS > for mac80211 drivers but we still need to be able to join older IBSS from > other drivers. Sure, how is it that this prevents that? Luis - 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
