tinc devel - May 2015 - tinc 1.1 "Got ADD_EDGE ... which does not match existing entry"

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.

On Fri, May 15, 2015 at 10:26:46PM +0200, Sven-Haegar Koch wrote:
> Another strange and difficult to understand thing - seems like all the 
> easy bugs in 1.1 are gone ;)
[...]
> 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)
> 
> 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?
It seems you have a perfect understanding of this bug, so perhaps it was
not so difficult to understand after all? Fix committed :)

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150515/54fe597b/attachment.sig>

On Fri, 15 May 2015, Guus Sliepen wrote:
> On Fri, May 15, 2015 at 10:26:46PM +0200, Sven-Haegar Koch wrote:
> 
> > Another strange and difficult to understand thing - seems like all the
> > easy bugs in 1.1 are gone ;)
> [...]
> > 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)
> > 
> > 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?
> 
> It seems you have a perfect understanding of this bug, so perhaps it was
> not so difficult to understand after all? Fix committed :)
This change is not so good:

Connection with aaa_vpnhub1 (1.2.3.4 port 443) activated
Error while translating addresses: ai_family not supported

(And then the tinc process exists)

c'ya
sven-haegar

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