[Commotion-dev] Commotion R1 Changes
Josh King
jking at opentechinstitute.org
Fri Jan 17 00:59:23 UTC 2014
Well, it's not just a problem of addressing. The various subnets of
10.0.0.0/8 that are generated by the nodes also are used for the HNA
announcements of OLSRd. If each client gets its own unique IP, other
parts of the network won't be able to find it unless each node
dynamically updates its list of HNAs to include every single address
individually. Alternatively, we could change the client networks so that
they're just NAT'd behind their nodes by default, but then the IP is
still effectively changing as far as the network is concerned, it's just
that it's the NAT's IP that's shifting rather than the client's own, so
that doesn't buy us anything. In order to do this properly, we would
need to do something like tunneling the original traffic from the
initial node to the new node when a client roams. Having a unified
client IP space might make this easier or might not; depends on how it's
implemented. Mobile IPv6 might get at this.
On Thu 16 Jan 2014 04:21:00 PM EST, Dan Staples wrote:
> 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
>
--
Josh King
Lead Technologist
The Open Technology Institute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20140116/2bf6ccfe/attachment.sig>
More information about the Commotion-dev
mailing list