On Jan 25, 2008 3:01 AM, bruno randolf [off-list ref] wrote:

On Friday 25 January 2008 01:55:04 Johannes Berg wrote:

quoted

quoted

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...

quoted

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 think it's a reasonable expectation from a users point of view that two or
more IBSS nodes using the same ESSID on the same channel can communicate with
each other, regardless of when and where they were configured.

quoted

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.

this is probably a valid, but a most conservative interpretation of the
standard, which makes IBSS practically unusable in many (or most) occasions.

i guess you have never actually used IBSS much. otherwise you would know from
experience that your simplest use case practically rarely happens. usually
you have situations where you miss the others BSS while scanning and end up
with 2 different BSSIDs. or what happens if there is a third station within
station 2's reach but out of range for station 1? sta2 will adopt the BSSID
of sta3, but sta1 will not and start a new BSSID. so not even your simplest
use case of two newly started stations will just work (without ibss merge).
examples and scenarios are endless, do you want me to continue? ;)

also i am not inventing this "non-standard merge". it is *not* non-standard,
it's just not directly obvious from reading the standard.

IBSS merges are done like this by various cards and drivers: prism54 does the
same (in firmware), hostap driver did it like this (probably does but i
haven't used it in quite a while), the broadcom driver in openwrt acts like
this, madwifi merges like this (ups, maybe i shouldn't have said that ;)) and
so on...

aren't there any other serious IBSS users out there who can support this case
and confirm that we need IBSS merge functionality?

Sure ACK. Also as was stated, even with IBSS merge functionality
working you could up with nodes splitting up due to missing the
"leader" beacon due to interference or even strange radio node
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.
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

  Luis