[Babel-users] AHCPD in openwrt (currently broken for multiple interface)

Dave Taht dave.taht at gmail.com
Wed Jun 22 15:54:16 UTC 2011

I have one outstanding issue with ahcpd that I'd like to resolve the right way.

The head of openwrt and the related luci gui currently are not
configuring ahcpd correctly in the presence of *multiple* client

Instead of firing off a single ahcpd instance, e.g.

ahcpd [some options] wlan1 wlan2 wlan3

The current incorrect code attempts to fire off one copy of the daemon
per device, e.g.g:

ahcpd [some options] wlan1
ahcpd [some options] wlan2
ahcpd [some options] wlan3

which odoesn't work.

Now, the code in /etc/init.d/ahcpd tries (or rather, tried at some
point in the past) to do the right thing, but it is currently
overridden and ignored by the normal ifup code which does the above.

Luci also has very excellent support for the server/forwarder modes of ahcpd.

This leads to my questions:

1a) Should the configuration distinguish between
server/forwarder/client at the gui level? below that, ahcp.sh, ignore
the ifup stuff entirely for interfaces marked as ahcp capable) (so the
only way to bring up or down ahcpd is to fiddle with the daemon,
rather than ifup)

1b) related to that solution it would be kind of nice to autoassign
the local ahcp marked devices their address also via ahcp...

2a) Alternatively there could be an 'option' 'type' 'ahcp' or 'network
name 'mesh' or something like that, to more finely control the
behavior in ifup/down. ahcpd could be stopped and restarted with new

I actually kind of like 2a as that lets me reconfigure more stuff on
the fly, such as network channels... but that still leaves conflicting
with 1a as something of a problem.

3) I don't quite 'get' the distinction between server/forwarder/client
in AHCPD. The specific scenario I have in mind is


(I use 2002:XXXX:ZZZZ:bab0::/64 as a convention for the babel mesh presently,
where 2002:XXXX:ZZZZ is the correct 6in4 address of the gateway)

where I would like both GW1 and GW2 to announce their addresses and
participate in the flooding protocol, acting as servers.

But it would be useful for both to have each other's subnets available
so if one goes down, the other gw could take over, and the leases to
be relatively short.

(obviously this would also require policy routing, and I haven't tried
fiddling with this at this level yet)

This last is not entirely relevant to solving the multiple interfaces
problem denoted in the first place.... it would be good to have a
clean solution to the original problem of 1a and/or 2a stated

is there a case where ahcpd could be used in both server and client
mode that makes sense?

Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608

More information about the Babel-users mailing list