similar to: Receiving packet failed: (10054)

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 :) ) 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

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

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

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

I would like to discuss the following commit: https://github.com/gsliepen/tinc/commit/4a0b9981513059755b9fd15b38fc198f46a0d6f2 ("Determine peer's reflexive address and port when exchanging keys") This is a great feature as it basically allows peers to do UDP Hole Punching (via MTU probes) even when both are having their source ports rewritten by a NAT, which is extremely useful.

Hi. I have few questions out of curiosity.. Cant help for now with your problem... What version is crashing? 1.1 or 1.0 ? How your network is segmented..? I use tinc myself here a lot too (1.0) but my network is very segmented. I use switch mode and handle routing myself, so mesh links arent large.. I would NOT go beyond 30 nodes for full auto-mesh.. its already like 435 edges... Regards,

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

Hello. Finally I discovered the mailinglists and subscribed. Before, I were in #tinc, pinging guus all the time with various stuff/problems/patches/etc. So... the problems, in no particular order. 1) Quite often, after re-starting a client (I run in tunnelserver mode), no packets are flowing. Tcpdump shows packets being sent from client but nothing gets received, and on the server both send

Thanks for answers. I think its now flaw.. but design.. Tinc auto-mesh is very very handy. You just need to avoid flat networks. There is also IndirectMode w/ forces nodes to be switched by intermediate node... but I would be cautionus how its used. I use it myself for certain nodes behind NATs where they cannot be connected to, so always connect node handles switching for them. You noticed it

I'm having a trouble. I use winXP to connect through L2TP/IPsec to one Linux server. When I try to connect in my domain appear an error at log. Plugin winbind.so loaded. WINBIND plugin initialized. using channel 36 Using interface ppp1 Connect: ppp1 <--> /dev/pts/3 sent [LCP ConfReq id=0x1 <mru 1410> <asyncmap 0x0> <auth chap MD5> <magic 0x564e3dc9>

Hi all, I have a network with about ~800. The network is a mix of tinc 1.0 and 1.1 nodes. It is gradually expanding for several years now. The problem is that at some point it seams the daemon can not handle the processing of the new connection and the edges. There are 3 major nodes in the system and every other node initially makes connection to one of them. Now after a lot of debugging

Hello, I have been reading through the documentation and trying to set up a very small VPN as a test for a larger rollout that I would like to complete in the future but cannot get this working. The configuration seems like it should be relatively simple, so I'm most likely missing something basic but I just cannot see what I'm doing wrong. At the moment I am trying to get this working

> - Indirectdata finally REALLY REALLY works now! > - More precise debug messages Hmmm ... I can't prove that using the CVS code I checked out this morning. Everything works like yesterday: I can ping the peer but I canot go beyond: *** SERVER *** Jun 27 09:04:56 lemon tinc.9[10186]: tincd 1.0pre3 (Jun 27 2000 08:53:56) startin g, debug level 4 Jun 27 09:04:56 lemon tinc.9[10186]:

Hi, I've been running tinc for a couple of months and it's great, but I have a periodic problem which maybe you guys can figure out. I operate a 3-node tinc VPN, lets say A, B and C. A / \ B --- C The problem is that after a while, node C can't exchange data with node B. It works fine (ping and other traffic) for about 10 minutes, then fails. Here is some debug

Hi, thank for getting back. I'll answer the questions, but I've already gave up on tinc and switch to zerotier-one. On 2020-07-27 5:10 p.m., borg at uu3.net wrote: > Hi. I have few questions out of curiosity.. Cant help for now with > your problem... > > What version is crashing? 1.1 or 1.0 ? 1.1 is crashing > > How your network is segmented..? > I use tinc myself

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

using 1.0pre5 A: tinc.conf ------------ Name = A PrivateKeyFile = /usr/local/etc/tinc/vpn/rsa_key.priv Device = /dev/tap0 ConnectTo = B A: tinc-up --------- #!/bin/sh modprobe ethertap ifconfig tap0 hw ether fe:fd:00:00:00:00 ifconfig tap0 192.168.0.3 netmask 255.255.0.0 ifconfig tap0 -arp B: tinc.conf ------------ Name = B PrivateKeyFile = /usr/local/etc/tinc/vpn/rsa_key.priv Device =

Here are a few facts that should make things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of

Hi, We want to deploy a tinc VPN, with more than 50 sites connected all arround the world. But we cannot trust all our sites with the same level, so the tinc solution (automatic full mesh) is "too automatic" for us : *any* node can add a new node which will be connected directly to others. A solution could be TLS (signing public keys), but create a PKI is another issue for us.

Hello! I have encountered a bug using tincd with Microsoft Windows: Below you'll find my Setup and my Logs. In short, i do the following: 1. office running tincd 1.0.7 and waiting for connections (no ConnectTo, but this does not resolve the issue) 2. the supporter starts up tincd 1.0.7 on windows (native) 3. ping from windows ("support") to the office: Here the error occours: