I managed to fix the issue by building my own Windows binaries from the
original release-1.1pre10 tag (with the addition of the build fix in
9f7e2df). Surprisingly, the binaries that I obtained seem to work
correctly, despite me making no changes to the source code.
Therefore I believe a mistake was made when building the official
Windows package for 1.1pre10 - most likely it was built from the wrong
source.
Here's the binaries I built while we wait for the official fix:
https://drive.google.com/file/d/0B4SHVPm2DfK5V09sV1QydUZEQVE/edit?usp=sharing
On 21/06/2014 16:39, Etienne Dechamps wrote:> Hi,
>
> I was previously using tinc-1.1pre8 and it worked just fine, but after
> upgrading to tinc-1.1pre10 my Windows machine is unable to connect to my
> tinc network, as it fails to complete the handshake.
>
> Steps to reproduce:
> - Set up a Linux node with tinc-1.1pre10 using "tinc init"
> - Set up a Windows node with tinc-1.1pre10 using "tinc init", and
try to
> make it connect to the Linux node
>
> The Windows node will be unable to connect. Here's an example with
> "pegasus" as the Windows (client) node and "zyklos" as
the Linux
> (server) node:
>
> ### pegasus (Windows) SIDE ###
>
> tincd 1.1pre10 (Feb 7 2014 22:45:15) starting, debug level 5
> {79D0E1D7-EAA8-442D-BC16-E4FBAEA3E3C2} (Longcat) is a Windows tap device
> Tap reader running
> Listening on :: port 655
> Listening on 0.0.0.0 port 655
> Ready
> Trying to connect to zyklos (10.172.1.1 port 655)
> Connected to zyklos (10.172.1.1 port 655)
> Sending ID to zyklos (10.172.1.1 port 655): 0 pegasus 17.3
> Sending 15 bytes of metadata to zyklos (10.172.1.1 port 655)
> Got ID from zyklos (10.172.1.1 port 655): 0 zyklos 17.3
> Broadcasting packet of 149 bytes from pegasus (MYSELF port 655)
> Sending ACK to zyklos (10.172.1.1 port 655): 4 655 24 300000c
> Sending 17 bytes of metadata to zyklos (10.172.1.1 port 655)
> Error while decrypting: error:00000000:lib(0):func(0):reason(0)
> Failed to decrypt record
> Closing connection with zyklos (10.172.1.1 port 655)
> Could not set up a meta connection to zyklos
>
> ### zyklos (Linux) SIDE ###
>
> tincd 1.1pre10 (Jun 21 2014 11:54:28) starting, debug level 5
> /dev/net/tun is a Linux tun/tap device (tun mode)
> Listening on 0.0.0.0 port 655
> Listening on :: port 655
> Executing script tinc-up
> Unconfigured tinc-up script, please edit
> /usr/local/tinc/etc/tinc/sandbox/tinc-up!
> Ready
> Connection from 10.172.1.2 port 12976
> Sending ID to <unknown> (10.172.1.2 port 12976): 0 zyklos 17.3
> Sending 14 bytes of metadata to <unknown> (10.172.1.2 port 12976)
> Got ID from <unknown> (10.172.1.2 port 12976): 0 pegasus 17.3
> Sending ACK to pegasus (10.172.1.2 port 12976): 4 655 17 300000c
> Sending 17 bytes of metadata to pegasus (10.172.1.2 port 12976)
> Got ACK from pegasus (10.172.1.2 port 12976): 4 655 24 300000c
> Connection with pegasus (10.172.1.2 port 12976) activated
> Sending ADD_EDGE to everyone (BROADCAST): 12 340155a3 zyklos pegasus
> 10.172.1.2 655 300000c 20
> Sending 53 bytes of metadata to pegasus (10.172.1.2 port 12976)
> Connection closed by pegasus (10.172.1.2 port 12976)
> Closing connection with pegasus (10.172.1.2 port 12976)
>
> Additional information:
> - I can confirm that zyklos (Linux) behaves correctly: if I connect to
> it from another Linux node it works fine (and the other way as well).
> Therefore the problems seems to be on pegasus (Windows) side.
> - Both sides are using freshly generated keys. Generating the Windows
> keys on the Linux box does not solve the problem, so it doesn't seem to
> be a problem with key generation.
> - The error message points strongly to a problem with the keys
> themselves, but I triple-checked that everything was consistent (no
> mixing of public/private keys and checksum-identical public key files on
> both sides).
> - On zyklos (Linux), tinc was compiled from source from the
> "release-1.1pre10" git tag. On pegasus (Windows) tinc was
installed from
> the downloadable package.
> - From where I'm standing this looks like a Windows-only regression
> between 1.1pre8 and 1.1pre10.
>
--
Etienne Dechamps