<div>if it realizes via rtnetlink that the interface "is removed/went down" it doesn't (or at least i planned to code it so) try to remove the routes (as they are already gone *G)<br></div><div><br></div><div>
i will try to reproduce this,.. (but i'm a bit skeptic as i used quite similar testcases when creating the patch,..)</div><div><br></div><div>regaqrds Markus</div><br><div class="gmail_quote">On Thu, Oct 1, 2009 at 5:52 AM, Eric Malkowski <span dir="ltr"><<a href="mailto:eric@bvwireless.net">eric@bvwireless.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In testing OLSR across an openvpn tap interface tonight, I killed openvpn and<br>
got some interesting syslog messages.<br>
This is running the tip of the 0.5.6 branch I believe to be the release<br>
candidate for 0.5.6-r6.<br>
<br>
Here's the log snippet<br>
<br>
Jan  1 02:45:16 hocr-node-3 <a href="http://daemon.info" target="_blank">daemon.info</a> olsrd[432]: Removing interface tap0<br>
Jan  1 02:45:16 hocr-node-3 daemon.err olsrd[432]: OLSR: sendto IPv4 No such device<br>
Jan  1 02:45:18 hocr-node-3 daemon.err olsrd[432]: error 'No such process' (3)<br>
del route to <a href="http://10.5.1.4/32" target="_blank">10.5.1.4/32</a> via 192.168.32.2 dev void<br>
Jan  1 02:45:18 hocr-node-3 daemon.err olsrd[432]: . ignoring 'No such process'<br>
(3) while deleting route!<br>
Jan  1 02:45:18 hocr-node-3 daemon.err olsrd[432]: error 'No such process' (3)<br>
del route to <a href="http://10.2.4.0/24" target="_blank">10.2.4.0/24</a> via 192.168.32.2 dev void<br>
Jan  1 02:45:18 hocr-node-3 daemon.err olsrd[432]: . ignoring 'No such process'<br>
(3) while deleting route!<br>
Jan  1 02:45:18 hocr-node-3 daemon.err olsrd[432]: error 'No such process' (3)<br>
del route to <a href="http://192.168.32.2/32" target="_blank">192.168.32.2/32</a> dev void<br>
Jan  1 02:45:18 hocr-node-3 daemon.err olsrd[432]: . ignoring 'No such process'<br>
(3) while deleting route!<br>
<br>
I'm wondering if olsr realizes (via new netlink notifier stuff perhaps?) tap0<br>
went down, but because openvpn also deletes the interface all together, olsr is<br>
trying to do some route cleanups against a now non-existent tap0 interface.<br>
i.e. it's a sort of race condition.<br>
<br>
I'm no expert on this stuff, but some years ago I did some virtual net interface<br>
drivers in the linux kernel and upon notification of an interface changing state<br>
(by ifconfig from userland and getting called via net device notifier chain),<br>
the kernel code could do whatever it needed to atomically and return from<br>
notifier callback when done.  Since this is a notification to olsr that the<br>
interface is gone, the openvpn process can still wipe the interface out even<br>
before olsr is "done" with whatever it's doing as a result of being notified --<br>
i.e. it's not a chain of calls in kernel space, but different userspace<br>
processes can step on each other is what I'm thinking.  i.e. it's too bad olsr<br>
couldn't be notified, block other stuff from going on while it cleans up<br>
(preventing openvpn from wiping the interface), and then "return" from the<br>
notifier chain and let openvpn finish it's work of removing the device.<br>
<br>
I hope I don't sound too confusing...  and maybe these messages can safely be<br>
ignored, but it looks like there could be some null strings being printed to the<br>
log or something.<br>
<br>
-Eric Malkowski<br>
<font color="#888888"><br>
<br>
--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
<br>
</font></blockquote></div><br>