[Commotion-dev] nailing down the default mesh network

Sat May 4 16:14:41 UTC 2013

Hello,

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.

Paul.

On Sat, May 4, 2013 at 10:50 PM, Hans-Christoph Steiner <
hans at guardianproject.info> wrote:

>
> 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
> >>>>
> >>>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130505/646aa285/attachment.html>