[Commotion-dev] nailing down the default mesh network

Hans-Christoph Steiner hans at guardianproject.info
Fri May 3 14:50:54 UTC 2013


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
>>
>>
> 


More information about the Commotion-dev mailing list