<div dir="ltr"><div><div>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?<br>
<br>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.<br>
<br></div>For meshing nodes, some non-trivial parts of smooth client roaming would be factors like ...<br><br></div><div>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.<br></div><div><br></div>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.<br>
<div><div><div><br></div>2. When a client roams from node A to node B, how to inform node B's captive portal to <i>not</i> 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 <i>does</i> get bounced back to the splash page, regardless of how many nodes he has roamed to, after some operator-defined timeout has elapsed.<br>
<div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 11:05 AM, 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">We actually hadn't considered that since the access point handover is a<br>
pretty large project for down the line. It was more for the sake of<br>
simplicity, IIRC.<br>
<br>
Handover aside, I also don't think retaining a client IP 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> 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 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 getting a new<br>
IP address when switching APs?<br>
<br>
Dan<br>
<div class="im"><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 address<br>
</div>> 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>> to, among other things, help make<br>
<div class="im">> client roaming between nodes easier? I.e. implying that clients would<br>
> be assigned the same IP regardless of which node they 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>
</div><div class="im">> <mailto:<a href="mailto:danstaples@opentechinstitute.org">danstaples@opentechinstitute.org</a>>> wrote:<br>
><br>
> Developers and network maintainers might want to check out our blog post<br>
> on significant backwards-imcompatible changes in the R1 release:<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 <a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a><br>
</div>> <<a href="http://100.64.0.0/10" target="_blank">http://100.64.0.0/10</a>> range and<br>
<div class="im">> all client subnets are bridged and assigned addresses in the<br>
</div>> <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>><br>
<div class="im">> range<br>
> * default adhoc SSID and channel were removed<br>
> * adhoc BSSID is now deterministically generated based on hash of SSID<br>
> and channel<br>
><br>
> The blog post explains the details and reasoning behind these changes,<br>
> for those that are interested, and also includes info on upgrading<br>
> pre-R1 Commotion networks.<br>
><br>
> You can also find R1 release notes here:<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 BD86 43A9<br>
> _______________________________________________<br>
> Commotion-dev mailing list<br>
> <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
</div>> <mailto:<a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a>><br>
<div class="im">> <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>
</div>> <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><br>
<div class="HOEnZb"><div class="h5"><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>