tinc 1.1 "Got ADD_EDGE ... which does not match existing entry"

[Sven-Haegar Koch]

Hallo,

Another strange and difficult to understand thing - seems like all the 
easy bugs in 1.1 are gone ;)

waehring (1.1)
|
+-------------------+--------------+
|                   |              |
vpnhub1 (1.1)    igor (1.1)    turing (1.0)
|                   |              |
+-------------------+--------------+
|
tokamak

Whenever another node outside of the graph connects to vpnhub or igor I 
receive a huge amount of "Got ADD_EDGE from ... which does not 
match existing entry" log entries (log level 3)

(huge amount == at least 3 or 4 per edge direction in the network)

After extending the debug log messages a bit I can see that it is always 
about the local_address field - essentially switching from an IP to 
unknown back and forth.


Here unrelated node "vlad" connected to aaa_vpnhub1 and to igor, on 
waehring I receive for the link tokamak<->igor:

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak 
-> igor which does not match existing entry (Local address 2.3.4.5 
!= unknown)

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak 
-> igor which does not match existing entry (Local address unknown != 
2.3.4.5)

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for igor -> 
haegar_tokamak which does not match existing entry (Local address 
3.4.5.6 != unknown)

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak 
-> igor which does not match existing entry (Local address 2.3.4.5 
!= unknown)

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for igor -> 
haegar_tokamak which does not match existing entry (Local address 
3.4.5.6 != unknown)

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak 
-> igor which does not match existing entry (Local address unknown != 
2.3.4.5)

Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for igor -> 
haegar_tokamak which does not match existing entry (Local address 
unknown != 3.4.5.6)


What I think may happen is that the 1.1 nodes pass on the local_address, 
but the 1.0 nodes (as they don't know that field) do not - resulting in 
"unknown" in an ADD_EDGE message, which in turn the 1.1 nodes pass on.


Wouldn't it make sense that when the only difference between the update 
and the current edge record is the local_address, and the ADD_EDGE 
message says "unknown local_address", to not remove a perhaps 
pre-existing local_address entry, and more important to not send this 
"unknown" out again to all others, in turn making them forget about it, 
until the "unknown" ADD_EDGE reaches the node itself, which will then 
send out another ADD_EDGE with the again filled-in value?

So accepting and propagating new/different local_address from ADD_EDGE, 
but not removing the existing value if ADD_EDGE contains "unknown".

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.