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

[Reuben Hawkins]

Hi Pekka,

Attached is my latest of the timerless code.  There were a few issues
if/when a flood of solicit messages were received which are fixed in the
attached.

I'm mirroring my code changes at http://gitorious.org/radvd-hacks.  I'm also
mirroring my testing tool at http://gitorious.org/pingra (which sends
solicits and waits for router adverts, a somewhat more proactive radvdump).

Sorry, I'm not experienced with TAHI...but I'm interested in how my changes
fare in the test.

Thanks,
Reuben

On Fri, Jun 4, 2010 at 2:49 AM, Pekka Savola <pekkas at netcore.fi> wrote:

> 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
>
> --
> 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/20100605/52b6ab27/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radvd-timerless-2010.6.5.tgz
Type: application/x-gzip
Size: 92477 bytes
Desc: not available
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20100605/52b6ab27/attachment-0001.bin>