[Commotion-dev] Commotion R1 Changes
Dan Staples
danstaples at opentechinstitute.org
Thu Jan 16 19:15:40 UTC 2014
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
More information about the Commotion-dev
mailing list