[Olsr-users] INFINITE cost in all links

[Henning Rogge]

On Tue, Jul 29, 2014 at 2:37 PM, Antonio Anselmi <(spam-protected)> wrote:
> hi Ben, nice to read you again!
>
> running olsrd with the minimal (default) configuration will be the first
> step for debugging, in addition to compile olsrd with the flag
> NO_DEBUG_MESSAGES=0 (Openwrt Makefile). This way, as soon as that condition
> occurs, we'll try to grab the debug lines for off-line examination based on
> a well-known configuration.
> Unfortunatelly, we can't reproduce the "ETX=infinite situation" and the
> interested networks are all production networks that serve several user
> connections.

If the production network Olsrd crashs anyways you could start it
there with logging activated and then pipe the stderr output into some
ringbuffer so you only see the end when it crashes again.

> By the way, we noticed that "ETX=infinite" occurs more frequently when the
> olsrd-gateway manages about a hundred connections from the users associated
> to the APs of the meshed nodes (every mesh node runs a second VAP in master
> mode): so the rate of that error, if I may say so, seems to be related to
> the traffic/connections.

> The more a node is under load the more is its
> latency, then it begins to lose packets and its LQ decreases, routes change
> and TC propagates the changes.

Could it be that the outgoing interface is congested to that Olsrd
cannot get its own packets out? If the outgoing UDP buffer of Olsrd
fills up it will just drop packets at some point.

Are you using prioritization for the Olsr UDP port?

> Maybe incorrect timings could cause slow
> refreshes of the routing tables so that a loop could occur?

No. Unless the system clock misbehaves the timing should be stable.

> But all the
> nodes and all at the same time?... unlikely. Moreover, the gateway node - as
> I wrote - continues to receive olsrd packets, sign that the other nodes are
> alive.

Henning