similar to: Invalid packet seqno: 58073 != 0 from host5

On Mon, Feb 22, 2016 at 11:46:28AM +0100, Florent B wrote: > I still have this "bug"... any idea of what's going wrong ? There are some situations where keys are being renegotiated that can cause two peers to be very briefly out of sync. If that happens when there is VPN traffic, it could cause that message to pop up. If it only happens once in a while and you don't notice

It's not. In fact it's explicitly telling you that it's *not* forwarding. On 22 December 2015 at 15:55, Florent B <florent at coppint.com> wrote: > Hi, > > I have a lot of messages like this in my Tinc 1.1-git log : > > Sending packet from host5 (MYSELF port 655) to host4 (192.168.0.4 port > 655) via host4 (192.168.0.4 port 655) (UDP) > > Is it expected ?

Hi all, I have two nodes, connected to a switch, using Tinc 1.1 from git. They connect each other with sptps, and to other nodes in the Internet with old protocol because they have Tinc 1.0. There is no problem with remote nodes, but between my 2 local nodes, they see 1518 PMTU. But local network is 1500 MTU !!! So nodes can ping each other but larger data does not go. test1=sllm1 test2=sllm2

On 7 December 2015 at 17:20, Florent B <florent at coppint.com> wrote: > I have a cluster of 5 nodes, running Proxmox 4, and Tinc as "virtual > switch" for my nodes : on each node, a bridge "vmbr1" where Tinc is > connected, provides me a secured network for my VMs (connected to that > bridge). > > When I move (hot move) a VM from a host to another, I

You could remove them with sieve in the latest version of pigeonhole. On Mar 24, 2015 7:33 AM, Florent B <florent at coppint.com> wrote: > > I know about RFC's, but that could be an option, not enabled by default.

Thank you for your report, we'll look into it! Aki > On December 27, 2017 at 8:16 PM Florent B <florent at coppint.com> wrote: > > > Hi, > > This repository does not work with Aptly. > It seems "architecture" line is wrong in InRelease file (needs to be > "Architectures:" instead of "Architecture:"). > And

Hello Florent, How did you proceed with the upgrade? Did you follow the recommended steps guide to upgrade ceph? (mons first, then OSDs, then MDS) Did you interrupt dovecot before upgrading the MDS specially? Did you remount the filesystem? Did you upgrade the ceph client too? Give people the complete scene and someone might be able to help you. Ask on ceph-users list too. Regards, Webert

On 11 April 2018 at 11:30, Hans de Groot <hansg at dandy.nl> wrote: > Hello again :) > > Thank you all for your reply's. Below are the config files of the 3 hosts. > I use tinc in router mode. I do not have a kernel mode config lines > anywhere so tinc must be using the default settings here. > > I added the ipaddressx to subnets on hostc and this works. Traffic

> On October 20, 2017 at 12:37 PM Florent B <florent at coppint.com> wrote: > > > Hi, > > We use Dovecot packages from http://xi.dovecot.fi/debian/. > > Could it be possible to serve it with HTTPS ? > > Thank you. > > Florent Hi! It has now https enabled with valid certificate. Aki

On Mon, Dec 7, 2015 at 7:20 PM, Florent B <florent at coppint.com> wrote: > Hi everyone, > > I already posted about this issue, but I can't find the old thread. > > I have a cluster of 5 nodes, running Proxmox 4, and Tinc as "virtual > switch" for my nodes : on each node, a bridge "vmbr1" where Tinc is > connected, provides me a secured network

why dont you place a service dependency on your tinc service init/systemd files to depend on your fuse/mount service? On Tuesday, 23 August 2016, Florent B <florent at coppint.com> wrote: > Hi everyone, > > I have a special setup were hosts files of Tinc are stored in a > directory mounted by fuse and shared across my hosts (Proxmox /etc/pve). > > On boot, sometimes Tinc

Try to disable ExperimentalProtocol. Florent B <florent at coppint.com> 于2018年8月10日周五 下午9:16写道： > > Hi, > > Is it possible to completely disable encryption with Tinc 1.1 ? > > I set in my configuration : > > ExperimentalProtocol = no > Cipher = none > Digest = none > > But it does not seem to disable encryption (same performance). > > Is it possible

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.

seems that you want your others services to depend on tinc, and not to set tinc to stop after the network has stopped On Wednesday, 24 August 2016, Florent B <florent at coppint.com> wrote: > Hi everyone, > > On many systems (Debian Jessie, Tinc 1.1 from git) using unit file > provided in git, I can see that when I "reboot", Tinc seems to stop > before others

You might want to try with https://github.com/gsliepen/tinc/pull/120 - that said, this bug probably doesn't explain everything because tinc is supposed to log a message from setup_vpn_in_socket() anyway, but there's no such message in your log. In addition, I really don't see any way the "Received UDP packet from unknown source" message could be logged if the UDP socket

Hi guys, I have now done the obvious - swapped out the kernel. Upgrading to 4.5.7 fixed the problem! udp UNCONN 0 1408 *:655 *:* users:(("tincd",pid=3242,fd=7)) tcp LISTEN 0 3 *:655 *:* users:(("tincd",pid=3242,fd=6)) Thank you very much for your time. Petr On Fri, Jul 15, 2016 at 7:22 AM,

Hi Etienne, I tried the patch, no change at all. Attached is a new log and also strace log. There is a FD 7 opened (the UDP socket), used and yet "ss -nlptu" doesn't see it. I have a suspicion now there is something wrong with the distro/kernel. As a test: netcat -ul -p600 ss -nlptu | grep netcat gives me no output... Petr On Thu, Jul 14, 2016 at 8:27 PM, Etienne Dechamps

Hi Guillermo, Yes, I've also noticed there are still issues with resuming from standby on Windows, despite the latest fixes that I wrote (which are included in 1.1pre15). I think my fixes covered some of the causes of tinc misbehaving on standby, but not all of them. Are you able to reproduce the issue reliably? If so, can you please file an issue at https://github.com/gsliepen/tinc/issues

Hi Guillermo, Yes, I've also noticed there are still issues with resuming from standby on Windows, despite the latest fixes that I wrote (which are included in 1.1pre15). I think my fixes covered some of the causes of tinc misbehaving on standby, but not all of them. Are you able to reproduce the issue reliably? If so, can you please file an issue at https://github.com/gsliepen/tinc/issues

On 6 September 2017 at 10:47, Guillermo Bisheimer <gbisheimer at bys-control.com.ar> wrote: > Hi Etienne, > > I will try to reproduce the issue, as it not always happen. Just sometimes. Right, that matches my experience. > The TAP driver I have installed in the Tinc folder is version 9.0.0.8 > according to the .inf file included. > > Should I test with driver 9.0.0.9?