<div dir="ltr"><div><div><div><div><div>hi Ben, nice to read you again! <br><br></div>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.<br>
</div>Unfortunatelly, we can't reproduce the "ETX=infinite situation" and the interested networks are all production networks that serve several user connections.<br><br></div>By the way, we noticed that "ETX=infinite" occurs more frequently when the olsrd-gateway manages about <span id="result_box" class="" lang="en"><span class="">a hundred</span> <span class="">connections from the users associated to the APs of the meshed nodes (every mesh node runs a second VAP in master mode): so </span></span><span id="result_box" class="" lang="en"><span class="">the rate</span> <span class="">of that error,</span> <span class="">if</span> <span class="">I may say so</span><span>, seems to</span> <span class="">be related to the</span> <span class="">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. Maybe incorrect timings could cause slow refreshes of the routing tables so that a loop could occur? But all the nodes and all at the same time?... unlikely. Moreover, the gateway node - as I wrote - continues to receive olsrd packets, </span></span><span id="result_box" class="" lang="en"><span class="">sign that</span> <span class="">the other nodes</span> <span class="">are alive.<br>
</span></span></div></div><div><br><span id="result_box" class="" lang="en"><span class="">Comments are</span> <span class="">always welcome!<br><br></span></span></div><span id="result_box" class="" lang="en"><span class="">Antonio<br>
<br></span></span><div><div><span id="result_box" class="" lang="en"><span class=""><br></span></span></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-28 23:27 GMT+02:00 Ben West <span dir="ltr"><<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Antonio! I recognize the timing / interval values you have for the adhoc interface from ROBIN-MESH firmware based on olsrd v0.5.6. When I tried carrying these timing values over to olsrd v0.6+, I experienced sporadic problems with isolated repeater nodes mysteriously losing their route (while using SmartGateway) in meshes with multiple gateway nodes. Removing those timings seemed to make that particular failure mode go away.<br>
<br></div>Below is the configuration I use (defaults if not specified), and the firmware platform versions:<br><br>DebugLevel 0<br>AllowNoInt yes<br>IpVersion 4<br>LinkQualityLevel 2<br>LinkQualityAlgorithm "etx_ffeth"<br>
SmartGateway yes<br>SmartGatewayUseCount 1<br>Pollrate 0.1<br><br>LoadPlugin "olsrd_arprefresh.so.0.1"<br>{<br>}<br><br>LoadPlugin "olsrd_dyn_gw.so.0.5"<br>{<br> PlParam "HNA" "0.0.0.0 0.0.0.0"<br>
}<br><br>LoadPlugin "olsrd_txtinfo.so.0.1"<br>{<br> PlParam "port" "2006"<br> PlParam "Accept" "127.0.0.1"<br>}<br><br>Interface "eth0"<br>{<br> Mode "ether"<br>
}<br><br>Interface "wlan0-1"<br>{<br> Mode "mesh"<br> Ip4Broadcast 255.255.255.255<br>}<br><br></div><div>Hardware:<br></div><div>UBNT Nanostation Loco M2's<br></div><div><br></div>Firmware platform:<br>
<div><div><div>OpenWRT AA r41182<br></div><div>Kernel v3.3.8<br></div><div>ath9k v3.3.8+2014-05-22-1<br></div><div>olsrd v0.6.6.1<br></div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div class="h5">
On Fri, Jul 25, 2014 at 5:11 AM, Antonio Anselmi <span dir="ltr"><<a href="mailto:tony.anselmi@gmail.com" target="_blank">tony.anselmi@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div dir="ltr"><div><div>Hi all,<br>I'm facing an odd problem that recurs randomly, without any user intervention, at different times on a single-gateway network. <br>Suddenly, all the links of the gateway node have their NLQ values equal to zero and the respective LQ values greather than zero, so every link has an INFINITE cost -> olsrd route table is empty -> ip main route table is empty.<br>
Just because all NLQ values are zero, it seems that the nodes do not receive/hear olsrd packets from the gateway, but , at the same time, the gateway itself continues to receive and process packets sent by the other node (LQ values change in time). <br>
<br>In this situation, I logged to the gateway node and run the command 'tcpdump -vv -ni wlan0-1 port 698' (wlan0-1 is the adhoc interface) to inspect the way olsrd was working.<br>As supposed:<br>1) the gateway had stopped transmitting olsrd packets but continued to receive and process olsrd packets sent by the other nodes<br>
2) olsrd route table and ip main route table were empty and the gateway does not ping any other node<br>3) the topology seen by the gateway have no node reachable<br>4) at layer2 the neighbors are all associated (iw dev wlan0-1 station dump) so adHoc beacons travel<br>
Stopping and restarting olsrd does not fix the stalemate as well as manually populating the ip main route table. Obviuosly, rebooting the node all goes right ...untill the next olsrd stale.<br><br>I'm wondering:<br>1) Why all links go to INFINITE cost? (A loop caused by LQ mechanism?)<br>
2) may be the case that the gateway try to transmit olsrd packets, but since its route table is empty, no packet reach the adHoc interface<br>(loop inside the gteway) ?<br>3) since the TC-LQ packets sent by the nodes (and received by the gateway) do not show the gateway (NLQ = 0) why these packets reach the gateway? Nodes should have no route to the gateway since they do not hear it!<br>
4) and... the all_INFINITE_costs situation (as well as the empty routing tables) is a "cause" or an "effect" ?<br><br>Have you some directions?<br><br>Antonio<br><br>For your information:<br></div>- network is 17 nodes + 1 gateway node, every node has an AP for wireless user connections<br>
</div><div><div>- openwrt trunk r37737, kernel 3.10.4<br>- ath9k from kmod-mac80211 3.10.4+2013-06-27-1<br>- olsrd.conf file below<br><br><br>DebugLevel 0<br>IpVersion 4<br>AllowNoInt yes<br>Pollrate 0.05<br>TcRedundancy 2<br>
MprCoverage 7<br>LinkQualityFishEye 1<br>LinkQualityLevel 2<br>UseHysteresis no<br>NatThreshold 0.5<br><br>Interface "wlan0-1"<br>{<br> Ip4Broadcast 255.255.255.255<br> HelloInterval 6.0<br> HelloValidityTime 108.0<br>
TcInterval 4.0<br> TcValidityTime 324.0<br> MidInterval 18.0<br> MidValidityTime 324.0<br> HnaInterval 18.0<br> HnaValidityTime 108.0<br>}<br><br>LoadPlugin "olsrd_txtinfo.so.0.1"<br>{<br> PlParam "port" "8090"<br>
PlParam "Host" "127.0.0.1"<br>}<br><br>LoadPlugin "olsrd_dot_draw.so.0.3"<br>{<br> PlParam "port" "2004"<br>}<br><br>LoadPlugin "olsrd_httpinfo.so.0.1"<br>
{<br> PlParam "port" "8080"<br> PlParam "Net" "0.0.0.0 0.0.0.0"<br>}<br><br> <br>Hna4<br>{<br> 0.0.0.0 0.0.0.0<br>}<br><br></div></div></div>
<br></div></div><div class="">--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
<a href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all">
<br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br></div>
</font></span></div>
</blockquote></div><br></div>