[Olsr-dev] [RFC] problems with multiple interfaces on the same medium + proposed solution

[Teco Boot]

It is an issue with the 1-hop table (i.e. link).

A link is defined by the local interface address and the neighbor's 
interface address. In the hello message, same link is reported twice, 
as can be seen in tcpdump provided by Conrad:
   172.28.175.97.698 > 255.255.255.255.698: OLSRv4, seq 0x1c2b, length 76
       Hello-LQ Message (0xc9), originator 172.31.175.97, ttl 1, hop 0
         vtime 576.000s, msg-seq 0x910e, length 48
         hello-time 6.000s, MPR willingness 3
           link-type Symmetric, neighbor-type Symmetric, len 12
             neighbor 172.29.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
           link-type Unspecified, neighbor-type Symmetric, len 20
             neighbor 172.29.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
             neighbor 172.31.175.61, link-quality 0.00%, neighbor-link-quality 0.00%

The 172.28.175.97<--->172.29.175.61 is reported as Symmetric-Symmetric and as
Unspecified-Symmetric. If parsing is sequential, the last Unspecified will override
the previous Symmetric-Symmetric. This can be solved at receiver, but why sending
misleading info?

By removing this link from the hello, the full link table is send to the neighbor, 
but in two hello messages. The receiver gets both on same interface. And fills the 
link table.

An alternate approach is updating the hello packet format, adding the local interface.
Let's not go there.

Teco 


> Op 7 jan. 2017, om 11:17 heeft Henning Rogge <(spam-protected)> het volgende geschreven:
> 
> Could the problem be that the OLSR 2-hop database (if I remember it
> correctly) is per neighbor, not per interface?
> 
> I think that was one of the major design changes in OLSRv2.
> 
> Henning
> 
> On Fri, Jan 6, 2017 at 10:22 PM, Ferry Huberts <(spam-protected)> wrote:
>> 
>> 
>> On 06/01/17 21:41, Conrad Lara wrote:
>>>>> 
>>>>> Ubuntu 14.04 running stock available olsr.org -
>>>>> 0.6.6.1-git_0000000-hash_41d32a614ae55e881b7c0456c8e3ed54 (built
>>>>> on 2013-10-26 05:10:52 on toyol)
>>>>> 
>>>> 
>>>> That olsrd is very very old.
>>>> 
>>>> Use master.
>>>> 
>>> 
>>> I agree it is an old version and will give the latest mainline a
>>> test, but if this issue only occurs in master I would believe that
>>> would make this a regression flaw in hello message parsing and
>>> shouldn't we instead look at placing the code there instead of
>>> changing how we broadcast hello's by removing data that has
>>> historically been broadcasted over the network?
>>> 
>> 
>> 
>> Once you are able to reproduce it on master and with that same setup NOT on
>> 0.6 then I will look into bisecting it when I'm also able to confirm that.
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev