search for: add_edg

...nc.nfp_kn_scala[2044]: Sending meta data to nfp_c_vpn (1.2.3.4 port 30665) failed: Resource temporarily unavailable Dec 13 19:17:20 gt-fw-nfp-konstanz-scala last message repeated 7 times And these are a short cut from the central box Dec 13 14:36:27 c tinc.nfp_c_vpn[17944]: Error while processing ADD_EDGE from nfp_c_rt (7.8.9.0 port 36758) Dec 13 14:36:37 c tinc.nfp_c_vpn[17944]: Error while processing ADD_EDGE from nfp_mz (8.9.0.1 port 43100) Dec 13 14:36:38 c tinc.nfp_c_vpn[17944]: Error while processing ADD_EDGE from nfp_c_luxur (3.4.5.6 port 59716) Dec 13 14:37:00 c tinc.nfp_c_vpn[17944]: Error...

...---------+--------------+ | | | vpnhub1 (1.1) igor (1.1) turing (1.0) | | | +-------------------+--------------+ | tokamak Whenever another node outside of the graph connects to vpnhub or igor I receive a huge amount of "Got ADD_EDGE from ... which does not match existing entry" log entries (log level 3) (huge amount == at least 3 or 4 per edge direction in the network) After extending the debug log messages a bit I can see that it is always about the local_address field - essentially switching from an IP to unknown...

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 1.1 nodes pass on the local_address, > but the 1.0 nodes (as they don't know that field) do no...

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 address 2.3.4.5 > > != unknown) > > > > What I think may happen is that the 1.1 nodes pass on the local_address, > > but the 1.0 nodes (as they don'...

...gt; 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 were cuased by different weight received > by add_edge_h(). > > This network is consists of ~4 hub nodes and 50+ leaf nodes. Sample > hub config: [...] Could...

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 were cuased by different weight received by add_edge_h(). This network is consists of ~4 hub nodes and 50+ leaf nodes. Sample hub config: Name = hub1 ConnectTo = hub2 ConnectT...

...10 1ad9c3b6 atlas 10.0.5.2/32#10 Sending 33 bytes of metadata to adamthinkpad (199.212.67.46 port 58877) Sending ADD_SUBNET to adamthinkpad (199.212.67.46 port 58877): 10 1b36d361 atlas 2600:3c03:e000:c6:0:0:0:2a/128#10 Sending 52 bytes of metadata to adamthinkpad (199.212.67.46 port 58877) Sending ADD_EDGE to adamthinkpad (199.212.67.46 port 58877): 12 471c8561 atlas titan 2600:3c03::f03c:91ff:fe93:415a 655 300000c 35 Sending 70 bytes of metadata to adamthinkpad (199.212.67.46 port 58877) Sending ADD_SUBNET to adamthinkpad (199.212.67.46 port 58877): 10 14ffb54e calypso 10.0.5.3/32#10 Sending 35 byt...

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

...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 that are targets to ConnectTo for all other nodes, and all they are doing is processing ADD_EDGE requests. So I was thinking: 1. is it possible to start mesh vpn with only hosts file and no ConnectTo directives? 2. is it ok that nodes are sending ADD_SUBNET (it consumes cpu to process) when StrictSubnets=yes? 3. is it possible to switch off sending ADD_EDGE when DirectOnly=yes? 4. is th...

...ytes of metadata to home (47.20.123.2 port 655) Got ACK from home (47.20.123.2 port 655): 4 655 78 c Connection with home (47.20.123.2 port 655) activated Sending ADD_SUBNET to home (47.20.123.2 port 655): 10 7cad work 192.168.1.66 Sending 32 bytes of metadata to home (47.20.123.2 port 655) Sending ADD_EDGE to everyone (BROADCAST): 12 4672 work home 47.20.123.2 655 c 88 192.168.1.117 655 Sending 65 bytes of metadata to home (47.20.123.2 port 655) Got ADD_SUBNET from home (47.20.123.2 port 655): 10 3684e9eb home 192.168.11.0/24#10 Forwarding ADD_SUBNET from home (47.20.123.2 port 655): 10 3684e9eb hom...

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: http...

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 er...

...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,...

...Sending CHAL_REPLY to client1 (2.2.2.2 port 35031) Got CHAL_REPLY from client1 (2.2.2.2 port 35031) Sending ACK to client1 (2.2.2.2 port 35031) Got ACK from client1 (2.2.2.2 port 35031) Connection with client1 (2.2.2.2 port 35031) activated Sending ADD_SUBNET to client1 (2.2.2.2 port 35031) Sending ADD_EDGE to everyone (BROADCAST) Got ADD_SUBNET from client1 (2.2.2.2 port 35031) Forwarding ADD_SUBNET from client1 (2.2.2.2 port 35031) Got ADD_SUBNET from client1 (2.2.2.2 port 35031) Forwarding ADD_SUBNET from client1 (2.2.2.2 port 35031) Got ADD_EDGE from client1 (2.2.2.2 port 35031) Forwarding ADD_ED...

...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. Instead, we have an idea : would it be possible to have a option in tinc.conf like "TrustedNodes=aaa,bbb,ccc" ? With this option : (a) any ADD_EDGE/ADD_SUBNET/ANS_KEY/... will be cancelled if it comes from a non-trusted connection (b) all REQ_KEY will be sent to trusted nodes only. (a) is easy, but we do not know how to manage (b). In net_packet.c and protocol_key.c we see : send_req_key(n->nexthop->connection, myself, n);...

...>address, &address, &port); + if(foaf){ + address = xstrdup("0.0.0.0"); + port = xstrdup("0.0.0.0"); + }else{ + sockaddr2str(&e->address, &address, &port); + } + x = send_request(c, "%d %x %s %s %s %s %x %d", ADD_EDGE, rand(), e->from->name, e->to->name, address, port, diff -Nur tinc-1.0.13/src/protocol.h tinc-1.0.13-patched/src/protocol.h --- tinc-1.0.13/src/protocol.h 2010-03-13 18:53:33.000000000 +0100 +++ tinc-1.0.13-patched/src/protocol.h 2010-09-17 23:28:44.671480039 +02...

...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 all connections between all nodes of the VPN. The meta-protocol has a command called ADD_EDGE which is used to inform other nodes about existing UDP data-connections. This leads to the conclusion that 'dump edges' is used to show UDP data-connections. But as far as I can tell from my tests, these are only the TCP meta-connections. I've tried to trace the actual UDP dat...

...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...

...vate NAT between the two local nodes, but this is probably an unsolvable problem anyway since we just don't have the necessary information to make them reach each other in this case, and broadcasts obviously won't get through a NAT. I guess the local socket information could be added to ADD_EDGE messages and stored in edge_t. Thoughts? [1] http://serverfault.com/questions/72112/how-to-alter-the-global-broadcast-address-255-255-255-255-behavior-on-windows (the long discussion in the comments of the second answer are particularly interesting) -- Etienne Dechamps