[Commotion-discuss] [Commotion-dev] Commotion R1 Changes

[Ben West]

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> 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 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> 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>> 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> range and
> >     all client subnets are bridged and assigned addresses in the
> >     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>
> >     https://lists.chambana.net/mailman/listinfo/commotion-dev
> >
> >
> >
> >
> > --
> > 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
>



-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-discuss/attachments/20140116/6d43d0e5/attachment.html>