Dear all,

Some of you may know that I've been working, on and off, on a simple
solution to the roaming problem: ensuring that a mobile node keeps its IP
address as it moves from one WiFi access point to another.

This is a collaboration with Nexedi (, to whom thanks.
Thanks also to Christof Schulze, who helped me understand the « l3roamd »

This is a very early prototype (it's been tested exactly twice, in two
different network topologies), and usually I wouldn't feel comfortable
making it available yet.  However, being confined in a small Parisian flat
with a limited selection of network hardware, I'm not able to do any
serious testing, so I've decided to make the software available for
testing before it's ready.

In order to help, you'll need a working Babel network running a reasonably
recent version of babeld (I haven't tested BIRD, but the protocol is
designed to be reasonably independent of the routing protocol) with at
least two WiFi APs including Linux.  You can run sroamd on just a subset
of your routers.

Show me the code

  git clone

and check the README.  It depends on Linux, hostapd and babeld.

Sorry for the idiosyncratic licence, but I'm not ready to allow
redistribution yet.  I'll put a free software licence when I feel the
software is ready.


Every sroamd node acts as a WiFi AP, as DHCPv4 server and as an IPv6 RA
server.  There is a replicated database, flooded between all sroamd nodes,
that contains, for each mobile node:

  - the IPv4 address it has been assigned;
  - the IPv6 prefix that it has been assigned;
  - its current location.

This information is used to announce a route to the mobile node over
Babel, which ensures that traffic destined to the mobile client gets to
it.  Traffic from the mobile node, on the other hand, is routed using
a simple hack (idea stolen from PMIPv4): all the sroamd nodes have the
same IPv4 address, the same link-local IPv6 address; a gratuitious ARP and
ND is sent to each node as soon as it associates to an AP in order to
update its neighbour tables tables.

Interestingly, the algorithm is intrinsically racy: agreeing on the mobile
node's location is a distributed consensus problem, and therefore
theoretically impossible.  In other words, in the absence of a global
clock the nodes sroamd nodes might, occasionally, disagree on the location
of a mobile node.  We solve this issue by detecting this situation (grep
for "conflict" in flood.c), and pinging the node at both locations.  Note
that I haven't proved the algorithm correct, so there might be some edge
cases I haven't thought about.


I recommend running sroamd with the "-d3" flag, which will give you an
idea of what's happening.  You may dump the replicated database by sending
the SIGUSR1 signal.

Please let me know of your successes or failures.  I'll be testing on my
side, to the extent possible during the current emergency, please pull

-- Juliusz

Babel-users mailing list

Reply via email to