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