On Feb 6, 2008 10:52 PM, Jouni Malinen <j@xxxxx> wrote: > On Wed, Feb 06, 2008 at 01:33:31PM -0500, Luis R. Rodriguez wrote: > > > 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. > > It doesn't really help even if the driver/stack would be configured to > default to a specific channel. This has to work with other > implementations, too. Right, my point was just that if a stack was configured to try to use a channel by default when creating an IBSS and you'd end up with the same BSSID you'd eventually get a merge. But I see your point about interoperability and I think its key. > Hardcoding BSSID based on SSID may be fine for > most cases when a new IBSS is created, but still, the implementation > will need to allow this to be changed when merging with other parts of > the IBSS since those other parts may not implement this type of hack. I'm not quite sure I understand the problem here. The *key* feature of using some sort of a hash is just to guarantee the "random" BSSID you create matches that of the other stations using the same BSSID (and channel if channel is part of the hash as well as you suggest). What changes here is just the method for generation of the BSSID should no beacon be received yet for the SSID chosen. > I'm somewhat concerned about the possibility of getting the same BSSID > on different channels, though. Using the same BSSID for different groups > is not really a very good solution.. Including the channel number in the > hash data would resolve this concern. Sure. > > 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. > > I'm not completely what the "misses the timer from the leader" is > referring to or even what this "leader" would be in context of IBSS. > Anyway, the implementation has to merge regardless of what BSSID is used > (i.e., SSID match is enough). Oh well I mean the TSF becaon leader when in IBSS in the BSS during beacon generation. When in IBSS you have a node who has the greatest time for the TSF, this is what I call the leader. If a STA misses the "leader beacon" it'll generate its own beacon and may create a separate BSS. If however, you change the algorithm for picking the "random BSSID" and instead use some sort of hash based on desired SSID (and channel) you'd end up generating beacons for the same BSSID, eventually forcing a merge even if you missed the first few beacons from the TSF leader for the BSS. > > 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. > > Sure, if you can control all the STAs in the IBSS. That just is not the > case in general and Linux wireless stack must not be designed with the > view point of all STAs following the exact same rules (unless those > rules are based on a required standard behavior).. Agreed that we shouldn't assume everyone will have the same hacks, and that we should focus on interoperability but I am wondering how this could break things. All that would be changed here is the algorithm for BSSID generation, instead of using a random BSSID you'd use one as a hash of say SSID and channel. Can you think of issues with interoperability with STAs who choose a random BSSID generator instead of a hash other than those using a hash being able to guarantee sticking to the same BSSID ? > Taken into account that we should really implement proper IBSS merge to > allow interoperation with non-mac80211 implementations, I don't know how > much of a benefit this BSSID=hash(SSID,chan) mechanism would really > provide. It simply would solve the IBSS split issue, which can be caused by several reasons, until that is solved within the standard or someone thinks of a better solution. > If it can be shown that the IBSS merges in a large network are > not stable, Oh we have proof for this :) and we also have proof of how using a hash helps correct it, of course, as hack. I'll try to see if we can come up with something a bit more formal I guess. > this could of course be helpful and I don't think I would > object it as long as the BSSID is going to end up being same only on the > same channel and the mac80211 implementation allows the BSSID to be > changed if a Beacon frame is received with a larger timestamp value than > the local TSF timer. Respecting the higher TSF is not affected, all that would be changed would be the algorithm used for generating the BSSID. Once we have IBSS merge on mac80211 I'll then test a patch for this on the 40x40 grid with ath5k and let you know how it goes. I'll try to use two BSSes, each on a separate channel. Not sure yet what topology to use. 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
