Hi Pekka,<br><br>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.<br><br>I'm mirroring my code changes at <a href="http://gitorious.org/radvd-hacks">http://gitorious.org/radvd-hacks</a>. I'm also mirroring my testing tool at <a href="http://gitorious.org/pingra">http://gitorious.org/pingra</a> (which sends solicits and waits for router adverts, a somewhat more proactive radvdump).<br>
<br>Sorry, I'm not experienced with TAHI...but I'm interested in how my changes fare in the test.<br><br>Thanks,<br>Reuben<br><br><div class="gmail_quote">On Fri, Jun 4, 2010 at 2:49 AM, Pekka Savola <span dir="ltr"><<a href="mailto:pekkas@netcore.fi">pekkas@netcore.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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?<br>
<br>
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.<div><div></div><div class="h5"><br>
<br>
On Mon, 10 May 2010, Reuben Hawkins wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Attached is timerless code. Rather than blocking for mdelay, RAs are simply scheduled in a task queue to be sent at the<br>
correct time. Care is taken to keep someone from remotely flooding the task queue.<br>
<br>
Main changes:<br>
* no timers/no race conditions<br>
* task queue queues up scheduled RAs (Unicast and Multicast)<br>
* main loop has a 'pulse' which checks if interfaces have gone up/down and automatically revives up'ed interfaces and<br>
schedules init RA's on them.<br>
* Ignore RA checking if the RA originated locally (RFC says check RA's from "other" routers)<br>
<br>
Minor changes:<br>
* sock isn't passed to functions as it's already global<br>
* adding source/dest address to logging info where interesting<br>
* removed whitespaces at the end of lines<br>
<br>
Let me know if anything is missing so I can fix.<br>
<br>
Thanks,<br>
Reuben<br>
<br>
On Wed, May 5, 2010 at 10:26 PM, Reuben Hawkins <<a href="mailto:reubenhwk@gmail.com" target="_blank">reubenhwk@gmail.com</a>> wrote:<br>
I'll try over the next week or so to submit timerless code which honours the delay...<br>
<br>
Thanks,<br>
Reuben<br>
<br>
On Wed, May 5, 2010 at 9:40 PM, Pekka Savola <<a href="mailto:pekkas@netcore.fi" target="_blank">pekkas@netcore.fi</a>> wrote:<br>
On Wed, 5 May 2010, Reuben Hawkins wrote:<br>
This is happening in the latest from CVS in the timer code? Can you reproduce this crash in the code<br>
I submitted which removes the<br>
timers? It seems like the timers are the source of half the problems submitted to the mailing list. <br>
I stand by removing the<br>
timers. Building a poll/select based solution will dramatically simplify the code and debugging. <br>
Please let me know what<br>
guidelines I should follow to get my code integrated into the next version...<br>
<br>
<br>
Yes, this happens with the latest CVS. I have not tried reproducing with polling based mechanism, but I don't<br>
think it would exist there.<br>
<br>
I agree that timers are causing problems (and likely continue to do so), and we would be better off without them,<br>
or by implementing better locking when using them (anyone interested in looking at this?).<br>
<br>
In order for select/poll-based mechanism to be considered, it would need to support all MUSTs from the spec and<br>
preferably SHOULDs also. I recall there was some discussion about this late last year, e.g. relating to random<br>
delay feature.<br>
<br>
--<br>
Pekka Savola "You each name yourselves king, yet the<br>
Netcore Oy kingdom bleeds."<br>
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings<br>
--<br>
radvd-devel-l mailing list : <a href="mailto:radvd-devel-l@litech.org" target="_blank">radvd-devel-l@litech.org</a><br>
<a href="http://lists.litech.org/listinfo/radvd-devel-l" target="_blank">http://lists.litech.org/listinfo/radvd-devel-l</a><br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
-- <br>
Pekka Savola "You each name yourselves king, yet the<br>
Netcore Oy kingdom bleeds."<br>
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings</div></div><br>--<br>
radvd-devel-l mailing list : <a href="mailto:radvd-devel-l@litech.org">radvd-devel-l@litech.org</a><br>
<a href="http://lists.litech.org/listinfo/radvd-devel-l" target="_blank">http://lists.litech.org/listinfo/radvd-devel-l</a><br></blockquote></div><br>