<p>This bug also showed up yesterday afternoon (every some minutes), but as we wanted to debug it in the evening everything was fine,..</p><p>today henning and me triggered it with doing ifdown eth1 && sleep 1 && ifup eth1 serveral times</p>
<p>above is not very likely under real conditions,..</p><p>but on this machine there are many openvpn tunnels olsr runs on,.. which go up and down quite often</p><p>so we also tried openvpn restarts but nothing happened,..</p>
<p>now i tried are more realistic approch, i blocked the openvpn traffic, to get a typical tunnel timeout shutdown</p><p>and about nearly 50% of my tries the same segfault happened,.. so im quite sure that this also triggered the problems yesterday (as there were some instable tunnels around at his time, which were comlpetely offline in the evening (when we couldn`t find a problem))</p>
<p>----</p><p>but during triggering this segfaults i also found some other bugs/strange things</p><p>it seems that even if no segfault happens olsr tends to forget to update the kernel routing table, under this test conditions,..</p>
<p>and once as there were stable ~ 90% wrong routes in the kernel (wrong meand 90% of the routes of txtinfo plugin where different (mostly different) or missing in the kernel table)</p><p>as i looked around i found following Links table in txtinfo (httpinfo had the same)</p>
<p>Table: Links<br>Local IP Remote IP Hyst. LQ NLQ Cost<br><a href="http://0.0.0.0">0.0.0.0</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 1.000<br><a href="http://107.105.101.7">107.105.101.7</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 1.860<br>
<a href="http://0.0.0.0">0.0.0.0</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 1.016<br><a href="http://0.0.0.0">0.0.0.0</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 1.020<br><a href="http://107.105.101.7">107.105.101.7</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 1.000<br>
<a href="http://0.0.0.0">0.0.0.0</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 3.735<br><a href="http://0.0.0.0">0.0.0.0</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 1.000<br><a href="http://0.0.0.0">0.0.0.0</a> <a href="http://100.0.0.0">100.0.0.0</a> 0.00 0.000 0.000 1.000<br>
<a href="http://0.0.0.0">0.0.0.0</a> <a href="http://100.0.0.0">100.0.0.0</a> 0.00 0.000 0.000 1.000<br><a href="http://107.105.101.7">107.105.101.7</a> <a href="http://100.0.0.0">100.0.0.0</a> 0.00 0.000 0.000 1.000<br>
<a href="http://0.0.0.0">0.0.0.0</a> <a href="http://2.0.0.0">2.0.0.0</a> 0.00 0.000 0.000 3.609<br><a href="http://107.105.101.6">107.105.101.6</a> <a href="http://100.0.0.0">100.0.0.0</a> 0.00 0.000 0.000 1.000<br>
<a href="http://0.0.0.0">0.0.0.0</a> <a href="http://100.0.0.0">100.0.0.0</a> 0.00 0.000 0.000 1.000<br><a href="http://0.0.0.0">0.0.0.0</a> <a href="http://100.0.0.0">100.0.0.0</a> 0.00 0.000 0.000 1.000<br>
<br>usually there are <a href="http://78.41.112.2">78.41.112.2</a> (instead of <a href="http://0.0.0.0">0.0.0.0</a>) and <a href="http://193.238.159.100">193.238.159.100</a> (instead of <a href="http://107.105.101.7">107.105.101.7</a>, which looks lik ea completely random number for me)<br>
</p><p><a href="http://78.41.112.2">78.41.112.2</a> belongs to the eth1 devcie of this machine, which has been ifupdowned several times (while olsr was starting up) but the interfaces with <a href="http://193.238.159.100">193.238.159.100</a> (openvpn tunnels) should have operated normally, ...</p>
<p>Markus</p>