Re: addrconf.c - possible bug

Re: addrconf.c - possible bug

[Petr Baudis]

Dear diary, on Sun, Mar 24, 2002 at 08:57:37PM CET, I got a letter,
where Petr Baudis <pasky@xs26.net> told me, that...
> Dear diary, on Sat, Mar 23, 2002 at 07:44:51PM CET, I got a letter,
> where Petr Baudis <pasky@xs26.net> told me, that...
> > I started the tcpdump there, and we'll see. However, by looking into code, we
> > found no possibility how would zebra want to mess with loopback.
> > 
> > Also, we discovered that just taking down and back up any ONE interface will
> > fix this for ALL other interfaces as well.
> 
> It failed again and tcpdump still runs happily. Again, taking one of the
> interfaces down and back up (maybe it's worth mentioning that the machine acts
> as XS26 PoP, thus it have about 270 interfaces just now up) fixed the problem
> and the machine started to reply to neighbor solicitations again.

Just as a reminder and for a record, quite nice record of conversation of two
such broken linuxes.

20:43:48.596927 fe80::3e8c:1d09 > fe80::3e18:401b: OSPFv3-dd 28: rtrid secret.host backbone V6/E/R I/M/MS mtu 1480 S 3CA76B2D [hlim 1]
20:43:51.433416 fe80::3e18:401b > fe80::3e8c:1d09: OSPFv3-ls_upd 1256: rtrid rover.dkm.cz backbone
20:43:51.456066 fe80::3e8c:1d09 > fe80::3e18:401b: icmp6: redirect fe80::3e8c:1d09 to fe80::3e8c:1d09
20:43:51.456147 fe80::3e18:401b > fe80::3e8c:1d09: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b
20:43:51.456176 fe80::3e8c:1d09 > fe80::3e18:401b: icmp6: redirect fe80::3e8c:1d09 to fe80::3e8c:1d09
20:43:51.456758 fe80::3e18:401b > fe80::3e8c:1d09: OSPFv3-ls_upd 1256: rtrid rover.dkm.cz backbone
20:43:51.456840 fe80::3e18:401b > fe80::3e8c:1d09: OSPFv3-ls_upd 1256: rtrid rover.dkm.cz backbone
20:43:51.478662 fe80::3e8c:1d09 > fe80::3e18:401b: icmp6: redirect fe80::3e8c:1d09 to fe80::3e8c:1d09

(as a result?)

20:46:54.618539 fe80::3e8c:1d09 > fe80::3e8c:1d09: icmp6: time exceeded in-transit for fe80::3e18:401b
20:46:54.618588 fe80::3e8c:1d09 > fe80::3e8c:1d09: icmp6: time exceeded in-transit for fe80::3e18:401b [hlim 1]
..a lot of that..

It looks they're not going to talk together :).

And another excellent example of the problem:

20:47:58.981124 fe80::2a0:c9ff:fea8:c91c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
20:47:58.981175 fe80::3e18:401b > fe80::2a0:c9ff:fea8:c91c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b

Kind regards,

-- 

				Petr "Pasky" Baudis

* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI hacker
.
Teamwork is essential -- it allows you to blame someone else.
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

Re: addrconf.c - possible bug

[Petr Baudis]

Dear diary, on Sun, Mar 31, 2002 at 09:13:46PM CEST, I got a letter,
where Petr Baudis <pasky@xs26.net> told me, that...
> Dear diary, on Sun, Mar 24, 2002 at 08:57:37PM CET, I got a letter,
> where Petr Baudis <pasky@xs26.net> told me, that...
> > Dear diary, on Sat, Mar 23, 2002 at 07:44:51PM CET, I got a letter,
> > where Petr Baudis <pasky@xs26.net> told me, that...
> > > I started the tcpdump there, and we'll see. However, by looking into code, we
> > > found no possibility how would zebra want to mess with loopback.
> > > 
> > > Also, we discovered that just taking down and back up any ONE interface will
> > > fix this for ALL other interfaces as well.
> > 
> > It failed again and tcpdump still runs happily. Again, taking one of the
> > interfaces down and back up (maybe it's worth mentioning that the machine acts
> > as XS26 PoP, thus it have about 270 interfaces just now up) fixed the problem
> > and the machine started to reply to neighbor solicitations again.
..snip..
> And another excellent example of the problem:
> 
> 20:47:58.981124 fe80::2a0:c9ff:fea8:c91c > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
> 20:47:58.981175 fe80::3e18:401b > fe80::2a0:c9ff:fea8:c91c: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b

  With 2.4.19-pre5, the problem still persist :(. However, now it looks that
the replies for neighbor sol stops to be sent on per-interface basis, not all
at once, as it used to be before..

  It still looks same..

20:49:25.562585 fe80::202:55ff:fe21:4756 > ff02::5: OSPFv3-hello 40: rtrid concorde.lido-tech.net backbone [hlim 1]
20:49:27.641160 fe80::3e18:401b > fe80::202:55ff:fe21:4756: OSPFv3-dd 28: rtrid rover.dkm.cz backbone V6/E/R I/M/MS mtu 1480 S 3CBB14BE
20:49:27.991125 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: OSPFv3-dd 28: rtrid concorde.lido-tech.net backbone V6/E/R I/M/MS mtu 1280 S 3CBB243F
20:49:27.991295 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b
20:49:27.991318 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: OSPFv3-dd 28: rtrid concorde.lido-tech.net backbone V6/E/R I/M/MS mtu 1280 S 3CBB243F
20:49:28.432548 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
20:49:28.432621 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b
20:49:28.432641 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
20:49:29.431424 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
20:49:29.431512 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b
20:49:29.431531 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
20:49:30.431762 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b
20:49:30.431870 fe80::3e18:401b > fe80::202:55ff:fe21:4756: icmp6: redirect fe80::3e18:401b to fe80::3e18:401b
20:49:30.431890 fe80::202:55ff:fe21:4756 > fe80::3e18:401b: icmp6: neighbor sol: who has fe80::3e18:401b

  If there's any more info needed, please just tell us, we'll try to help you
as much as possible.

  Kind regards,

-- 
 
				Petr "Pasky" Baudis
 
* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI hacker
.
Object orientation is in the mind, not in the compiler. -- Alan Cox
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/

Re: addrconf.c - possible bug

[kuznet]

Hello!

>   With 2.4.19-pre5, the problem still persist :(.


Nothing wonderful, nothing has been changed. :-)

>   If there's any more info needed, please just tell us, we'll try to help you
> as much as possible.

Well, when you see this, dump routing tables with

ip -6 route ls table all

And addresses too with

ip addr ls


Alexey