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

[Reuben Hawkins]

Hi Pekka,

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20100510/1fd0e9ea/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radvd-1.6-poll.tgz
Type: application/x-gzip
Size: 92403 bytes
Desc: not available
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20100510/1fd0e9ea/attachment-0001.bin>