Network association algorithm

[Dan Williams]

On Sun, 2007-05-13 at 21:08 -0700, Javier Cardona wrote:
> Dan, John,
> 
> The patch linked below modifies dhclient to override the broadcast
> address of a network interface with an anycast address.  This option
> is configured in dhclient.conf with the new directive anycast-mac :
> 
> interface "msh0" {
>   anycast-mac ethernet c0:27:c0:27:c0:27;
> }
> 
> When that option is present, all DHCP broadcast traffic out of msh0
> will be sent to the anycast-mac address.  The IP address is left
> unchanged (i.e. 255.255.255.255), which avoids having to change
> anything on the dhcp server side.  We tested it with a vanilla dhcp
> server running on the MPP(s).
> 
> Let me know if you would like me to package this in an RPM or if there
> is anything special that needs to be done to integrate this with NM.

Any chance you could tighten up the timeout/backoff algorithm to not
wait so long between tries?  A max of 5 - 7 seconds or so between
DHCPDISCOVER tries should be a good enough hack for the moment...
Sometimes it picks obscene values like 25 seconds.  On a wireless
medium, it's just really, really likely the frame got lost somewhere
rather and needs to be re-requested.

See client->interval in client/dhclient.c in send_discover() and
send_request() for a start.

Thanks!
Dan

> Cheers,
> 
> Javier
> 
> The patch:  https://cozybit1.dnsalias.org/~javier/patches/dhclient-3.0.5-anycast.patch
> 
> On 5/9/07, Michail Bletsas <mbletsas at laptop.org> wrote:
> > Javier,
> >
> > I think that your approach fits perfectly with our latest connection
> > flowchart and I would like to see it implemented asap.
> >
> > M.
> >
> >
> >
> >
> >
> > "Javier Cardona" <javier at cozybit.com>
> > 05/04/2007 02:39 PM
> >
> > To
> > "John Watlington" <wad at laptop.org>
> > cc
> > "Dan Williams" <dcbw at redhat.com>, "Michail Bletsas" <mbletsas at laptop.org>,
> > "OLPC Devel" <devel at laptop.org>
> > Subject
> > Re: Network association algorithm
> >
> >
> >
> >
> >
> >
> > Hi John, Dan,
> >
> >
> > After chatting with Dan I finally understood your flowchart (pardon my
> > thickness,  I was having some nomenclature problems..).  I learned
> > yesterday
> > that:
> >
> >  1) "established MPPs" are MPPs with multiple mesh interfaces, at most one
> > on
> >  each channel 1,6 and 11.  They are also called "school servers" and will
> > not
> >  be moving around.
> >
> >  2) "ad-hoc MPPs" are xo's that act as MPPs, as portals they were
> > originally conceived.
> >
> >  3) Addresses are assigned by DHCP because link local addresses cannot be
> >  routed.  L3 routing is done by MPPs across mesh segments at different
> >  channels.
> >
> > Based on this understanding, I would like to suggest a change in the way
> > DHCP
> > is used in your proposal.  The current flow is:
> >
> >        +           +
> >       / \         / \
> >      /   \ y     /   \ y
> > ----+DHCP?+-----+ MPP?+----
> >      \   /       \   /
> >       \ /         \ /
> >        + n         + n
> >        |           |
> >        +-----------+
> >        |
> >
> > This approach separates IP address assignment (DHCP) and MPP detection and
> > path
> > selection.  I believe these two functions which can be combined in one:
> >
> > 1. xo sends a DCHP request to L2 address ANY_MPP.  This is a standard
> > DHCPREQUEST sent to a unicast address.  The only thing "non-standard"
> > would be
> > done at the dhcp client:  this DHCPREQUEST would have the L2 anycast
> > address, the L3 broadcast address and would be injected at L2 using
> > the linux packet interface.
> >
> > 2. MPP assigns an IP address and sends a DHCPACK to the L2 address that
> > was in
> > the DHCPREQUEST.  That's vanilla DHCP server.
> >
> > 3. The xo knows the DHCPACK comes from an MPP because it's a response from
> > a
> > request sent to the ANY_MPP address.
> >
> > Advantages:
> >
> > 1. Faster configuration.
> > 2. No broadcast+anycast traffic, only anycast.
> > 3. Replaces non-standard MPPREQs with standard DHCP
> >
> > This model can also be used for ad-hoc MPPs.  In that case ad-hoc MPPs
> > would
> > return gateway and DNS information but would not assign an IP address.
> >
> > What do you think?
> >
> > Javier
> >
> >
> >
> >
> 
>