<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 30, 2012, at 1:32 AM, Teco Boot wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Op 29 jun. 2012, om 22:53 heeft Hans-Christoph Steiner het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 29, 2012, at 4:14 PM, Teco Boot wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Op 29 jun. 2012, om 21:11 heeft Hans-Christoph Steiner het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 29, 2012, at 2:58 PM, Teco Boot wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Op 29 jun. 2012, om 20:50 heeft Markus Kittenberger het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 8:40 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class="im"><br><div><div>On Jun 29, 2012, at 2:34 PM, Markus Kittenberger wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 8:25 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br><div><div>On Jun 29, 2012, at 1:57 PM, Markus Kittenberger wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 7:29 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Here's our idea for a standard algorithm for generating a static BSSID<br>
based on the SSID and the channel. Aaron suggested using the channel<br>
directly in the BSSID to lower the risk of conflicts. Basically,<br>
networks with the same BSSID on different channels will work, </blockquote><div>yes but many devices will actually connect to each other on such a setup.</div><div>of course with quite bad reception as the channel is wrong,</div>
<div><br></div><div>(in the lab with afair some bulelts this worked up to an offset of 15mhz!)</div><div><br></div><div>-> use different BSSID</div><div><br></div><div>Markus</div></div>
</blockquote></div><br></div></div><div>Do you have a suggestion how to do this in an algorithm? </div></div></blockquote><div>just encode the channel into the bssid<br><br><div>btw i just meant do not use the same bssid for different channels,..</div>
<div>(which is what aaron suggested to avoid conflicts) and which you comemnted, with "basically it would work"</div><div><br></div><div>so i felt it might be a good idea, to tell what kind of conflicts/issues you get with the same BSSID.</div>
<div><br></div><div>this btw is also a reason to NOT use the same CA:FE BA:BE bssid for different channels</div></div></div>
</blockquote><br></div></div><div>I'm confused. The proposal I sent already includes the channel in two bytes of the generated BSSID. Am I missing something?</div></div></blockquote><div>sry for casuing another confusion,..<br>
<br></div><div>i was not commetning on your bssid proposal, but on the statement that using the same bssid on different channels would work,..</div><div><br></div><div>as yes it works, but not really as one would expect,..</div>
<div><br></div><div>as most people do not expect that one router on channel 1 can (quite well) exchange data with another router on channel 2</div><div>or will have an very high ETX link in olsrd to another router on channel 3,..</div></div></blockquote><div><br></div><div>Users expect that nodes with same SSID do communicate.</div><div>I understand the bad link with neighbor channels.</div><div><br></div><div>Define SSID "olsr-(channel)", then the BSSID hash. Everybody happy...</div></div></div></blockquote><br></div><div>And when someone doesn't follow that rule, the system breaks. </div></div></blockquote><div>I thought the discussion was on good defaults...</div></div></div></blockquote></div></div></blockquote><div><br></div><div>I hope all of this in in olsrd-tools-(distribution), not in olsrd installer itself.</div><div>olsrd doesn't use 802.11 channels, SSID, BSSID or others sub-IP configs. It runs over sub-IP.</div><div>(but we need link metrics, for path calculation...).</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>So we can automatically include the channel in the algorithm and users don't have to think about it, nor people defining the SSID.</div></div></blockquote><div>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?</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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</div><div><br></div><div>- a roving group of people who work together with laptops and phones</div><div>- they work out of whatever space they can find</div><div>- they often move to different spaces</div><div>- they always use the same mesh id</div><div>- if they have internet at the space they are at, they share it via HNA</div><div>- if not, they still have the mesh between themselves, wherever they are</div><div><br></div><div>To make this work, we cannot reasonably expect people to follow technical rules when naming their SSID. </div></div></blockquote><div>???</div><div>I travel by train a lot, and see dozens of users handling network selection based on SSID.</div><div>If you create multiple network profiles, with same SSID, but with different channels/BSSID, people would get confused. At least I would.</div></div></div></blockquote><div><br></div></div>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.</div></blockquote><div>Yes, that is what the standard says.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> Wifi browsers don't handle this situation well, and I don't think we'll be able to either. </div></blockquote><div>Not agreed. Browsers are OK.</div><div>It is the one that comes up with same SSID, for different networks, that creates the problem.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> Let's say there are multiple open networks called 'linksys', </div></blockquote><div>All friendly neighbors, with open WiFi and high speed Internet access. Great!!!!</div><div>(new boxes have other factory settings, probably enforced by some countries)</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.</div></blockquote><div>Then, in my train, I have suddenly multiple entries in my SSID table, all for the same network.</div><div>Bad idea. Not as it is specified.</div><div><br></div><div>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. </div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>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.</div></div></blockquote><div>Now I am completely lost.</div><div>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?</div></div></div></blockquote><div><br></div><div>The problem is this: if you are talking about impromptu meshes based on IBSS assigned BSSIDs, then you can easily get into the situation where nodes try connecting to the same SSID but end up associating with different BSSIDs. For example, Android phones in a crowd all connect to the SSID 'flashmob' in a public square with the aim to join a single mesh. At one end, a phone randomly generates BSSID 02:02:02:02:02:02 and all the phones on that end associate to it. At the same time on the other end, another phone randomly generates BSSID ee:ee:ee:ee:ee:ee and all the phones on that end associate with that BSSID. As the mesh grows in the crowd, you have different BSSIDs and therefore different networks.</div><div><br></div><div>For this scenario, we need a given SSID and channel to always generate the same BSSID.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>OK, let's face some scenario's:</div><div>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.</div></div></div></blockquote><br></div><div>I think it would make sense to use different SSIDs there, certainly for the backbone.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>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.</div></div></div></blockquote><div><br></div><div>In terms of wifi, these would already be separate networks, so I see no harm is having them automatically get separate BSSIDs.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>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).</div></div></div></blockquote></div><br><div>Makes sense to me.</div><div><br></div><div>.hc</div></body></html>