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

[Teco Boot]

As lq_packet.c is not changed with impact on hello msg, I think the issue shows 
after 3d2fd73a5528a9c7cdccd088f2dcca80b37e66b9. It changes neighbor parsing.

I did not analyse your patch. 

I think it is a bug at sender and the impact is at receiver. Before your change, 
the bug didn't show up.

Let's fix issue at sender.

Teco 


> Op 7 jan. 2017, om 13:03 heeft Teco Boot <(spam-protected)> het volgende geschreven:
> 
> 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
>