Thank you for your response. Yes, I know something changed, hence the smiley. I have looked at the code (I was able to build it under the new windows bash). It turns out that the error was on a udp receive, not a tcp connection. Didn't know you would get this error. Anyhow near the location of the error there was a remark about IPv6. I hadn't looked at that yet. So I turned IPv6 off at the client that could not be reached and now it works. Maybe I should look at when and how to use IPv6 someday, when there are more than 24hs in a day. Now I'm happy it works. -----Oorspronkelijk bericht----- Van: tinc [mailto:tinc-bounces at tinc-vpn.org] Namens ???? Verzonden: maandag 26 september 2016 13:54 Aan: tinc at tinc-vpn.org Onderwerp: Re: Receiving packet failed: (10054) (2nd post) On Mon, 26 Sep 2016 07:46:36 +0000 Henk <henk at innomeer.nl> wrote:> > Hello, > > I have a problem connecting to one of my computers using tinc 1.0.x on > Windows. It used to work, now it suddenly stopped (and nothing changed > :) )When something worked for a long time but now it's not, then there was a change. It's time to determine where!> > We have a server with a known ip address and port forwarding set. > All computer connect to this server. > I can ping from my computer (laptophenk) to the server and some other > computers but not to jeffrey2015. When I set tincd to -D -d4 I get ( > I left out a lot of data of course) UDP address of vpnserver set to > ...... port 655 > > UDP address of jeffrey2015 set to ...... port 655 Got ANS_KEY from > vpnserver (..... port 655): 16 jeffrey2015 laptophenk F.....E 91 64 4 > 5 ..... 33487 Using reflexive UDP address from jeffrey2015: .... port > 33487 UDP address of jeffrey2015 set to ..... port 33487 Receiving > packet failed: (10054) An existing connection was forcibly closed by > the remote host. Receiving packet > failed: (10054) An existing connection was forcibly closed by the > remote host. Receiving packet failed: (10054) An existing connection > was forcibly closed by the remote host. Receiving packet failed: > (10054) An existing connection was forcibly closed by the remote host. > Receiving packet failed: (10054) An existing connection was forcibly > closed by the remote host.Check that your tinc keys are not damaged on both parties, and also that the host files are intact.> > I have tried to set the connection to TCPOnly (I know it is > deprecated). I don't get the error, but still can't ping jeffrey2015. > All computers are on separate internet connections behind their own > modem/router. All computers run without the Microsoft firewall, or any > other Windows firewall.Windows Firewall may place it's own rules that can ban tinc activity for no reason. Check that your network policy is correct too (home/work/public).> > Get somebody shed some light on my problem? > How can a connection be closed when all data is send using UDP? > >Tinc runs both TCP and UDP: TCP for reliable control and UDP for main traffic data. _______________________________________________ tinc mailing list tinc at tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
On Mon, 26 Sep 2016 20:40:47 +0000 Henk <henk at innomeer.nl> wrote:> Thank you for your response. > Yes, I know something changed, hence the smiley. > > I have looked at the code (I was able to build it under the new > windows bash). It turns out that the error was on a udp receive, not > a tcp connection. Didn't know you would get this error. > > Anyhow near the location of the error there was a remark about IPv6. > I hadn't looked at that yet. So I turned IPv6 off at the client that > could not be reached and now it works. > > Maybe I should look at when and how to use IPv6 someday, when there > are more than 24hs in a day. Now I'm happy it works.It should be interesting to know what exactly version of Windows runs at faulty client? And was any of IPv6 services activated on it (including Teredo)? Your tcpdump (or whatever on Windows, Wireshark?) should show ICMP Unreachable packets before that error. At least many people get this when they receive 10054 error on UDP sockets. http://stackoverflow.com/questions/34242622/windows-udp-sockets-recvfrom-fails-with-error-10054 http://stackoverflow.com/questions/2576926/python-socket-error-on-udp-data-receive-10054 So probably more workarounds for Windows. One of them is probably ignoring 10054 return value of recvfrom on Windows.
I will be more than happy to try and investigate this issue some more. The only thing I have tried is to get it to stop throwing that error. I did not take the time to see if I could get the error back by reversing the settings. I will try and do that later, when the computer concerned is not used. The 10054 error was reported on the computers (multiple) trying to connect to the computer that had the problem. The IPv6 settings where changed on the computer that had the problem. I had never heard of Teredo before (I looked it up on wikipedia). Is it started by default on Windows 10? How can I check if it is running? Would you run Wireshark on the client with the problem or on one of the other clients? Should I listen to the physical network card or to the OpenVpn card? -----Oorspronkelijk bericht----- Van: tinc [mailto:tinc-bounces at tinc-vpn.org] Namens ???? Verzonden: dinsdag 27 september 2016 05:43 Aan: tinc at tinc-vpn.org Onderwerp: Re: Receiving packet failed: (10054) (2nd post) On Mon, 26 Sep 2016 20:40:47 +0000 Henk <henk at innomeer.nl> wrote:> Thank you for your response. > Yes, I know something changed, hence the smiley. > > I have looked at the code (I was able to build it under the new > windows bash). It turns out that the error was on a udp receive, not a > tcp connection. Didn't know you would get this error. > > Anyhow near the location of the error there was a remark about IPv6. > I hadn't looked at that yet. So I turned IPv6 off at the client that > could not be reached and now it works. > > Maybe I should look at when and how to use IPv6 someday, when there > are more than 24hs in a day. Now I'm happy it works.It should be interesting to know what exactly version of Windows runs at faulty client? And was any of IPv6 services activated on it (including Teredo)? Your tcpdump (or whatever on Windows, Wireshark?) should show ICMP Unreachable packets before that error. At least many people get this when they receive 10054 error on UDP sockets. http://stackoverflow.com/questions/34242622/windows-udp-sockets-recvfrom-fails-with-error-10054 http://stackoverflow.com/questions/2576926/python-socket-error-on-udp-data-receive-10054 So probably more workarounds for Windows. One of them is probably ignoring 10054 return value of recvfrom on Windows. _______________________________________________ tinc mailing list tinc at tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
I'm sorry, but I was not able to get more data about this problem. That same day windows was updated automatically and I was not able to reproduce the problem. -----Original Message----- From: tinc [mailto:tinc-bounces at tinc-vpn.org] On Behalf Of ???? Sent: dinsdag 27 september 2016 05:43 To: tinc at tinc-vpn.org Subject: Re: Receiving packet failed: (10054) (2nd post) On Mon, 26 Sep 2016 20:40:47 +0000 Henk <henk at innomeer.nl> wrote:> Thank you for your response. > Yes, I know something changed, hence the smiley. > > I have looked at the code (I was able to build it under the new > windows bash). It turns out that the error was on a udp receive, not a > tcp connection. Didn't know you would get this error. > > Anyhow near the location of the error there was a remark about IPv6. > I hadn't looked at that yet. So I turned IPv6 off at the client that > could not be reached and now it works. > > Maybe I should look at when and how to use IPv6 someday, when there > are more than 24hs in a day. Now I'm happy it works.It should be interesting to know what exactly version of Windows runs at faulty client? And was any of IPv6 services activated on it (including Teredo)? Your tcpdump (or whatever on Windows, Wireshark?) should show ICMP Unreachable packets before that error. At least many people get this when they receive 10054 error on UDP sockets. http://stackoverflow.com/questions/34242622/windows-udp-sockets-recvfrom-fails-with-error-10054 http://stackoverflow.com/questions/2576926/python-socket-error-on-udp-data-receive-10054 So probably more workarounds for Windows. One of them is probably ignoring 10054 return value of recvfrom on Windows. _______________________________________________ tinc mailing list tinc at tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc