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

[Reuben Hawkins]

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/fca91a2c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stop_adverts.diff
Type: application/octet-stream
Size: 226 bytes
Desc: not available
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20100510/fca91a2c/attachment.obj>