[radvd-devel-l] losing default route

[Tomasz Grobelny]

On Saturday 23 of July 2005 00:24, Pekka Savola wrote:
> On Fri, 22 Jul 2005, Tomasz Grobelny wrote:
> > --- and this is repeated as before: ---
> > [Jul 22 23:01:21] radvd: timer_handler called for eth2
> > [Jul 22 23:01:21] radvd: sending RA on eth2
> > [Jul 22 23:01:21] radvd: setting timer: 7.58 secs
> > [Jul 22 23:01:21] radvd: calling alarm: 7 secs, 580494 usecs
> > [Jul 22 23:01:21] radvd: calling alarm: 7 secs, 580282 usecs
> > [Jul 22 23:01:21] radvd: recvmsg len=56
> > [Jul 22 23:01:21] radvd: if_index 5
> > [Jul 22 23:01:21] radvd: found Interface: eth2
> > --- and once again it all stops after: ---
> > [Jul 22 23:02:25] radvd: calling alarm: 0 secs, 302 usecs
> > --- end of file ---
>
> So, there is _nothing_ after that in the logs?  
Right. Unless I do ifdown/ifup on the client once again.

> What are the about 10 preceding messages prior to the last one?
>
Here you are (after one more ifdown/ifup):
[Jul 23 00:33:32] radvd: recvmsg len=16
[Jul 23 00:33:32] radvd: if_index 5
[Jul 23 00:33:32] radvd: found Interface: eth2
[Jul 23 00:33:32] radvd: random mdelay for eth2: 96.48
[Jul 23 00:33:32] radvd: sending RA on eth2
[Jul 23 00:33:32] radvd: setting timer: 3.65 secs
[Jul 23 00:33:32] radvd: calling alarm: 3 secs, 651956 usecs
[Jul 23 00:33:32] radvd: recvmsg len=56
[Jul 23 00:33:32] radvd: if_index 5
[Jul 23 00:33:32] radvd: found Interface: eth2
[Jul 23 00:33:35] radvd: timer_handler called for eth2
[Jul 23 00:33:35] radvd: sending RA on eth2
[Jul 23 00:33:35] radvd: setting timer: 3.83 secs
[Jul 23 00:33:35] radvd: calling alarm: 3 secs, 826750 usecs
[Jul 23 00:33:35] radvd: calling alarm: 3 secs, 826505 usecs
[Jul 23 00:33:35] radvd: recvmsg len=56
[Jul 23 00:33:35] radvd: if_index 5
[Jul 23 00:33:35] radvd: found Interface: eth2
[Jul 23 00:33:39] radvd: calling alarm: 0 secs, 86 usecs

> Could you also run debugging with -d 5 so we could see which context
> set_timer is called.
>
man says there are only 4 levels... But with "-d 5" before last message I get 
"calling schedule_timer from alarm_handler context".

> Have you tried whether this worked in 0.7.2? (There were some changes
> in timestamp usage in 0.7.3)
>
I had 0.7.2 and it worked just fine. Then I upgraded both client and router OS 
(PLD Linux) and found that it stopped working. Then I thought that maybe the 
bug is fixed in 0.8 so I tried this version, without success.

> If I'd have to guess, I'd say this is caused by a host sending an
> ill-timed RS just when radvd has sent out a RA, and it messes up the
> timing somehow.  
I don't know if this information is of any value but time and date is pretty 
well synchronised between router and host (ntp).

> If you want to try look at this, you could try adding 
> a bit of debugging printing in the middle 'else
> if' of process.c:process_rs().. you could also try uncommenting the
> clear_timer line there.
>
It is already uncommented.

Tomek