[Commotion-dev] Commotion R1 Changes
Dan Staples
danstaples at opentechinstitute.org
Thu Jan 16 21:21:00 UTC 2014
Good point. They use WRT54G as their testing hardware, so at least a
router of that capacity can handle it. But whether it can handle that
*plus* all the stuff we run on Commotion...well, we'll just have to see :)
On 01/16/2014 03:38 PM, Ben West wrote:
> Inline!
>
> On Thu, Jan 16, 2014 at 2:29 PM, Dan Staples
> <danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>> wrote:
>
> Inline:
>
> On 01/16/2014 03:19 PM, Ben West wrote:
> > 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.
>
> I'm not following, how would unique client IP addresses remove the
> problem? The way SMesh does handoff is by setting a 2sec DHCP lease
> time, thus causing the client to renew constantly to the nearest AP. The
> nice thing is that doesn't require any changes on the client
> side...clever, in my opinion :)
>
>
> Sorry didn't see the detail about a 2sec DHCP lease in the SMesh paper,
> just the language about preserving open connections across roaming!
> (Didn't read far enough...)
>
> IMO, such a short DHCP lease would help smooth roaming, but I'm curious
> about the extent of overhead it creates. That would have dnsmasq (or
> equivalent) working continuously on the node, using resident memory to
> do so. Likewise, it would send out a fair amount of traffic over the
> channel just to manage the DHCP leases. This may not work well on
> low-quality/noisy connections, e.g. ~1Mbit/s transfer rates, with all
> the DHCP overhead displacing client traffic.
>
>
> >
> > 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
> <mailto:danstaples at opentechinstitute.org>
> > <mailto:danstaples at opentechinstitute.org
> <mailto: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>
> > <mailto:danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>>
> > > <mailto:danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>
> > <mailto: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>
> > <http://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> <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>>
> > > <mailto:danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>
> > <mailto:danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>>>
> > > > <mailto:danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>
> > <mailto:danstaples at opentechinstitute.org
> <mailto:danstaples at opentechinstitute.org>>
> > > <mailto: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>
> > > <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>
> <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>>
> > > <mailto: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>>>
> > > > <mailto: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>>
> > > <mailto: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>>
> > <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>
> <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>>
> > > <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>
> <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
> > <mailto: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> <tel:314-246-9434
> <tel:314-246-9434>> <tel:314-246-9434 <tel:314-246-9434>
> > <tel: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>
> <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
> > <mailto: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> <tel: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
> > _______________________________________________
> > 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