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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel