[Babel-users] How should an AHCP server configure it's ip address?

[Juliusz Chroboczek]

> I figured out what was throwing me off. AHCPd doesn't allocate the
> first IP address in the netmask. So for 10.99.1.32/27, it skips
> 10.99.1.32. Unfortunately, for 10.99.1.1/24, it skips 10.99.1.0.

Yes.  In IPv4, the first and last addresses of a subnet are reserved
(the first is the network address, the last is the broadcast address),
so AHCP avoids these adresses in case the full subnet is being
configured by AHCP.

(Interestingly enough, both of these addresses are there to support
features that have been obsoleted for as long as anyone can remember,
but who am I to redefine the way IPv4 works.)

> I guess I'm confused by what you mean by a global IP address, and
> don't see the advantage to it.

No advantage in your particular case.  It simply turns out that both our
AHCP servers already had a statically configured global IPv4 address, so
this partciular issue never concerned us.

> So if Desktop.wlan0's IPv4 addess can't be in the subnet it's
> advertising, what is the most logical IP to assign to that interface?
> Do I give it a 10.1.1.0/24 address? A 10.99.NotInAPrefix address?

If you're in a pure mesh, the prefix length you put on your interfaces
does not matter -- you can set it up as a /24 or a /32, the
Babel-provided routes will supersede the kernel-provided routes anyway.

What we're doing (in addition to the global addresses described above)
is to split our /24 into two /25s; the bottom half is for statically
allocated addresses (nodes that we configure manually), and the upper
half for AHCP-allocated ones.  The prefix length given to the kernel is
/32, in both cases.

> The first solution that comes to mind is adding a "configure-self"
> flag to tell the ahcpd server to allocate itself a piece of the
> sub-net, and use the already existing ahcp-config.sh script to set it.

Interestingly enough, that used to be implemented in an earlier version,
but I removed the support.  I'll be glad to reinstate it if the
discussion below fails to convince you.

I don't think that's a good idea.  If for some reason you break your AHCP
configuration, you'll want to be able to ssh into the server to fix it.
(I realise that you probably have a console on your AHCP server, but at
some point you'll want to put it under key, and it's easier to share the
sudoers bit than to share a key.)

> When you're configuring multiple ahcp servers, you already have to go
> through the effort of coordinating disjoint prefixes, so why not use
> that same effort to prevent IPv4 collisions between ahcp servers?

I can see the following solutions:

1. "mode client-server", as described above (what you called "configure-
   self");
2. make ahcpd skip the two first adresses of its range, rather than
   just the first one;
3. add an "exclude" address to the ahcpd configuration, allowing ahcpd
   to skip part of the range;
4. change the config file format to be "first-last" rather than
   "first/plen", allowing for more flexible (non-power-of-two)
   allocations;
5. obsolete IPv4, and make everyone use IPv6 and AHCPv0.

Please let me know which you prefer, and I'll implement it.  (My
personal favourites are 2 and 4, but I don't have any strong feelings
about that particular issue.)

> On another aside, between the half dozen or so wifi chipsets I've
> pulled out of my junk boxes, I haven't seen any of them successfully
> merge 802.11 IBSS fragments.

I'm curious myself.  I've found myself having to manually reboot
a subset of our mesh nodes after each power failure.

> is hard-coding cell numbers (iwconfig wlan0 mode ad-hoc ap
> 12:12:12:12:12:12) another requirement of meshes?

Some people do that.  We don't, and just do manual reboots when the mesh
splits.

-- Juliusz