[radvd-devel-l] radvd crash with multiple interfaces when 1 interface comes back up

[Pekka Savola]

I apologize for not being able to get time and test setup to look at 
this.  I wonder -- has this been tested with e.g. TAHI IPv6 ready logo 
test programs?  Is anyone experienced with these?

I could roll these up as a radvd-2.0-rc1 package or something, but I'd 
like to get someone do an IPv6 ready logo test before that could be 
released as final.

On Mon, 10 May 2010, Reuben Hawkins wrote:
> Attached is timerless code.  Rather than blocking for mdelay, RAs are simply scheduled in a task queue to be sent at the
> correct time.  Care is taken to keep someone from remotely flooding the task queue.
> 
> Main changes:
> * no timers/no race conditions
> * task queue queues up scheduled RAs (Unicast and Multicast)
> * main loop has a 'pulse' which checks if interfaces have gone up/down and automatically revives up'ed interfaces and
> schedules init RA's on them.
> * Ignore RA checking if the RA originated locally (RFC says check RA's from "other" routers)
> 
> Minor changes:
> * sock isn't passed to functions as it's already global
> * adding source/dest address to logging info where interesting
> * removed whitespaces at the end of lines
> 
> Let me know if anything is missing so I can fix.
> 
> Thanks,
> Reuben
> 
> On Wed, May 5, 2010 at 10:26 PM, Reuben Hawkins <reubenhwk at gmail.com> wrote:
>       I'll try over the next week or so to submit timerless code which honours the delay...
>
>       Thanks,
>       Reuben
> 
> On Wed, May 5, 2010 at 9:40 PM, Pekka Savola <pekkas at netcore.fi> wrote:
> On Wed, 5 May 2010, Reuben Hawkins wrote:
>       This is happening in the latest from CVS in the timer code?  Can you reproduce this crash in the code
>       I submitted which removes the
>       timers?  It seems like the timers are the source of half the problems submitted to the mailing list. 
>       I stand by removing the
>       timers.  Building a poll/select based solution will dramatically simplify the code and debugging. 
>       Please let me know what
>       guidelines I should follow to get my code integrated into the next version...
> 
> 
> Yes, this happens with the latest CVS.  I have not tried reproducing with polling based mechanism, but I don't
> think it would exist there.
> 
> I agree that timers are causing problems (and likely continue to do so), and we would be better off without them,
> or by implementing better locking when using them (anyone interested in looking at this?).
> 
> In order for select/poll-based mechanism to be considered, it would need to support all MUSTs from the spec and
> preferably SHOULDs also. I recall there was some discussion about this late last year, e.g. relating to random
> delay feature.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> --
> radvd-devel-l mailing list  :  radvd-devel-l at litech.org
> http://lists.litech.org/listinfo/radvd-devel-l
> 
> 
> 
> 
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings