On Feb 5, 2008 11:34 PM, Jouni Malinen [off-list ref] wrote:

On Sat, Feb 02, 2008 at 06:22:12PM -0500, Luis R. Rodriguez wrote:

quoted

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.

quoted

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