Bogus data received from ...

[Joop Susan]

Hello,

I'm trying to test a tinc vpn between two Linux hosts on the same ethernet.

If I start tinc on both sides as 'tinc -n test --bypass-security --debug=5'
I can ping both machines from each other and tcpdump shows that the packets
pass through the tun-device created by tinc.

Connection from 192.168.192.17 port 32852
Sending ID to (null) (192.168.192.17 port 32852): 0 helix 17
Sending 11 bytes of metadata to (null) (192.168.192.17 port 32852)
Got ID from (null) (192.168.192.17 port 32852): 0 crux 17
Sending ACK to crux (192.168.192.17 port 32852): 4 655 0 0
Sending 10 bytes of metadata to crux (192.168.192.17 port 32852)
Got ACK from crux (192.168.192.17 port 32852): 4 655 1 0
Connection with crux (192.168.192.17 port 32852) activated
Sending ADD_SUBNET to crux (192.168.192.17 port 32852): .....
Sending 35 bytes of metadata to crux (192.168.192.17 port 32852)
Sending ADD_EDGE to everyone (BROADCAST): 12 2650c921 helix crux .....
Sending 46 bytes of metadata to crux (192.168.192.17 port 32852)
Got ADD_SUBNET from crux (192.168.192.17 port 32852): 10 .....
Forwarding ADD_SUBNET from crux (192.168.192.17 port 32852): .....
Got ADD_EDGE from crux (192.168.192.17 port 32852): 12 .....
Forwarding ADD_EDGE from crux (192.168.192.17 port 32852): .....
Node crux (192.168.192.17 port 655) became reachable
Read packet of 98 bytes from Linux tun/tap device
Sending packet of 98 bytes to crux (192.168.192.17 port 655)
No valid key known yet for crux (192.168.192.17 port 655), queueing packet
Sending REQ_KEY to crux (192.168.192.17 port 32852): 15 helix crux
Sending 14 bytes of metadata to crux (192.168.192.17 port 32852)
Got ANS_KEY from crux (192.168.192.17 port 32852): 16 .....
Flushing queue for crux (192.168.192.17 port 655)
Got REQ_KEY from crux (192.168.192.17 port 32852): 15 crux helix
Sending ANS_KEY to crux (192.168.192.17 port 32852): 16 .....
Sending 73 bytes of metadata to crux (192.168.192.17 port 32852)
Received packet of 98 bytes from crux (192.168.192.17 port 655)
Writing packet of 98 bytes to Linux tun/tap device
Read packet of 98 bytes from Linux tun/tap device

However is I start tinc as 'tinc -n test --debug=5' the connection fails.
The log shows messages like:

Connection from 192.168.192.20 port 33105
Sending ID to (null) (192.168.192.20 port 33105): 0 crux 17
Sending 10 bytes of metadata to (null) (192.168.192.20 port 33105)
Got ID from (null) (192.168.192.20 port 33105): 0 helix 17
Sending METAKEY to helix (192.168.192.20 port 33105):  ........
Sending 269 bytes of metadata to helix (192.168.192.20 port 33105)
Got METAKEY from helix (192.168.192.20 port 33105):  ........
Sending CHALLENGE to helix (192.168.192.20 port 33105): ........
Sending 259 bytes of metadata to helix (192.168.192.20 port 33105)
Bogus data received from helix (192.168.192.20 port 33105)
Closing connection with helix (192.168.192.20 port 33105)

[ Are those (null)s debugging code buglets or unavoidable? Looks like
protocol.c:85 when request is 'ID' and the port is not 'Port', but the
originating high port number and meta.c:51. ]

My question is: what causes the bogus data warning and subsequent closing
of the connection.

Could this be a configuration problem? Does this mean that there is a
problem with the keys or is there a protocol error of some sort or an OS or
SSL incompatibility. The hosts/* files are identical on both sides and the
keys were generated with 'tincd -n test -K'.

I've got the configuration and full logs saved, but it is a 30 Kb file
with long lines, which I won't attach unless requested.

Any hint appreciated.

Joop

Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/