John, > 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 Cheers, Javier -- Javier Cardona cozybit Inc. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
