[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4739D7F7.90300@hp.com>
Date: Tue, 13 Nov 2007 11:59:35 -0500
From: Vlad Yasevich <vladislav.yasevich@...com>
To: "Templin, Fred L" <Fred.L.Templin@...ing.com>
Cc: netdev@...r.kernel.org,
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
Hi Fred
Templin, Fred L wrote:
>>> + return;
>>> + }
>>> +
>>> sit_add_v4_addrs(idev);
>>>
>>> if (dev->flags&IFF_POINTOPOINT) {
>>> @@ -2531,6 +2570,18 @@ static void addrconf_rs_timer(unsigned l
>>> * Announcement received after solicitation
>>> * was sent
>>> */
>>> +
>>> + /* ISATAP (RFC4214) - schedule next RS/RA */
>>> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
>>> + struct ip_tunnel *t =
>> netdev_priv(ifp->idev->dev);
>>> + if (t->parms.i_key != INADDR_NONE) {
>>> + spin_lock(&ifp->lock);
>>> + ifp->probes = 0;
>>> + ifp->idev->if_flags &=
>> ~(IF_RS_SENT|IF_RA_RCVD);
>>> + addrconf_mod_timer(ifp, AC_DAD,
>> t->parms.o_key*HZ);
>>
>> You are using a DAD timer to schedule RS?
>
> I am using the DAD timer to re-DAD the link local, which
> in turn schedules RS.
>
Why? Seems to me that using the RS timer (AC_RS) gets you everything you
want and nothing you don't. You set probes to 0, which marks DAD complete,
thus you don't do DAD. You already have code in the addrconf_rs_timer() to
properly send the RS. So, your patch to sending the RS is much shorter if
you use the AC_RS timer.
Am I missing something?
Thanks
-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists