[Olsr-users] problem when disconnection two network cables

[Ferry Huberts]

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