[Commotion-dev] Commotion R1 Changes
Ben West
ben at gowasabi.net
Thu Jan 16 20:19:21 UTC 2014
Sorry for cluttering the discuss listserv with technobabble!
A RADIUS server would indeed help play the role of coordinating clients
across all APs/hotspots in a mesh. It does add a fair bit of complexity,
along with a central point of control that a bit adverse to meshing
topology. I looking more at simple distributed methods to assist client
roaming (e.g. sharing lists of client MACs/ lease IPs between nodes). For
a particular client connected to a particular node, it's probably safe to
assume that only that node's immediate neighbors need to know about that
client's potential to roam.
Since the decision about whether to roam is made entirely by the client,
just having several nodes/APs broadcast the same SSID, even across
different channels, should be enough for many clients to roam. This mode
of operation (i.e. all nodes broadcast the same SSID for their public AP),
was explicitly encouraged with the old ROBIN firmware, although it was
acknowledged that some clients might not be intelligent enough to
automatically refresh their DHCP lease upon association with the new node.
Having clients issued a unique IP in their DHCP lease regardless of node
would at least remove that problem.
Also, the UniFi java-based controller pulls off client roaming, without
needing a central authentication arbiter like a RADIUS server, by depending
on a central DHCP server and also by having APs broadcast the same SSID.
However, since the UniFi firmware is closed source, it could also be using
some fancy 802.11 extensions to assist roaming.
The SMesh project looks like it wants to take seamless roaming a step
further. I.e. in addition to the layer 2 / layer 3 handoff we're
discussing, also preserve a client's open connections. Cool!
On Thu, Jan 16, 2014 at 1:15 PM, Dan Staples <
danstaples at opentechinstitute.org> wrote:
> Moving to dev list only, since discussion is getting technical.
>
> When I was doing some brief research on wifi handover a while ago, it
> seemed the most common way of doing it used some 802.11 extensions
> (don't remember the letters), and a central RADIUS server for
> coordinating clients and handoffs between APs. So that seems like a way
> to do it.
>
> Another alternative I was looking at is called SMesh
> (http://www.smesh.org/). It also does coordination of client handover,
> but using a multicast group instead of a central coordinating node. The
> details are here:
> http://www.cnds.jhu.edu/pub/papers/smesh_tocs_accepted_version.pdf. I
> think it would be worth experimenting with this.
>
> Although I have been told that Batman-Adv does seamless client handover
> due to it being a layer 2 mesh routing protocol. Haven't tried that
> myself though.
>
>
> On 01/16/2014 01:04 PM, Ben West wrote:
> > Issuing clients a unique IP in the 10.x.x.x space, regardless of the
> > specific node associated with, could possibly let client roaming occur
> > more smoothly. Giving clients their own unique IPs seems like it would
> > be the logical extension of bridging all client subnets, right?
> > Likewise, this could work toward eliminating some of the layers of NAT
> > within the mesh and lay groundwork for NAT-free ipv6?
> >
> > At any rate, issuing clients unique IPs is actually what is done in many
> > conventional hotspots deployments with multiple APs, whereby the APs
> > (all broadcasting the SSID) are wired back to a central router that
> > issues DHCP leases to all clients. That is, Ubiquiti UniFi operates
> > like this, and I think even the batman-adv routing in Cloudtrax nodes
> > use may also do this now, too.
> >
> > For meshing nodes, some non-trivial parts of smooth client roaming would
> > be factors like ...
> >
> > 0. When a client roams from node A to node B, how to reliably detect
> > that event and react to it immediately. hostapd does write to syslog
> > when a new client associates. Nodes could poll hostapd via syslog or
> > via wpa_cli to discover when a new client associates. Or there is
> > possibly a more elegant way to trigger an action upon new client
> > association which I haven't found yet.
> >
> > 1. When a client roams from node A to node B, while retaining client IP,
> > how to inform node B to begin routing traffic from that client.
> >
> > 2. When a client roams from node A to node B, how to inform node B's
> > captive portal to /not/ redirect the client to the splash page. Similar
> > to #1, this could also be accomplished with nodes sharing the list of
> > active client MACs (perhaps also with an incrementing session time for
> > each client), so that incoming roaming clients don't get bounced back to
> > the splash page. Or, such a list could be used so that every client
> > /does/ get bounced back to the splash page, regardless of how many nodes
> > he has roamed to, after some operator-defined timeout has elapsed.
> >
> >
> >
> > On Thu, Jan 16, 2014 at 11:05 AM, Dan Staples
> > <danstaples at opentechinstitute.org
> > <mailto:danstaples at opentechinstitute.org>> wrote:
> >
> > We actually hadn't considered that since the access point handover
> is a
> > pretty large project for down the line. It was more for the sake of
> > simplicity, IIRC.
> >
> > Handover aside, I also don't think retaining a client IP address
> would
> > be possible without some restructuring, since the 10.0.0.0/8
> > <http://10.0.0.0/8> client
> > subnet on each router is chosen to be unique (in order to avoid
> > collision), i.e. the router assigns client IP addresses on the
> > 10.a.b.0/24 range, where a and b correspond to the last two bytes of
> the
> > router's MAC address.
> >
> > But it's still worth considering. Do you think retaining client IP
> > addresses would provide some benefits, as opposed to just getting a
> new
> > IP address when switching APs?
> >
> > Dan
> >
> > On 01/16/2014 10:20 AM, Ben West wrote:
> > > All of the addressing changes look like great ideas.
> > >
> > > Question: is the decision to address all clients within the address
> > > space 10.0.0.0/8 <http://10.0.0.0/8> <http://10.0.0.0/8> to, among
> > other things, help make
> > > client roaming between nodes easier? I.e. implying that clients
> would
> > > be assigned the same IP regardless of which node they associate
> with?
> > >
> > > I noticed this item filed in the feature queue just now:
> > > https://github.com/opentechinstitute/commotion-router/issues/87
> > >
> > >
> > > On Fri, Jan 10, 2014 at 4:52 PM, Dan Staples
> > > <danstaples at opentechinstitute.org
> > <mailto:danstaples at opentechinstitute.org>
> > > <mailto:danstaples at opentechinstitute.org
> > <mailto:danstaples at opentechinstitute.org>>> wrote:
> > >
> > > Developers and network maintainers might want to check out our
> > blog post
> > > on significant backwards-imcompatible changes in the R1
> release:
> > >
> https://commotionwireless.net/blog/commotion-r1-breaking-changes
> > >
> > > In summary:
> > > * Mesh IP addresses are now self-assigned in the 100.64.0.0/10
> > <http://100.64.0.0/10>
> > > <http://100.64.0.0/10> range and
> > > all client subnets are bridged and assigned addresses in the
> > > 10.0.0.0/8 <http://10.0.0.0/8> <http://10.0.0.0/8>
> > > range
> > > * default adhoc SSID and channel were removed
> > > * adhoc BSSID is now deterministically generated based on hash
> > of SSID
> > > and channel
> > >
> > > The blog post explains the details and reasoning behind these
> > changes,
> > > for those that are interested, and also includes info on
> upgrading
> > > pre-R1 Commotion networks.
> > >
> > > You can also find R1 release notes here:
> > >
> > https://commotionwireless.net/blog/commotion-router-v1-release-notes
> > >
> > > cheers,
> > > Dan
> > >
> > > --
> > > Dan Staples
> > >
> > > Open Technology Institute
> > > https://commotionwireless.net
> > > OpenPGP key: http://disman.tl/pgp.asc
> > > Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9
> > > _______________________________________________
> > > Commotion-dev mailing list
> > > Commotion-dev at lists.chambana.net
> > <mailto:Commotion-dev at lists.chambana.net>
> > > <mailto:Commotion-dev at lists.chambana.net
> > <mailto:Commotion-dev at lists.chambana.net>>
> > > https://lists.chambana.net/mailman/listinfo/commotion-dev
> > >
> > >
> > >
> > >
> > > --
> > > Ben West
> > > http://gowasabi.net
> > > ben at gowasabi.net <mailto:ben at gowasabi.net>
> > <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
> > > 314-246-9434 <tel:314-246-9434>
> >
> > --
> > Dan Staples
> >
> > Open Technology Institute
> > https://commotionwireless.net
> > OpenPGP key: http://disman.tl/pgp.asc
> > Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9
> >
> >
> >
> >
> > --
> > Ben West
> > http://gowasabi.net
> > ben at gowasabi.net <mailto:ben at gowasabi.net>
> > 314-246-9434
>
> --
> Dan Staples
>
> Open Technology Institute
> https://commotionwireless.net
> OpenPGP key: http://disman.tl/pgp.asc
> Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>
>
--
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20140116/6cf2c6c0/attachment.html>
More information about the Commotion-dev
mailing list