mesh portal discovery

[Javier Cardona]

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.