Hi,
A problem seems to be is that ifp->probes has been overloaded for both
RS's and NS's (rtr solicits and DAD basically), and they're used
differently: DAD starts from number X (X>0) decrementing it and RS start
from (assumed to be zero), incrementing it.
So there _appears_ to be a possible race there. I'm not not 100%
confortable with my analysis though, so I'm sure Alexey will correct me
if/when I'm wrong.
If this is the case, perhaps the attached patch would do.. disclaimer:
untested.
On Fri, 8 Mar 2002, Petr Baudis wrote:
> Dear diary, on Fri, Mar 08, 2002 at 01:48:28PM CET, I got a letter,
> where Jan Oravec <jan.oravec@xxxxxxxx> told me, that...
> > Hello,
> >
> > In function addrconf_rs_timer, the code increases ifp->probes, but it's
> > never reset (except DAD). That is probably causing that neighbor
> > solicitation doesn't work correctly and in order to use IGP routing daemons
> > (e.g. OSPFv3 included in 'zebra' package), it must work, otherwise OSPF
> > daemons are not able to connect, because their packets are not delivered
> > because router doesn't receive neighbor solicitation response.
> >
> > Best Regards,
> >
> > --
> > Jan Oravec
> > project coordinator
> > XS26 - 'Access to IPv6'
> > jan.oravec@xxxxxxxx
>
> In order to clarify this even a bit more - it will try to send the neigh sol
> three times (or whatever arbitrary number is set for the interface), and if it
> will fail, it will never try to resend it once more.
>
> Tested on linux-2.4.18 (non-usagi).
>
> Kind regards,
>
>
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
ipv6-ns_prbes.diff
Description: Text document
|