[Commotion-dev] static BSSID?

[Hans-Christoph Steiner]

On May 17, 2012, at 11:05 AM, L. Aaron Kaplan wrote:

> 
> On May 13, 2012, at 3:57 AM, Josh King wrote:
> 
>> BSSID in an ad-hoc network definitely should be statically set in order 
>> to avoid network cell partitioning problems. I remember that hashing 
> 
> ACK!
> 
>> the SSID was a proposed solution for this in the madwifi driver, but I 
>> don't know if it was ever implemented (I vaguely recall some objection 
>> to this as a bad idea, but I cannot for the life of me find the 
>> reference to that argument, or think myself of why it might not be a 
>> good idea). In any event, there's an old patch posted for the madwifi 
>> driver that provides some sample code that could provide some guidance 
>> w/ respect to hashing:
>> 
> 
> One thing we came across in our Vienna testing days (which actually given a second thought is pretty obvious):
> different ESSIDs, same BSSID but different channels still results in some roque packets from the other channel to arrive at the network stack.
> 
> Therefore - for multi-channel setups - I'd recommend:
> * different channel implies different BSSIDs 
> * keep BSSIDs static
> 
> Most drivers can still cope with (different ESSID, same BSSID, same channel)
> However, some drivers are known to get confused in this setup.

Why would you want different ESSIDs on networks that share the BSSID?  As far as I know, the ESSID is just like the "domain name" and the BSSID is the actual address representing the network.  It seems to me that supporting encouraging multiple ESSIDs per BSSID would just confuse things.

.hc