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/
On Mon, Jan 27, 2003 at 12:01:15AM +0100, Joop Susan wrote: [...]> Bogus data received from helix (192.168.192.20 port 33105) > Closing connection with helix (192.168.192.20 port 33105)Receiving bogus data during authentication almost certainly means something is wrong with the keys. Either you misspelled "PrivateKeyFile" as "PrivateKey" in tinc.conf, or you copied the host configuration files with the public keys in the wrong way (make sure they are identical with md5sum).> [ 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. ]We used the fact that most libc's printf() function accept NULL pointers for %s. The (null) is the name of the other tinc daemon, which isn't known until the ID message has been sent. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20030127/c6602b3f/attachment.pgp