On Feb 5, 2008 11:34 PM, Jouni Malinen <j@xxxxx> wrote: > On Sat, Feb 02, 2008 at 06:22:12PM -0500, Luis R. Rodriguez wrote: > > > problems. A solution to this we implemented at Orbit with MadWifi was > > that instead of generating "random" BSSIDs you'd create one based on > > the hash of the SSID [1]. This ensures that nodes with identical SSIDs > > end up with identical BSSIDs, regardless of any strange problems. > > How does that work with multiple channels? Good point. It never really accounted for it. This patch to MadWifi was just a hack to prevent IBSS split on a large grid, and should be treated as such. I would have to check with MadWifi but my guess here would be that we didn't see issue with channels as the channel selected would be a default and all the cards were using the same driver and hardware. > The patch did not seem to do > more than just use a very weak "hash" of the SSID to generate the BSSID. Indeed the hash is extremely weak. If we were to use something similar we'd have to consider a stronger hash, say maybe SHA1. > In other words, I would assume it leaves IBSS STAs on whatever channel > they end up selecting, i.e., in separate groups, unless all STAs are > forced to use the same channel by not allowing them to initialize the > IBSS on other channels. Yes I see your point, this is definitely an issue, unless of course the driver/stack is configured to default to use a specific channel by default. But regardless its a problem. > This would also likely require hardcoding the > STAs not to allow merging to other BSSIDs should there be any such > (i.e., any STA that does not implement this hack). Well the idea is that if it misses the timer from the leader it'll try to create the IBSS but will end up using the same BSSID as the leader would have, eventually causing a merge amongst the nodes. So you would not merge unless its with the same BSSID. > > Technically from what I have gathered this doesn't break the specs but > > would prevent this split-IBSS problem. I actually like to see this > > technique added into mac80211 too. > > > > [1] http://www.orbit-lab.org/wiki/HowTo/bssidFix > > I don't see how this alone would either prevent the split-IBSS problem I haven't run the test myself but I am informed this hack helps to try to solve the issue with 400 nodes on IBSS mode. > or be compliant with the IEEE 802.11 standard. The change in this patch > makes it likely to get same BSSID for different IBSS since the first six > octets of the SSID is used as the BSSID. That would not be very > desirable.. Agreed, the hash used is very weak, again its a hack but perhaps it can help find a better solution. AFAICT this is still an open problem. > Furthermore, it is unlikely to work well with STA > implementations that do not implement the identical mechanism for > generating the BSSID. Agreed, it definitely won't improve the situation in those cases, but with those that do it would at least help. > The BSSID generation as a hash from SSID does not sound like something > that would match the requirements of IEEE 802.11 11.1.6 ("a number > selected in a manner that minimizes the probability of STAs generating > the same number") since it is actually maximizing that probablity for > the case of same SSID ;-). Heh, good catch :) > As far as joining of separate STA groups in an IBSS (same SSID) is > concerned, 11.1.4 seems to indicate that the STA in IBSS shall adopt > _all_ parameters (i.e., also BSSID and channel) contained in the Beacon > frame when the Timestamp field of the received Beacon is later than the > STA's own TSF timer. This seems to be a requirement for supporting > merging of separate IBSS groups.. ACK > Actually hearing a Beacon from another > channel may be an issue, though, Broken? :) > but at least as far as separate groups > using different BSSIDs, but same SSID, on the same channel is concerned, > the merging behavior seems to be defined in the standard. ACK. Again, this seems like an open problem. We *could* take the channel into considering for the hash along with SSID... Anyway, good points! 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
