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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> > 05/04/2007 02:39 PM
> >
> > To
> > "John Watlington" <[EMAIL PROTECTED]>
> > cc
> > "Dan Williams" <[EMAIL PROTECTED]>, "Michail Bletsas" <[EMAIL PROTECTED]>,
> > "OLPC Devel" <devel@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
> >
> >
> >
> >
>
>
_______________________________________________
Devel mailing list
Devel@laptop.org
http://mailman.laptop.org/mailman/listinfo/devel
