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

[Kenneth Finnegan]

> Cool.  Is there a website describing your project?

Not yet, but I will definitely document the heck out of it on my blog
once I get it all put together; this was way more difficult than I
expected.

> You should assign your AHCP server an address that's outside the AHCP
> pool.
>
> For example, in our network, we're using global IPs for the servers, and
> addresses in 192.168.4.0/24 for the clients.
>
>> At this point I have it working by configuring the ahcpd server node
>> as 10.99.1.254/16 while distributing 10.99.1.0/24,
>
> Either reduce the AHCP pool (a /25 should be enough, at least until you
> have more nodes), or put the server at 10.99.2.1 (which might require
> you to export more routes in Babel).
>
>> I can think of a number of solutions, but looking through the code I
>> didn't pick up the scent of any of them.
>
> If the above answer doesn't suit your particular case, please feel free
> to suggest any features you're thinking about, we can discuss them on
> this list to see if they're reasonable.

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.

I guess I'm confused by what you mean by a global IP address, and
don't see the advantage to it.  My network topology is as follows:
[Internet]--- Public IP address [DSL Modem] 10.1.1.1 --- 10.1.1.13
(DHCP - eth0) [Desktop] (AHCP server - wlan0) SomeIPAddress
~~~2.4GHz~~~ AHCP issued IP address [Mesh node]

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?
Neither seems very elegant.

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.
 When I started AHCPd on an unconfigured interface advertising a
prefix, I kind of expected it to allocate itself one of those
addresses and configure the interface...

I'm imagining that in a situation where you are quickly setting up and
growing a mesh network, AHCP subnet allocations for each server is
going to be on postits via sneaker-net.   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?

Or do I manually enforce the rule "10.99.1.0/27 is for ahcp servers,
and each one advertises a prefix based on it's IP address 10.99.1.X:
10.99.1.(X*32)/27"  (So that 10.99.1.1 advertises 10.99.1.32/27,
10.99.1.3 advertises 10.99.1.96/27, etc)


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.  If two nodes come up out of range of
each other, neither sees an existing ad-hoc network matching the
essid, so they both create random IBSSs and forever refuse to talk to
each other, even once they come within range.  Is there a documented
list somewhere of chipsets that actually handle ad-hoc mode correctly
with Linux, or am I doing something wrong, or is hard-coding cell
numbers (iwconfig wlan0 mode ad-hoc ap 12:12:12:12:12:12) another
requirement of meshes?

Kenneth Finnegan
blog.thelifeofkenneth.com