[Olsr-dev] bmf plugin problem

[Klaus Darilion]

Hi Erik!

Erik Tromp schrieb:
> Yes, you are right.
> 
> There is a fix at:
>  
> http://downloads.sourceforge.net/olsr-bmf/olsr0.5.6-bmf-v1.6.tar.gz

Oh, I did not knoew that bmf is distributed separately.

> I already proposed that fix in my mail from 6 july 2008.
I subscribed the list on 11. July :-)

I made some multicast tests and experienced strange behavior. When I 
ping to 224.0.0.1 I see the ICMP packets in interface mbf0 (and the 
encapsulated ones in interface eth0).

But when I send UDP traffic to 224.0.0.1 with netcat or iperf I see the 
UDP packets are routed through interface eth0 (although the routing 
table clearly shows bmf0 as outgoing interface). Then I also tried a 
simple UDP client program (same sample code found in the Internet) which 
was routed correctly via interface bmf0.

Do you have any ideas about this strange behavior?

thanks
klaus



> 
> Regards,
> Erik
> 
> 
>> -----Oorspronkelijk bericht-----
>> Van: (spam-protected) 
>> [mailto:(spam-protected)] Namens Klaus Darilion
>> Verzonden: maandag 21 juli 2008 12:35
>> Aan: OLSR development
>> Onderwerp: [Olsr-dev] bmf plugin problem
>>
>> Hi!
>>
>> I installed the bmf plugin but it does not work:
>>
>> OLSRD BMF: outgoing pkt of 84 bytes captured on tuntap 
>> interface "bmf0": 
>> 10.10.0.153->224.0.0.1
>> OLSRD BMF: ----> Considering forwarding pkt on "eth0" to 
>> 10.10.0.152 OLSRD BMF: ----> Not forwarding to 10.10.0.152: 
>> link is timing out.
>>
>> The condition of the last log output is:
>>
>> if (currEtx < LINK_COST_BROKEN)
>>        {
>>          OLSR_PRINTF( 9, "%s: ----> Not forwarding to ........
>>          continue; /* for */
>>        }
>>
>>
>> I dumped the corresponding values:
>>
>> With: LinkQualityAlgorithm    "etx_fmp"
>>    currEtx=70811.000000, LINK_COST_BROKEN=4194304 (1<<22)
>>
>> With: LinkQualityAlgorithm    "etx_ff"
>>    currEtx=1024.000000, LINK_COST_BROKEN=4194304 (1<<22)
>>
>> The condition does not use a path whose currEtx is BELOW 
>> LINK_COST_BROKEN. Shouldn't it be the other way round?
>>
>> thanks
>> klaus
>>
>> --
>> Olsr-dev mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-dev
>>
>