mesh portal discovery

[david at lang.hm]

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
>> renewing...
>
> 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 
through.

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 
the packet)

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


Potential problems

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.

David Lang