[Commotion-dev] nailing down the default mesh network

Fri May 3 02:42:02 UTC 2013

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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: get_bssid.tar.bz2
Type: application/x-bzip
Size: 3569 bytes
Desc: not available
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130502/e4bce256/attachment.bin>