mesh portal discovery
david at lang.hm
david at lang.hm
Wed Jan 9 20:29:28 EST 2008
On Wed, 9 Jan 2008, Javier Cardona wrote:
>> The DHCP procedure currently being used only discovers
>> the nearest mesh portal when it is first run (DHCP_DISCOVER),
>> not when it tries to renew (DHCP_REQUEST). Furthermore,
>> as the address previously assigned indicates which mesh portal
>> was selected, it seems like we should always be discovering, not
> You probably don't want that: a mesh point might have equal cost
> routes to several mesh portals. In that case you want some
> hysteresis: only change to a new MPP if it offers a big advantage
> over the current one.
>> As long as it can communicate with it by hopping through the mesh, it
>> will renew the existing lease and never discover a closer MPP/DHCP server
>> This was the problem that prompted my original message on this thread.
> One way to do this would be to run a simple daemon that
> 1. Periodically sends traffic to the anycast address. If you want
> to use dhclient for this ( assuming it is patched as described here:
> http://www.cozybit.com/projects/mpp-utils/index.html#update ) you
> could send frames to the anycast address like this:
> # dhclient eth0 -1 -lf /dev/null -sf /bin/true
> 2. Compare the metric of the best mpp with the current mpp. This
> can be done via iwpriv fwt_list calls.
> 3. If the cost difference justifies it, wipe out the existing leases
> and re-discover
> # rm /var/lib/dhcp3/* ; dhclient eth0
you really don't want to change the IP of the laptop any more then you
absolutly must, it's too likely to disrupt existing connections.
as I understand it the mesh is (close to) continuously reconfiguring
itself to find the most efficiant path across it.
is the resulting information available to all of the MPP nodes?
if it is you should be able to do something like the following.
1. on initial connection use the existing process to make a 'best guess'
to find a DHCP server and get an IP address.
2. outbound packets use this IP address no matter which MPP the packets go
3. inbound packets go to the MPP that initially gave out the IP address.
3a. if that MPP determines that it is still the closest MPP to the end
node, it sends the packet out normally.
3b. if the packet arrives at the MPP over a tunnel from another MPP, don't
check the routing, just send it out over the mesh (avoids routing loops)
3c. if the MPP determines that another MPP is significantly closer to the
end node, it tunnels the packet over to the closer MPP, which then sends
it over the mesh to the end node.
I think that step 3 can be tested without extensive code changes by useing
hooks in iptables. Iptables has the ability to call out to userspace code
as part of it's processing decision, if that userspace code reports that
the end-node is closest to this MPP then it routes the packet normally, if
it thinks that another MPP is closer, it returns somthing to indicate
which remote node to use, and then the packet gets routed through a tunnel
to that node (a simple GRE tunnel will do, we just need to encapsulate
This approach requires that all of the MPP boxes know which one of them is
closest to each end-node. If the current mesh structure does not provide
this info to all nodes then an additional daemon would need to share this
info (possibly over the same tunnels that are used to relay the traffic)
I will say up front that I haven't done the iptables->userspace hooking in
any of my projects, but this should be an easy way to prototype this
before adding this type of routing to the kernel.
This approach is safe, the worst case is that inbound packets take a
longer path then optimal to get to the node (either they don't get
re-routed when they should or they get re-routed when they shouldn't,
either way they take more hops over the radio than nessasary). By not
changing the IP address of the node it avoids breaking existing
connections at the cost of an additional hop over wired networks
if you are doing NAT on the MPP then this approach won't work (becouse the
outbound packets don't all go through the same MPP)
if the different MPP boxes are on different Internet connections and there
is egress filtering outside the MPP boxes, that filtering would need to
allow the mesh IP's out through all MPP boxes.
More information about the Devel