[Olsr-users] problem when disconnection two network cables

[Koen Swinters]

Ferry,

Thank you for posting it. 
I've checked your patch and it is OK for me. 
I've have made an automatic test to check this and it has runned for more than 48h without any error.

Regards,

Koen


-----Original Message-----
From: Ferry Huberts [mailto:(spam-protected)] 
Sent: zaterdag 13 juni 2015 13:38
To: Henning Rogge
Cc: Koen Swinters; (spam-protected)
Subject: Re: [Olsr-users] problem when disconnection two network cables

I've posted a patch on the dev list, please review it.


On 13/06/15 12:40, Henning Rogge wrote:
> Hi,
>
> the analysis of the bug sounds reasonable. Please post the patch here
> and/or the olsr-dev list! :)
>
> Henning
>
> On Fri, Jun 12, 2015 at 4:03 PM, Ferry Huberts <(spam-protected)> wrote:
>> You can post the patch here, or on the dev list
>>
>> Henning, WDYT?
>>
>> On 12/06/15 15:55, Koen Swinters wrote:
>>>
>>> Hi all,
>>>
>>> We are using olsrd-0.6.8 in our system.
>>>
>>> I have a problem with the following setup:
>>>
>>> Node 8100 ------------- node 3
>>>
>>>        |             X                 |
>>>
>>> Node 8120 ------------- node 425
>>>
>>> Each node has a wired connection to the 3 other nodes (each node has 3
>>> Ethernet interfaces). Olsrd is running on each node.
>>>
>>> When I disconnect the cable between node 3 and node 8120 and after this
>>> the cable between node 8120 and node 425 => node 425 cannot reach node
>>> 8120 anymore (there is still a path via node 3 and node 8100) => the
>>> routing table on node 425 is not updated.
>>>
>>> Remark: when there is no physical Ethernet connection our systems
>>> disables the eth interface (ethx)
>>>
>>> I`ve investigated this problem and found the following problem in olsrd:
>>>
>>> ·disconnect the cable between node 3 and node 8120 => Link down between
>>> 3 and 8120 => disable interface
>>>
>>> oLine 371 in interfaces.c: "olsr_remove_interface(struct olsr_if* iface)"
>>>
>>> ·Line 379 in "interfaces.c":
>>> "olsr_delete_link_entry_by_ip(&ifp->ip_addr)"
>>>
>>> §Line 411 in "link_set.c":  "olsr_delete_link_entry(link);"
>>>
>>> ·Line 375 in
>>> "olsr_delete_neighbor_table(&link->neighbor->neighbor_main_addr)";
>>>
>>> ·This function will delete the neighbor from the neighbor table
>>>
>>> ·(Line 177 in neighbor_table.c)
>>>
>>> ·This function sets "changes_neighborhood = true;" (Line 219 in
>>> neighbor_table.c)
>>>
>>> oIn "olsr_scheduler(void)" (line 486 in scheduler.c)
>>>
>>> ·function "olsr_process_changes()" (line 180 in olsr.c)
>>>
>>> ·Because "changes_neighborhood == TRUE and olsr_cnf->lq_level > 1"
>>> "olsr_calculate_lq_mpr() "is called
>>>
>>> ·In "olsr_calculate_lq_mpr()" (line 51 in lq_mpr.c) a new mpr is
>>> calculated (8100 will now be mpr for 8120) and the function
>>> "signal_link_changes(true);" is called => link_changes  == true
>>>
>>> ·In the next step  ANSN  is increased
>>>
>>> oAt the tc_interval  a tc message is generated with this ANSN in => the
>>> neighbors see a change in the ANSN number(when the packet are received)
>>> an will update their tables
>>>
>>> ·Link Down between node 8120 and 425
>>>
>>> oLine 371 in interfaces.c: "olsr_remove_interface(struct olsr_if* iface)"
>>>
>>> ·Line 379 in "interfaces.c":
>>> "olsr_delete_link_entry_by_ip(&ifp->ip_addr)"
>>>
>>> §Line 411 in "link_set.c":  "olsr_delete_link_entry(link);"
>>>
>>> ·Line 375 in
>>> "olsr_delete_neighbor_table(&link->neighbor->neighbor_main_addr)";
>>>
>>> ·This function will delete the neighbor from the neighbor table
>>>
>>> ·(Line 177 in neighbor_table.c)
>>>
>>> ·This function sets "changes_neighborhood = true;" (Line 219 in
>>> neighbor_table.c)
>>>
>>> oIn "olsr_scheduler(void)" (line 486 in scheduler.c)
>>>
>>> ·function "olsr_process_changes()" (line 180 in olsr.c)
>>>
>>> ·Because "changes_neighborhood == TRUE and olsr_cnf->lq_level > 1"
>>> "olsr_calculate_lq_mpr() "is called
>>>
>>> ·In "olsr_calculate_lq_mpr()" (line 51 in lq_mpr.c) no new mpr is
>>> calculated (8100 will stay mpr for 8120) and the function
>>> "signal_link_changes(true);" is not called => link_changes  == false
>>>
>>> ·In the next step  ANSN  is not increased
>>>
>>> oAt the tc_interval  a tc message is generated with old ANSN in => the
>>> neighbors see no change in the ANSN number(when the packet are received)
>>> an will no update their tables
>>>
>>> Solution:
>>>
>>> ·When a neighbor is deleted from the neighbor table (line 177 in
>>> neighbor_table: olsr_delete_neighbor_table(const union olsr_ip_addr
>>> *neighbor_addr)) also call the function signal_link_changes(true);
>>> because there is a change in the neighbor table.
>>>
>>> I’ve tested this and it is working correct (routing tables are updated
>>> as expected).
>>>
>>> Where can I post this fix, or is there a better solution?
>>>
>>> Regards,
>>>
>>> koen
>>>
>>>
>>>
>>
>> --
>> Ferry Huberts

-- 
Ferry Huberts

-----
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2015.0.5961 / Virusdatabase: 4360/9999 - datum van uitgifte: 06/12/15