<div>definetely sounds like a bug,.. <br></div><div><br></div><div>my own (monitored) olsrds definitely dont do it,... *G</div><div><br></div><div>Markus</div><br><div class="gmail_quote">On Sun, Apr 25, 2010 at 5:22 AM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi!<br>
<br>
On Sat, Apr 24, 2010 at 7:25 PM, Markus Kittenberger<br>
<div class="im"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
</div><div class="im">> if so, there would be non influence on olsr/routing from any layer <=2<br>
> (which means you problem is probably inside olsr and/or its config)<br>
<br>
</div>Yes. I also believe so. For example, we added some new reporting about<br>
connectivity loss from the mesh (which we measure with number of time<br>
route to the gateway drops) and one node with VPN uplink + direct ~1.0<br>
ETX WiFi peering with another node with VPN uplink is reporting<br>
connectivity loss from time to time. There was no stuck beacons errors<br>
on any of those nodes, they use different ISPs for VPN tunnels and<br>
just the first one reported connectivity loss even with having (at<br>
least two - its own VPN tunnel and direct peer without connectivity<br>
loss reported) very good connections to the mesh. Why OLSR dropped the<br>
connection to the mesh and not just changed its peering node? (It is a<br>
rhetorical question. But I do believe there is some bug somewhere.)<br>
<font color="#888888"><br>
<br>
Mitar<br>
<br>
</font></blockquote></div><br>