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

Reuben Hawkins reubenhwk at gmail.com
Wed May 5 12:30:26 EDT 2010


Hi Pekka,

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...

Thanks,
Reuben

On Tue, May 4, 2010 at 2:20 AM, Pekka Savola <pekkas at netcore.fi> wrote:

> Hello,
>
> During today's testing I found a similar problem that Teemu fixes last
> year.
>
> When you have multiple interfaces (IgnoreIfMissing=on, and one interface is
> down, when you bring it back up, radvd crashes with a segfault in
> timer.c:152 ("tm->prev->next = tm->next;").
>
> Interestingly enough, I don't see this happening when running radvd as
> root.
>
> I played around with this a bit, but could not figure out the real root
> cause.  I'm tempted to work around this by applying the following
> work-around fix.  Anyone else interested in looking into this a bit more?
>
> On Thu, 27 Aug 2009, Teemu Torma wrote:
>
>> On Thursday 27 August 2009 15:20:23 Pekka Savola wrote:
>>
>>> Anyone interested and have time to look at this?  I'll try to figure
>>> out more when I have a bit more time.
>>>
>>
>> I did that yesterday and I have been running the radvd with attached patch
>> which seems to cure the problem.
>>
>> The issue is that when interface comes back up, send_ra will call
>> reload_config which will reset timers for all interfaces.  However, the
>> current timer event will continue processing as usual and at the end will
>> reset the current timer.  Since reload_config already did that, timer list
>> pointers will be screwed and at least in my case cause an infinite loop.
>>
>> I haven't tried this, but it might suffice to ignore already existing
>> timer
>> entry in set_timer (i.e, tm->next && tm->prev).
>>
>> I don't know the code well enough to say if this is a good way to deal
>> with
>> the issue.
>>
>> Teemu
>
>
> --
> 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/20100505/6a63825f/attachment.html>


More information about the radvd-devel-l mailing list