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

Reuben Hawkins reubenhwk at gmail.com
Tue May 11 00:52:35 EDT 2010

Sorry for the sloppy submission, but I have yet another patch.  Please apply
this to to the tgz file and ignore my last patch (it already included in
this one).

On Mon, May 10, 2010 at 11:05 AM, Reuben Hawkins <reubenhwk at gmail.com>wrote:

> Hi Pekka,
> I realized after my last email I had no calls to stop_adverts.  The
> attached diff can be applied to my code.
> Thanks,
> Reuben
> On Mon, May 10, 2010 at 10:46 AM, Reuben Hawkins <reubenhwk at gmail.com>wrote:
>> 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/b5fda4f7/attachment.html>

More information about the radvd-devel-l mailing list