> 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 _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
