search for: add_edges

Hello, we currently set up a large tinc network with 2 central Nodes (these nodes connecting to each other). All satellites (ca 40) connect to these both machines. All containing two ConntectTo fields (for backup) e.g. (satellite) Name = nfp_hy Device = /dev/tun PrivateKeyFile = /etc/tinc/nfp_hy/rsa_key.priv ConnectTo = nfp_f_vpn ConnectTo = nfp_c_vpn If the count of satellites reaches

Hallo, Another strange and difficult to understand thing - seems like all the easy bugs in 1.1 are gone ;) waehring (1.1) | +-------------------+--------------+ | | | vpnhub1 (1.1) igor (1.1) turing (1.0) | | | +-------------------+--------------+ | tokamak Whenever another node outside of the graph connects to vpnhub or igor

On Fri, May 15, 2015 at 10:26:46PM +0200, Sven-Haegar Koch wrote: > Another strange and difficult to understand thing - seems like all the > easy bugs in 1.1 are gone ;) [...] > Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak > -> igor which does not match existing entry (Local address 2.3.4.5 > != unknown) > > What I think may happen is that the

On Fri, 15 May 2015, Guus Sliepen wrote: > On Fri, May 15, 2015 at 10:26:46PM +0200, Sven-Haegar Koch wrote: > > > Another strange and difficult to understand thing - seems like all the > > easy bugs in 1.1 are gone ;) > [...] > > Got ADD_EDGE from aaa_vpnhub1 (1.2.3.4 port 443) for haegar_tokamak > > -> igor which does not match existing entry (Local

On Tue, Dec 11, 2018 at 02:36:18PM +0800, Amit Lianson wrote: > We're suffering from sporadic network blockage(read: unable to ping > other nodes) with 1.1-pre17. Before upgrading to the 1.1-pre release, > the same network blockage also manifested itself in a pure 1.0.33 > network. > > The log shows that there are a lot of "Got ADD_EDGE from nodeX >

Hello, We're suffering from sporadic network blockage(read: unable to ping other nodes) with 1.1-pre17. Before upgrading to the 1.1-pre release, the same network blockage also manifested itself in a pure 1.0.33 network. The log shows that there are a lot of "Got ADD_EDGE from nodeX (192.168.0.1 port 655) which does not match existing entry" and it turns out that the mismatches

Hello tincers, I run a small tinc mesh using version 1.1pre10 on mostly linux (debian) hosts. In the past, I was able to successfully join my windows machine to the tinc network, when I was running an earlier version of tinc (throughout the mesh). However, with 1.1pre10, I have had no success. Is this a known error, a misconfiguration on my part, or some other issue? I currently have no tinc-up

On Sat, May 16, 2015 at 12:09:52AM +0200, Sven-Haegar Koch wrote: > This change is not so good: > > Connection with aaa_vpnhub1 (1.2.3.4 port 443) activated > Error while translating addresses: ai_family not supported > > (And then the tinc process exists) Hm, I couldn't reproduce it, but I committed a fix anyway that makes sockaddr2str() handle AF_UNSPEC addresses. It

On Sat, 16 May 2015, Guus Sliepen wrote: > On Sat, May 16, 2015 at 12:09:52AM +0200, Sven-Haegar Koch wrote: > > > This change is not so good: > > > > Connection with aaa_vpnhub1 (1.2.3.4 port 443) activated > > Error while translating addresses: ai_family not supported > > > > (And then the tinc process exists) > > Hm, I couldn't reproduce

Hello, I am tying to create tinc vpn for the ~1000 nodes and was thinking why meta connections are needed at all if I only need static configuration where every node knows addresses of other hosts and due to the amount of traffic any indirect connections will not work, so DirectOnly=yes is a must and then passing around routing information is not needed, right? Currently I have 10 nodes

Hi there I have the following setup Home - Main Tinc server with public IP running on PfSense work - tinc client running behind a CISCO ASA firewall with public IP running on Windows 10 offsite - tinc client running on tomato router behind a double NAT Home & offsite connect & i can see all PCs & devices & connect to them easily, on either side work to Home or offsite connects

Hi, I am running R 3.3.3 and getting the following error: Error in add_edges(res, edges = t(as.matrix(el[, 1:2])), attr = weight) : long vectors not supported yet: ../../src/include/Rinlinedfuns.h:138 when passing a 13 GB TransitionLayer object to shortestPath from the package 'gdistance'. The error, albeit in a different context, is discussed here: https:...

Hi Jeff, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> writes: >> Hi, >> >> I am running R 3.3.3 and getting the following error: >> >> Error in add_edges(res, edges = t(as.matrix(el[, 1:2])), attr = weight) >> : >> long vectors not supported yet: ../../src/include/Rinlinedfuns.h:138 >> >> when passing a 13 GB TransitionLayer object to shortestPath from the >> package 'gdistance'. >> >> The erro...

...their development repository (R-forge, though it looks unused). -- Sent from my phone. Please excuse my brevity. On February 14, 2018 7:43:51 AM PST, Loris Bennett <loris.bennett at fu-berlin.de> wrote: >Hi, > >I am running R 3.3.3 and getting the following error: > >Error in add_edges(res, edges = t(as.matrix(el[, 1:2])), attr = weight) >: > long vectors not supported yet: ../../src/include/Rinlinedfuns.h:138 > >when passing a 13 GB TransitionLayer object to shortestPath from the >package 'gdistance'. > >The error, albeit in a different context, i...

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

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.

Hi! here a little patch for darknet functionality, i hope it does what its intended for sufficiently ... but it seems to work :). what should it do? imagine your friend-network. A trusts B and C. B trusts D and E, D trust F, C trusts G. All trust relationships are mutal A <---> C <---> G ^ \ \-----> B <---> D <---> F ^ \ \---> E

Hi, I'm using Tinc in a scenario where round-trip time matters. I've multiple nodes behind firewalls (with and without NAT) and a single public server node. How do I can get the current state of UDP data-connections between my firewall'd nodes? According to the docs: - 'dump connections' give me all TCP meta-connections of the current node - 'dump edges' give me

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

LocalDiscovery works by sending some of the MTU probe packets to the broadcast address (255.255.255.255). If the destination node receives one of these packets, it will update its UDP cache and reply, thus the two nodes will start using their local addresses to communicate. Now, I see two problems with this approach: - In case the two nodes are behind the same NAT and can reach other *but*