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

[Teco Boot]

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

> 
> On Jun 29, 2012, at 4:14 PM, Teco Boot wrote:
> 
>> 
>> 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...

I hope all of this in in olsrd-tools-(distribution), not in olsrd installer itself.
olsrd doesn't use 802.11 channels, SSID, BSSID or others sub-IP configs. It runs over sub-IP.
(but we need link metrics, for path calculation...).

>>> 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.
> 
> Ah I see, that is the flip side of more or less the same question.  Users see the same SSID and think they are all the same network, regardless of channel.
Yes, that is what the standard says.

>  Wifi browsers don't handle this situation well, and I don't think we'll be able to either.
Not agreed. Browsers are OK.
It is the one that comes up with same SSID, for different networks, that creates the problem.

>  Let's say there are multiple open networks called 'linksys',
All friendly neighbors, with open WiFi and high speed Internet access. Great!!!!
(new boxes have other factory settings, probably enforced by some countries)

> the Mac OS X wifi browser, for example, will just show one network called 'linksys', since it assumes they are different APs on the same network.  If we have a mesh browser, I suppose we could show each SSID as a separate listing based on which channel they are on.
Then, in my train, I have suddenly multiple entries in my SSID table, all for the same network.
Bad idea. Not as it is specified.

But you have a point, some pieces are missing. For example, an SSID is for a L2 network. When nodes roam within same SSID, they may keep the L3 (DHCP) state. 

> 
> The flip side is users create a network and just want to choose a unique name, and don't want to have to read a spec to name their SSID.  Since we are aiming at non-technical users, then we cannot assume they even know that they should look at some spec before naming the network.
Now I am completely lost.
Users create an IBSS, have a unique SSID. A channel is selected, often the default 1. A (unique) BSSID is selected. What is the problem?

OK, let's face some scenario's:
1) a large olsr network (say SSID is olsr), with backbone and access nodes. Access nodes advertise their existence on multiple channels, say 2.4 and 5GHz. "clients" connect to one of the channels, and may extend the network if they are a router.
2) multiple olsr networks (again, SSID is olsr), started on different channels. Question is, should this be two separate networks? Or is it "to be repaired", by a dual channel node? After it is repaired, we are back to first scenario. Before, the networks are isolated. BSSID setting doesn't matter a lot.

My opinion on this: the IEEE802.11 spec should have specified that BSSID for IBSS is a hashed SSID. This would have prevented many bugs. More important, beacons can be eliminated (ahdemo).

Teco

 
> .hc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120630/8112007f/attachment.html>