<div dir="ltr">Hello,<div><br></div><div>Yes, this would be great if OTI could take up the baton on this.  If anyone is interested in doing so, we can provide some hand-over for where we got to etc.  The working group were positive about the BSSID from hash of SSID approach, as I recall.</div>
<div><br></div><div>Paul.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 4, 2013 at 10:50 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>
Sounds like a natural role for OTI, if they are amenable, since OTI is also<br>
steeped in policy.  Updating the official IEEE adhoc mode for mesh sounds very<br>
valuable!<br>
<span class="HOEnZb"><font color="#888888"><br>
.hc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 05/04/2013 06:24 AM, Paul Gardner-Stephen wrote:<br>
> Hello,<br>
><br>
> We just ran out of money to stay involved in the process.  This was in<br>
> large part due to the IEEE meetings mostly being in North America, while we<br>
> are in Australia, within 2,000 miles of the antipode of most meetings.<br>
>  This would be great to have another more local group come in and push for<br>
> that and general fixing of ad-hoc Wi-Fi.<br>
><br>
> Paul.<br>
><br>
><br>
> On Sat, May 4, 2013 at 12:20 AM, Hans-Christoph Steiner <<br>
> <a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>> wrote:<br>
><br>
>><br>
>> Why did you stop pushing it? Was there resistance to the idea?<br>
>><br>
>> .hc<br>
>><br>
>> On 05/03/2013 12:48 AM, Paul Gardner-Stephen wrote:<br>
>>> Hello,<br>
>>><br>
>>> Deterministic BSSID generation is a good thing, and we did briefly try to<br>
>>> push this general idea into the 802.11 working group in the IEEE.  It<br>
>> great<br>
>>> advantages in reducing the possibility for cell splits which are a real<br>
>>> nuisance with ad-hoc as currently "standardized".<br>
>>><br>
>>> Paul.<br>
>>><br>
>>><br>
>>> On Fri, May 3, 2013 at 12:12 PM, Hans-Christoph Steiner <<br>
>>> <a href="mailto:hans@guardianproject.info">hans@guardianproject.info</a>> wrote:<br>
>>><br>
>>>><br>
>>>> Sean McIntyre and I developed an algorithm to generate the BSSID based<br>
>> on<br>
>>>> the<br>
>>>> SSID and channel:<br>
>>>><br>
>>>><br>
>>>>> Hey folks,<br>
>>>>><br>
>>>>> Talked about this with Hans today. We came up with the following<br>
>>>> 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>
>>>>> <<br>
>>>><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>
>>>>><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>
>>>><br>
>>>> .hc<br>
>>>><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<br>
>>>> v4 space. More fundamental: auto-generated IPv6 ULA and with support<br>
>> for v4<br>
>>>> traffic. With IPv6, multi-homing with multi-path is much easier to<br>
>>>> implement (routing based on source address).<br>
>>>>><br>
>>>>> Teco<br>
>>>>><br>
>>>>> Op 1 mei 2013, om 22:17 heeft Hans-Christoph Steiner <<br>
>>>> <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<br>
>>>> is<br>
>>>>>> nailing down a default mesh profile that we can set everywhere.  The<br>
>>>> core idea<br>
>>>>>> is that people can use this as the easiest way to get started, and<br>
>>>> 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<br>
>> 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<br>
>>>> 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<br>
>>>> seems<br>
>>>>>> like the best bet is to use one of the RFC1918 private network ranges<br>
>>>> (10/8,<br>
>>>>>> 172.16/12, and 192.168/16).  172.16.0.0-172.31.255.255 seems to be the<br>
>>>> least<br>
>>>>>> used of the three.  It privdes 1,048,576 unique IP addresses, so<br>
>> 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<br>
>>>> "carrier<br>
>>>>>> grade NAT", i.e. a large scale NATed network that is attached to the<br>
>>>> internet.<br>
>>>>>><br>
>>>><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<br>
>>>> prevent<br>
>>>>>> collisions with other mesh networks.  02:ca:ff:ee:ba:be is used by a<br>
>>>> number of<br>
>>>>>> other meshes.  It really could be any valid adhoc BSSID like<br>
>>>> 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>
>>>><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>
>>>><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>