similar to: Compression issue in 1.1pre11

You have a typo in your routes: fd80:2015:2105:adcd::/6 abcd vs. adcd On 21 May 2015, at 19:35, Martin <martinmoen at gmail.com<mailto:martinmoen at gmail.com>> wrote: I have 2 nodes nodeA and nodeB I'm using tinc 1.1pre11 -- nodeA(fd80:2015:2105:abcd::1) : $ ip -6 route fd80:2015:2105:abcd::1 dev tun0 proto kernel metric 256 fd80:2015:2105:adcd::/64 dev tun0 metric 1024

I have 2 nodes nodeA and nodeB I'm using tinc 1.1pre11 -- nodeA(fd80:2015:2105:abcd::1) : $ ip -6 route fd80:2015:2105:abcd::1 dev tun0 proto kernel metric 256 fd80:2015:2105:adcd::/64 dev tun0 metric 1024 fe80::/64 dev eth0 proto kernel metric 256 $ ping6 fd80:2015:2105:abcd::1 PING fd80:2015:2105:abcd::1(fd80:2015:2105:abcd::1) 56 data bytes 64 bytes from fd80:2015:2105:abcd::1:

Guus, i wonder if you have had a moment to have a look at the compression issue? Thanks a lot! Peter -----Original Message----- From: tinc [mailto:tinc-bounces at tinc-vpn.org] On Behalf Of Guus Sliepen Sent: Thursday, December 29, 2016 1:15 PM To: tinc at tinc-vpn.org Subject: Re: Compression not working between 1.1pre11 and 1.1pre14 On Thu, Dec 29, 2016 at 12:47:15PM -0000, Peter Schulze

On Thu, Dec 29, 2016 at 12:47:15PM -0000, Peter Schulze wrote: > It appears that a 1pre14 client cannot talk to a 1.1pre11 server with > compression enabled, even though the tunnel is being established with no > errors. Hm, nothing really changed wrt. compression between pre11 and pre14. I'll have to investigate to see what the problem is. -- Met vriendelijke groet / with kind

Hello! I'm trying to make a wireless mesh network with b.a.t.m.a.n. protocol, and I would like to secure the wireless links with tinc. My test network is 2 wireless routers with OpenWRT Kamikaze firmware, and the network topology is the following: |CLIENT|eth0: 192.168.180| <--> |eth0: 192.168.1.1|MESH-NODE|ath0: 192.168.5.54| <~~> |ath0: 192.168.5.51|GW|eth1: 192.168.1.51|

Sorry for the delayed response: been a busy weekend. SCTP looks very promising, and would make a hopefully stable mesh: I agree with your assessment in that regard vs optimized UDP setups. http://en.wikipedia.org/wiki/SCTP As for my request for improved compression, the "zpipe" implementation looks promising, as it is a high-level streaming compressor. I know most of the developers

I did notice the that interface we have named br-lan did not have the proper broadcast and netmask information. I adjusted that and it looks like its now connecting but still running into issues. Here is a snipet from the new system we are trying to connect in (from the /var/log/tinc.log file) 2018-03-15 22:57:26 tinc.NETNAME[871]: Read packet of 74 bytes from Linux tun/tap device (tun mode)

Hello I have currently a larger network deployed using 1.1pre11. I have now tried to use 1.1pre14 on a remote system, but I have problems to make it work with compression enabled. It appears that a 1pre14 client cannot talk to a 1.1pre11 server with compression enabled, even though the tunnel is being established with no errors. I have tried both lzo and zlib with various levels, none works.

Hi, Hopefully someone can help me. I've been trying to set up a private vpn, for both internal ipv6 and ipv4 traffic. There are two Hosts involved with the vpn at the moment. I've been struggling with this but am now going round in circles - Can anyone recognise and explain what i'm doing wrong? The tinc daemons are listening on an ipv4 address, connected to the standard

Guus Sliepen [2016-05-24 11:26 +0200] : > On Tue, May 24, 2016 at 08:17:07AM +0200, Niklaas Baudet von Gersdorff wrote: [...] > > A $ cat /usr/local/etc/tinc/klaas/tinc-up > > ifconfig $INTERFACE inet6 fd16:dcc0:f4cc:0:0:1:0:1 prefixlen 80 > > route -6 add -host fd16:dcc0:f4cc:0:0:2:0:1 fd16:dcc0:f4cc:0:0:1:0:1 > > route -6 add -net

I'm been experiencing a very very odd problem for the past several weeks and am throwing it out in case someone can shed some light on it for me. There is a single box on our tinc mesh which can be pinged from all hosts, but cannot ping any. It is not limited to ping, the box cannot communicate over tinc. tinc is running in router mode for this mesh. ~30 other nodes function normally,

I am looking to connect edge-routers in a VPN over the Internet, with requirement: - Mesh - NAT-traversing - 500 mbit throughput. I'm using Tinc 1.0.23 and it does this very nicely (I think I could also use 1.1, once it's considered stable) except for the througphut: the edgerouters cannot encrypt this fast. So I want to relieve the edge routers from this responsibility. If the end hosts

Hi there, we're using tinc to mesh together hosts in a public datacenter (instead of using a private VLAN, sort of). So all hosts are reasonably modern; connections are low latency with an available bandwith of around 500Mbit/s or 1Gbit/s (depending on how close they are to each other). Iperf between two nodes directly reports around 940Mbit/s. The CPUs are Intel(R) Core(TM) i7-4770 CPU @

tinc uses direct UDP communication for performance, not reliability. If you want to establish more metaconnections for increased reliability, you can use AutoConnect (though it probably won't work across NATs). A better solution is to use two central nodes (instead of one) for redundancy. On 11 June 2015 at 18:59, Daniel J. Grinkevich <danielgrinkevich at gmail.com> wrote: > If we

Hi everyone. I'm wondering whether a setup like the one described below would be possible with Tinc: nodeA1 nodeB3 | | (Network A) --- [GWA] --- (Internet) --- [GWB] --- (Network B) | | nodeA2

i need forwarding off , cause i need a central node , which is connected directly to all the network , directly , so it can usually upload content directly , without slowing down other nodes in the network , i also don't want it to act as a forwarder , since ,it only has 2mbps of bandwidth , and i don't want it for that purpose , is there any other way to fix this problem ? On 16 March

I run tinc on a series of routers running 3rd party firmware (tomato). Since tinc is running on the gateway device, its routing table is aware of the mesh vpn. At each endpoint, any device one subnet can access any device on another subnet. I now have the situation where I need to make a new endpoint and entire subnet available on the mesh. In this situation I have a device running tinc

Hello everyone. First of all, i congratulate tinc and its community for such reliable tool it is. I am working on a community wireless project where we have an isolated mesh network that we want to link by VPN. In order to fulfill this requirement we setup a tinc VPN, with two "nodes", servera and serverb. Servera has ip 10.0.0.1/24 and serverb has 10.0.0.2/24, and a spare network

Hi. I read that one feature of tink vpn solution is the Automatic Full Mesh Routing support that is defined as: "regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate" hops. What this means? I don't understand how this work. Can you please give me some

Hi, I've got a four site site-to-site tinc mesh working nicely. I have the following systems at two of those sites: 10.a.a.2: Linux box running tinc and DHCP/DNS for site A 10.a.a.dhcp: Windows desktop with a GPU 10.b.b.2: Linux box running tinc and DHCP/DNS for site B 10.b.b.dhcp: Linux laptop I'd like to use Steam In-Home Streaming to game in the laptop streaming from the desktop. The