<div dir="ltr">Hello,<div><br></div><div>Deterministic BSSID generation is a good thing, and we did briefly try to push this general idea into the 802.11 working group in the IEEE.  It great advantages in reducing the possibility for cell splits which are a real nuisance with ad-hoc as currently "standardized".</div>
<div><br></div><div style>Paul.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 3, 2013 at 12:12 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>
Sean McIntyre and I developed an algorithm to generate the BSSID based on the<br>
SSID and channel:<br>
<br>
<br>
> Hey folks,<br>
><br>
> Talked about this with Hans today. We came up with the following algorithm:<br>
><br>
> BSSID = MD4(ESSID)[0:4] ++ channel 2-byte integer<br>
><br>
> This is read in English as: "The six byte BSSID is the first four<br>
> bytes of the MD4 hash of ESSID concatenated with the lowest two bytes<br>
> of the channel."<br>
><br>
> The rationale for this is that MD4 is uniformly distributed, and the<br>
> first four bytes of MD4 are presumably uniformly distributed. (Should<br>
> be distributed enough.) Then add on the bytes of the channel so that<br>
> same ESSIDs don't collide. MD4 was an arbitrary function choice, and<br>
> security is not an issue.<br>
><br>
> I found a public domain implementation of MD4<br>
> <<a href="http://openwall.info/wiki/people/solar/software/public-domain-source-code/md4" target="_blank">http://openwall.info/wiki/people/solar/software/public-domain-source-code/md4</a>><br>
> and made a simple get_bssid() function the same as the above algorithm<br>
> (attached).<br>
><br>
> Signature for get_bssid:<br>
><br>
> get_bssid(char *essid, unsigned int channel, unsigned char *bssid) //<br>
> (result goes in bssid)<br>
><br>
> Not sure how to add this in, so hope one of you goes ahead and does<br>
> that, or let me know how I can be of further service.<br>
<br>
Also, see the attached source code for Sean's implementation of it.<br>
<span class="HOEnZb"><font color="#888888"><br>
.hc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 05/02/2013 02:32 AM, Teco Boot wrote:<br>
> I prefer WiFi channels 1, 6 or 11 as a default.<br>
><br>
> I prefer a true (pseudo-)random BSSID. Could be hash over SSID&channel.<br>
><br>
> I'm afraid there is no ideal solution for addressing. Short term: some v4 space. More fundamental: auto-generated IPv6 ULA and with support for v4 traffic. With IPv6, multi-homing with multi-path is much easier to implement (routing based on source address).<br>

><br>
> Teco<br>
><br>
> Op 1 mei 2013, om 22:17 heeft Hans-Christoph Steiner <<a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>> het volgende geschreven:<br>
><br>
>><br>
>> One idea that we discussed at the last dev sprint last Thursday/Friday is<br>
>> nailing down a default mesh profile that we can set everywhere.  The core idea<br>
>> is that people can use this as the easiest way to get started, and also, it<br>
>> can serve as the mesh config for impromptu meshing.<br>
>><br>
>> Currently, we have been using this:<br>
>><br>
>> SSID: <a href="http://commotionwireless.net" target="_blank">commotionwireless.net</a><br>
>> BSSID: 02:CA:FF:EE:BA:BE<br>
>> Channel: 5<br>
>> IP range: <a href="http://5.0.0.0/255.0.0.0" target="_blank">5.0.0.0/255.0.0.0</a><br>
>><br>
>> There are two issues that we need to address in order to nail down this<br>
>> default profile: a valid IP range, and perhaps a unique BSSID.<br>
>><br>
>> <a href="http://5.0.0.0/255.0.0.0" target="_blank">5.0.0.0/255.0.0.0</a> is an officially allocated block of IPs that is actually<br>
>> deployed in some places.  We should use an IP block that is officially<br>
>> allocated for uses like Commotion intends.  We discussed this, and it seems<br>
>> like the best bet is to use one of the RFC1918 private network ranges (10/8,<br>
>> 172.16/12, and 192.168/16).  172.16.0.0-172.31.255.255 seems to be the least<br>
>> used of the three.  It privdes 1,048,576 unique IP addresses, so plenty.<br>
>><br>
>> We might want to consider using <a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a>, which is reserved for "carrier<br>
>> grade NAT", i.e. a large scale NATed network that is attached to the internet.<br>
>> <a href="https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_Carrier_Grade_NAT_deployments" target="_blank">https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_Carrier_Grade_NAT_deployments</a><br>

>><br>
>> The rules for using it are in RFC 6598:<br>
>> <a href="https://tools.ietf.org/html/rfc6598" target="_blank">https://tools.ietf.org/html/rfc6598</a><br>
>><br>
>><br>
>> As for the BSSID, I think we should probably use a unique BSSID to prevent<br>
>> collisions with other mesh networks.  02:ca:ff:ee:ba:be is used by a number of<br>
>> other meshes.  It really could be any valid adhoc BSSID like 02:02:02:02:02:02<br>
>><br>
>> .hc<br>
>> _______________________________________________<br>
>> Commotion-dev mailing list<br>
>> <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
>> <a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
><br>
</div></div><br>_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
<br></blockquote></div><br></div>