On Thursday 24 January 2008 02:22:26 Dan Williams wrote: > On Wed, 2008-01-23 at 15:48 +0100, Johannes Berg wrote: > > > enable IBSS cell merging. if an IBSS beacon with the same ESSID and a > > > TSF higher than the local TSF (mactime) is received, we have to join > > > its BSSID. > > > > Can you back that up with standard references? I see no such requirement > > in the standard text. I can see that under some circumstances this may > > be desirable, but maybe not. > > > > In fact, this seems to *break* standard behaviour, as per 11.1.3.1: > > (emphasis mine) > > The way I understood Ad-Hoc to work was that if you weren't using the > SSID + BSSID as somebody else, you weren't part of that adhoc network. > Ad-Hoc + roaming isn't supported and is even less defined, which is what > this patch would enable IIUC. i agree that you could call what my patch enables is roaming. but i think in IBSS mode this "roaming" has to happen in order to get IBSS mode working as the user would expect. if you configure 2 laptops in distance, say two different rooms and then move one of them into the other room you would expect to be able to communicate with the other laptop wouldn't you? > When joining an adhoc network, your > card/driver must scan around to find the SSID + (optionally) BSSID of > that adhoc network. If it finds one that matches criteria, it joins > that adhoc network, which means using the same BSSID. If it doesn't, it > creates a new adhoc network with a generated BSSID and the specified > SSID. > > If this patch were applied, then you'd pretty quickly get split adhoc > networks where some people were automatically moved to a different BSSID > and the rest are left on the old BSSID (maybe missed a beacon, or > whatever), and therefore can't talk to each other. actually i would argue that *without* this patch you will get split adhoc networks all the time (which is the reason i created the patch in the first place). please see my previous mail for some additional scenarios where this would happen. also please understand that merging in a city wide IBSS might seem like a crazy, irrelevant idea to you, but that is how IBSS mode is used in practice (too) and secondly it's just an example of similar odd cases that can also happen when you start an IBSS in a conference room with just a few participants. > If only because > mac80211 would jump adhoc BSSIDs, while all other drivers (including > fullmac parts) would not. that's not true. most other drivers, including fullmac drivers will join BSSIDs when the ESSID matches and the TSF is higher. > A cell is identified uniquely by the combination of BSSID + SSID, > nothing less. You don't combine infrastructure networks of the same > SSID and a different BSSID, nor does this happen for adhoc. sure you do that in infrastructure mode: any bigger infrastructure network will consist of several APs connected by ethernet and using different BSSIDs, with the same ESSID, allowing users to roam between them. as far as adhoc is concerned: yes, you shouldn't do that, and this is exactly what my patch is trying to achieve - only one BSSID for a given ESSID and channel (the one with the oldest TSF value). bruno - 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
