<div dir="ltr"><div><div><div>hi all<br><br>we finally got a lot of debug lines from the gateway node 5.5.56.38 <span lang="en"><span>and</span> <span>we will begin to</span> <span>examine the file. </span></span><span lang="en"><span>From</span> <span>a quick glance</span></span> I was truck by the message <br>
<span lang="en"><span></span></span><span lang="en"><span></span></span>
</div>"22:03:49 root: Not processing message originating from 5.5.56.38!"<br>repeated a few lines further<br></div>Well, as said, 5.5.56.38 is the IP address of that node so - <span lang="en"><span>excluding</span> <span>that there are</span> no <span>repeated</span> <span>addresses in the network - it seems that that node starts to receive olsrd packets sent by itself! And, IMO, this could be the problem because after these two messages all neighbors of<br>
</span></span></div><div><span lang="en"><span>the node are not symmetric ones and all links go to INFINITE (see the portion of debug lines just after the ned of this post).<br><br></span></span></div><div><span lang="en"><span>
</span></span></div><span lang="en"><span>Moreover, from what I can see (...and understand) it seems that the node processes itself (</span></span><span lang="en"><span><span lang="en"><span>5.5.56.38) </span></span>like any other neighbour:<br>
<br>--- 22:19:05.165044 ---------------------------------------------------- GATEWAYS<br> SPF: append path 5.5.56.38, cost 0.000, via -<br> --- 22:19:05.164935 ------------------------------------------------- DIJKSTRA<br>
SPF: exploring node 5.5.56.38, cost 0.000<br> SPF: delete candidate 5.5.56.38, cost 0.000<br> SPF: insert candidate 5.5.56.38, cost 0.000 <br></span></span><div><span lang="en"><span></span></span><br><span id="result_box" class="" lang="en"><span class="">Or maybe</span> <span class="">my thoughts</span> <span class="">are wrong</span><span class="">?</span></span></div>
<div><span lang="en"><span>Antonio<br>
<br><br><br>--- 22:03:49.239496 ----------------------- TWO-HOP NEIGHBORS<br>5.67.178.219 0.000 YES YES YES 3<br>TC: chg edge entry 5.101.255.146 > 5.103.216.152, cost (0.592/0.537) 3.143<br>TC: chg edge entry 5.101.255.146 > 5.103.1.95, cost (0.678/0.615) 2.394<br>
TC: chg edge entry 5.101.255.146 > 5.101.254.224, cost (0.784/0.631) 2.019<br>TC: chg edge entry 5.101.255.146 > 5.101.254.120, cost (0.117/0.203) 41.683<br>Processing TC from 5.101.255.146, seq 0x3aad<br>TC: chg edge entry 5.101.254.224 > 5.103.216.228, cost (0.757/0.769) 1.719<br>
TIMER: jitter 5% rel_time 288000ms to 280369ms<br>TC: chg edge entry 5.101.254.224 > 5.149.138.10, cost (0.168/0.419) 14.132<br>TC: chg edge entry 5.101.254.224 > 5.101.255.146, cost (0.615/0.808) 2.010<br>TIMER: jitter 5% rel_time 288000ms to 284555ms<br>
TC: chg edge entry 5.101.254.224 > 5.67.177.233, cost (0.757/0.489) 2.695<br>Processing TC from 5.101.254.224, seq 0x62dc<br>TC: chg edge entry 5.149.138.10 > 5.101.254.224, cost (0.286/0.199) 17.465<br>TC: chg edge entry 5.149.138.10 > 5.103.1.136, cost (0.650/0.882) 1.740<br>
TC: chg edge entry 5.149.138.10 > 5.103.216.228, cost (0.635/0.549) 2.866<br>TC: chg edge entry 5.149.138.10 > 5.67.177.233, cost (0.732/0.808) 1.688<br>Processing TC from 5.149.138.10, seq 0x8e73<br>TIMER: jitter 5% rel_time 288000ms to 277541ms<br>
TC: chg edge entry 5.67.177.233 > 5.149.138.10, cost (0.839/0.732) 1.624<br>TC: chg edge entry 5.67.177.233 > 5.103.1.136, cost (0.310/0.497) 6.480<br>TC: chg edge entry 5.67.177.233 > 5.103.216.228, cost (0.721/0.784) 1.767<br>
TC: chg edge entry 5.103.1.136 > 5.149.138.10, cost (0.882/0.631) 1.795<br>Processing TC from 5.67.177.233, seq 0x600e<br>TIMER: jitter 5% rel_time 288000ms to 273980ms<br>TC: chg edge entry 5.67.177.233 > 5.101.254.224, cost (0.478/0.678) 3.080<br>
TC: chg edge entry 5.103.1.136 > 5.67.177.233, cost (0.497/0.372) 5.389<br>TC: chg edge entry 5.103.1.136 > 5.67.179.17, cost (0.619/0.415) 3.882<br>Received TC from NON SYM neighbor 5.103.1.136<br>Not processing message originating from 5.5.56.38! <-------------------------- !!!!<br>
Received TC from NON SYM neighbor 5.103.1.136<br>Processing TC from 5.103.1.136, seq 0xd695<br>Received TC from NON SYM neighbor 5.101.255.146<br>Received TC from NON SYM neighbor 5.101.255.146<br>Not processing message originating from 5.5.56.38! <-------------------------- !!!!<br>
Received TC from NON SYM neighbor 5.103.1.136<br>Processing TC from 5.103.1.136, seq 0xd695<br>Received TC from NON SYM neighbor 5.101.255.146<br>Received TC from NON SYM neighbor 5.101.255.146<br>Received TC from NON SYM neighbor 5.103.216.152<br>
Received TC from NON SYM neighbor 5.103.216.152<br>TIMER: jitter 5% rel_time 20000ms to 19453ms<br>Received TC from NON SYM neighbor 5.101.254.224<br>Received TC from NON SYM neighbor 5.101.254.224<br>Received TC from NON SYM neighbor 5.101.254.224<br>
Received TC from NON SYM neighbor 5.101.254.224<br>Received TC from NON SYM neighbor 5.101.254.224<br>Received TC from NON SYM neighbor 5.103.216.119<br>reset link timer: 5.103.216.119 = 19128060<br>5.103.1.95 INFINITE<br>
5.103.216.119 INFINITE<br>5.101.255.146 INFINITE<br>5.67.178.219 INFINITE<br>5.103.1.95 INFINITE<br>5.67.179.22 INFINITE<br>5.103.216.152 5.149.138.53 INFINITE<br>5.103.216.119 5.67.179.22 INFINITE<br>
5.67.179.17 INFINITE<br> 5.101.254.120 INFINITE<br>5.103.216.152 INFINITE<br><br>
</span></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-30 19:55 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Jul 30, 2014 at 7:47 PM, Antonio Anselmi <<a href="mailto:tony.anselmi@gmail.com">tony.anselmi@gmail.com</a>> wrote:<br>
>> Are you using prioritization for the Olsr UDP port?<br>
><br>
><br>
> that's an interesting point, it could make the difference.<br>
> Do you know examples about tc implementation that prioritizes UDP packets?<br>
<br>
</div>I think the Freifunk firmware has it.<br>
<br>
Just google for "OLSR UDP prioritization" and you should find a few examples.<br>
<br>
With some current wifi drivers it might be even possible to set the<br>
traffic class of OLSR UDP packets so that they get prioritization on<br>
layer2 (wifi) too. But I am not an expert for using the "tc" command.<br>
<span class="HOEnZb"><font color="#888888"><br>
Henning Rogge<br>
</font></span></blockquote></div><br></div>