[Commotion-dev] nailing down the default mesh network

Sat May 4 13:20:41 UTC 2013

Sounds like a natural role for OTI, if they are amenable, since OTI is also
steeped in policy.  Updating the official IEEE adhoc mode for mesh sounds very
valuable!

.hc

On 05/04/2013 06:24 AM, Paul Gardner-Stephen wrote:
> Hello,
> 
> We just ran out of money to stay involved in the process.  This was in
> large part due to the IEEE meetings mostly being in North America, while we
> are in Australia, within 2,000 miles of the antipode of most meetings.
>  This would be great to have another more local group come in and push for
> that and general fixing of ad-hoc Wi-Fi.
> 
> Paul.
> 
> 
> On Sat, May 4, 2013 at 12:20 AM, Hans-Christoph Steiner <
> hans at guardianproject.info> wrote:
> 
>>
>> Why did you stop pushing it? Was there resistance to the idea?
>>
>> .hc
>>
>> On 05/03/2013 12:48 AM, Paul Gardner-Stephen wrote:
>>> Hello,
>>>
>>> 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".
>>>
>>> Paul.
>>>
>>>
>>> On Fri, May 3, 2013 at 12:12 PM, Hans-Christoph Steiner <
>>> hans at guardianproject.info> wrote:
>>>
>>>>
>>>> Sean McIntyre and I developed an algorithm to generate the BSSID based
>> on
>>>> the
>>>> SSID and channel:
>>>>
>>>>
>>>>> Hey folks,
>>>>>
>>>>> Talked about this with Hans today. We came up with the following
>>>> algorithm:
>>>>>
>>>>> BSSID = MD4(ESSID)[0:4] ++ channel 2-byte integer
>>>>>
>>>>> This is read in English as: "The six byte BSSID is the first four
>>>>> bytes of the MD4 hash of ESSID concatenated with the lowest two bytes
>>>>> of the channel."
>>>>>
>>>>> The rationale for this is that MD4 is uniformly distributed, and the
>>>>> first four bytes of MD4 are presumably uniformly distributed. (Should
>>>>> be distributed enough.) Then add on the bytes of the channel so that
>>>>> same ESSIDs don't collide. MD4 was an arbitrary function choice, and
>>>>> security is not an issue.
>>>>>
>>>>> I found a public domain implementation of MD4
>>>>> <
>>>>
>> http://openwall.info/wiki/people/solar/software/public-domain-source-code/md4
>>>>>
>>>>> and made a simple get_bssid() function the same as the above algorithm
>>>>> (attached).
>>>>>
>>>>> Signature for get_bssid:
>>>>>
>>>>> get_bssid(char *essid, unsigned int channel, unsigned char *bssid) //
>>>>> (result goes in bssid)
>>>>>
>>>>> Not sure how to add this in, so hope one of you goes ahead and does
>>>>> that, or let me know how I can be of further service.
>>>>
>>>> Also, see the attached source code for Sean's implementation of it.
>>>>
>>>> .hc
>>>>
>>>>
>>>>
>>>> On 05/02/2013 02:32 AM, Teco Boot wrote:
>>>>> I prefer WiFi channels 1, 6 or 11 as a default.
>>>>>
>>>>> I prefer a true (pseudo-)random BSSID. Could be hash over SSID&channel.
>>>>>
>>>>> 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).
>>>>>
>>>>> Teco
>>>>>
>>>>> Op 1 mei 2013, om 22:17 heeft Hans-Christoph Steiner <
>>>> hans at guardianproject.info> het volgende geschreven:
>>>>>
>>>>>>
>>>>>> One idea that we discussed at the last dev sprint last Thursday/Friday
>>>> is
>>>>>> nailing down a default mesh profile that we can set everywhere.  The
>>>> core idea
>>>>>> is that people can use this as the easiest way to get started, and
>>>> also, it
>>>>>> can serve as the mesh config for impromptu meshing.
>>>>>>
>>>>>> Currently, we have been using this:
>>>>>>
>>>>>> SSID: commotionwireless.net
>>>>>> BSSID: 02:CA:FF:EE:BA:BE
>>>>>> Channel: 5
>>>>>> IP range: 5.0.0.0/255.0.0.0
>>>>>>
>>>>>> There are two issues that we need to address in order to nail down
>> this
>>>>>> default profile: a valid IP range, and perhaps a unique BSSID.
>>>>>>
>>>>>> 5.0.0.0/255.0.0.0 is an officially allocated block of IPs that is
>>>> actually
>>>>>> deployed in some places.  We should use an IP block that is officially
>>>>>> allocated for uses like Commotion intends.  We discussed this, and it
>>>> seems
>>>>>> like the best bet is to use one of the RFC1918 private network ranges
>>>> (10/8,
>>>>>> 172.16/12, and 192.168/16).  172.16.0.0-172.31.255.255 seems to be the
>>>> least
>>>>>> used of the three.  It privdes 1,048,576 unique IP addresses, so
>> plenty.
>>>>>>
>>>>>> We might want to consider using 100.64.0.0/10, which is reserved for
>>>> "carrier
>>>>>> grade NAT", i.e. a large scale NATed network that is attached to the
>>>> internet.
>>>>>>
>>>>
>> https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_Carrier_Grade_NAT_deployments
>>>>>>
>>>>>> The rules for using it are in RFC 6598:
>>>>>> https://tools.ietf.org/html/rfc6598
>>>>>>
>>>>>>
>>>>>> As for the BSSID, I think we should probably use a unique BSSID to
>>>> prevent
>>>>>> collisions with other mesh networks.  02:ca:ff:ee:ba:be is used by a
>>>> number of
>>>>>> other meshes.  It really could be any valid adhoc BSSID like
>>>> 02:02:02:02:02:02
>>>>>>
>>>>>> .hc
>>>>>> _______________________________________________
>>>>>> Commotion-dev mailing list
>>>>>> Commotion-dev at lists.chambana.net
>>>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> Commotion-dev mailing list
>>>> Commotion-dev at lists.chambana.net
>>>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>>>
>>>>
>>>
>>
> 