[Olsr-dev] faulty behaviour when emulating asymmetric links

[Peter Tarjan]

Hi all,
I have recently tested olsrd version 0.5.6~rc7-1 (from Debian testing
- Lenny distribution).
It that did not work perfectly so I tried to find its cause but I only
found that someone else also experienced the same problem.

My testbed consisted of 3 hosts that were physically fully connected.
I emulated an asymmetric bad link by iptables, dropping all packets in
one direction.
(Practically I dropped packets in the INPUT chain of a host arriving
with the MAC address of another host.)
I experienced the following.

Let our 3 hosts be A, B, and C and the bad link A -> C (so C drops the
packets that come from A).
The problem is that olsrd running on A cannot find the route to C, so
the (kernel) routing table does not have an entry for C.
I find that it is because:
- topology information maintained in A is wrong, the link C->B is
missing, so the algorithm does not count with B->C link, since it has
no inverse edge
- A gets TC messages about C->B link from both B and C
- the message (about C->B link) coming from C is discarded because the
A-C link is not symmetric
- the message (about C->B link) coming from B is discarded because A
has already got a message about this link with the same seq.no (from
C).

I think the problem is that the function
olsr_shall_process_message(...) is called (in parser.c) earlier than
olsr_input_tc(...) checks (in tc_set.c) if the message comes from a
symmetric link.
So the link quality information is considered to be processed when it is not.

I have more ideas how to solve this issue but up to now none of them
is a smart way.
Should I remove the element from duplicate_set when discarding message
because of non symmetric link?
Should I put the olsr_shall_process_message call after checking link
symmetry in olsr_input_tc function (tc_set.c) and in similar places
for other message types?

Any other idea to fix...?

--
Best,
Peter Tarjan