<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-30 19:35 GMT+02:00 Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On Tue, Jul 29, 2014 at 2:37 PM, Antonio Anselmi <<a href="mailto:tony.anselmi@gmail.com">tony.anselmi@gmail.com</a>> wrote:<br>

> hi Ben, nice to read you again!<br>
><br>
> running olsrd with the minimal (default) configuration will be the first<br>
> step for debugging, in addition to compile olsrd with the flag<br>
> NO_DEBUG_MESSAGES=0 (Openwrt Makefile). This way, as soon as that condition<br>
> occurs, we'll try to grab the debug lines for off-line examination based on<br>
> a well-known configuration.<br>
> Unfortunatelly, we can't reproduce the "ETX=infinite situation" and the<br>
> interested networks are all production networks that serve several user<br>
> connections.<br>
<br>
</div>If the production network Olsrd crashs anyways you could start it<br>
there with logging activated and then pipe the stderr output into some<br>
ringbuffer so you only see the end when it crashes again.<br>
<div class=""><br>
> By the way, we noticed that "ETX=infinite" occurs more frequently when the<br>
> olsrd-gateway manages about a hundred connections from the users associated<br>
> to the APs of the meshed nodes (every mesh node runs a second VAP in master<br>
> mode): so the rate of that error, if I may say so, seems to be related to<br>
> the traffic/connections.<br>
<br>
> The more a node is under load the more is its<br>
> latency, then it begins to lose packets and its LQ decreases, routes change<br>
> and TC propagates the changes.<br>
<br>
</div>Could it be that the outgoing interface is congested to that Olsrd<br>
cannot get its own packets out? If the outgoing UDP buffer of Olsrd<br>
fills up it will just drop packets at some point.<br>
<br>
Are you using prioritization for the Olsr UDP port?<br></blockquote><div> </div><div>that's an interesting point, it could make the difference.<br>Do you know examples about tc implementation that prioritizes UDP packets?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
> Maybe incorrect timings could cause slow<br>
> refreshes of the routing tables so that a loop could occur?<br>
<br>
</div>No. Unless the system clock misbehaves the timing should be stable.<br>
<div class=""><div class="h5"><br>
> But all the<br>
> nodes and all at the same time?... unlikely. Moreover, the gateway node - as<br>
> I wrote - continues to receive olsrd packets, sign that the other nodes are<br>
> alive.<br>
<br>
</div></div><span class=""><font color="#888888">Henning<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Antonio<br></div></div>