[Olsr-users] Routing problem with bad ETX

Ferry Huberts (spam-protected)
Tue Apr 30 18:09:28 CEST 2013


There are some relevant changes in there :-)

0.6.5.3 -------------------------------------------------------------------

Ferry Huberts (5):
      pud: detect the java include directory
      pud: better detection of java jdk
      gateway: work around kernel IPIP module initialisation bug
      main: use /dev/urandom by default
      pud: set local loopback for multicast tx

Henning Rogge (2):
      Update version after release of v0.6.5.2
      Release v0.6.5.3

Ronald in 't Velt (1):
      Fix setsockopt for setting Traffic Class in IPv6



On 30/04/13 18:08, Ferry Huberts wrote:
> 
> 
> On 30/04/13 18:04, Saverio Proto wrote:
>> You need to adjust your multicast rate.
>> Btw 0.6.3 olsrd is very old. Please use this feed to compile latest version:
>>
>> https://github.com/openwrt-routing/packages
> 
> Saverio, can you upgrade this feed to 0.6.5.3?
> Thanks!
> 
>>
>> best regards
>>
>> Saverio Proto
>>
>>
>> 2013/4/30 Simon Ebnicher <(spam-protected)>:
>>> Hi,
>>> we have set up a small OLSR mesh network with three routers (TP-Link
>>> TL-WDR3600 running OpenWrt 12.09rc1, olsrd 0.6.3). We placed two routers
>>> near to each other, and the third router at quite some distance.
>>> R1 <----ETX:~1----> R2 <---------------ETX: 1.x to 2.x-----------> R3
>>>
>>> The ETX on the direct link between R1 and R3 is usually below 2 (about
>>> 1.3 to 1.7), so the direct route is preferred. However, the direct route
>>> is completely unusable for data transfer (e.g., ping reports >95% packet
>>> loss). As soon as two hop route via R2 is used, ping and other traffic
>>> works fine.
>>> We are wondering why the unreliable link is rated too optimistically. We
>>> suspect that the Hello and TC multicast packets (which are used to
>>> calculate the ETX) may have a better reception probability than unicast
>>> packets (e.g., because they are sent at lower rates, no RTS/CTS). This
>>> would lead to ETX values that do not reflect the link accurately.
>>>
>>> Can anyone confirm or explain this behaviour and maybe offer a solution?
>>>
>>> Best regards,
>>> Simon Ebnicher
>>>
>>> --
>>> Olsr-users mailing list
>>> (spam-protected)
>>> https://lists.olsr.org/mailman/listinfo/olsr-users
>>
> 

-- 
Ferry Huberts




More information about the Olsr-users mailing list