[Olsr-dev] algorithm to generate BSSID from SSID and channel

[Teco Boot]

Op 29 jun. 2012, om 21:11 heeft Hans-Christoph Steiner het volgende geschreven:

> 
> On Jun 29, 2012, at 2:58 PM, Teco Boot wrote:
> 
>> 
>> Op 29 jun. 2012, om 20:50 heeft Markus Kittenberger het volgende geschreven:
>> 
>>> 
>>> 
>>> On Fri, Jun 29, 2012 at 8:40 PM, Hans-Christoph Steiner <(spam-protected)> wrote:
>>> 
>>> On Jun 29, 2012, at 2:34 PM, Markus Kittenberger wrote:
>>> 
>>>> 
>>>> 
>>>> On Fri, Jun 29, 2012 at 8:25 PM, Hans-Christoph Steiner <(spam-protected)> wrote:
>>>> 
>>>> On Jun 29, 2012, at 1:57 PM, Markus Kittenberger wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Jun 29, 2012 at 7:29 PM, Hans-Christoph Steiner <(spam-protected)> wrote:
>>>>> 
>>>>> Here's our idea for a standard algorithm for generating a static BSSID
>>>>> based on the SSID and the channel.  Aaron suggested using the channel
>>>>> directly in the BSSID to lower the risk of conflicts.  Basically,
>>>>> networks with the same BSSID on different channels will work,
>>>>> yes but many devices will actually connect to each other on such a setup.
>>>>> of course with quite bad reception as the channel is wrong,
>>>>> 
>>>>> (in the lab with afair some bulelts this worked up to an offset of 15mhz!)
>>>>> 
>>>>> -> use different BSSID
>>>>> 
>>>>> Markus
>>>> 
>>>> Do you have a suggestion how to do this in an algorithm?
>>>> just encode the channel into the bssid
>>>> 
>>>> btw i just meant do not use the same bssid for different channels,..
>>>> (which is what aaron suggested to avoid conflicts) and which you comemnted, with "basically it would work"
>>>> 
>>>> so i felt it might be a good idea, to tell what kind of conflicts/issues you get with the same BSSID.
>>>> 
>>>> this btw is also a reason to NOT use the same CA:FE BA:BE bssid for different channels
>>> 
>>> I'm confused.  The proposal I sent already includes the channel in two bytes of the generated BSSID.  Am I missing something?
>>> sry for casuing another confusion,..
>>> 
>>> i was not commetning on your bssid proposal, but on the statement that using the same bssid on different channels would work,..
>>> 
>>> as yes it works, but not really as one would expect,..
>>> 
>>> as most people do not expect that one router on channel 1 can (quite well) exchange data with another router on channel 2
>>> or will have an very high ETX link in olsrd to another router on channel 3,..
>> 
>> Users expect that nodes with same SSID do communicate.
>> I understand the bad link with neighbor channels.
>> 
>> Define SSID "olsr-(channel)", then the BSSID hash. Everybody happy...
> 
> And when someone doesn't follow that rule, the system breaks.  
I thought the discussion was on good defaults...

> So we can automatically include the channel in the algorithm and users don't have to think about it, nor people defining the SSID.
People can start or join a network. If you want to define a profile for a network, with SSID and channel, and thus the BSSID, what is wrong with distinct SSIDs for distinct networks?

> We're pushing to make it common for people to make their own local meshes.  For example, here's one scenario we are targetting: the Cairo protest organizers
> 
> - a roving group of people who work together with laptops and phones
> - they work out of whatever space they can find
> - they often move to different spaces
> - they always use the same mesh id
> - if they have internet at the space they are at, they share it via HNA
> - if not, they still have the mesh between themselves, wherever they are
> 
> To make this work, we cannot reasonably expect people to follow technical rules when naming their SSID. 
???
I travel by train a lot, and see dozens of users handling network selection based on SSID.
If you create multiple network profiles, with same SSID, but with different channels/BSSID, people would get confused. At least I would.

Teco

> 
> .hc
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120629/57501ecd/attachment.html>