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

This smells like https://github.com/gsliepen/tinc/pull/104 - are you sure you're using latest HEAD? How often does this occur? Does it correlate with other events such as nodes joining or leaving? Does it occur more often if you reduce the value of KeyExpire? On 22 December 2015 at 16:10, Florent B <florent at coppint.com> wrote: > Hi, > > With latest Tinc 1.1 git code, I have

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, I just upgraded my entire environment from Tinc 1.0.24 (or prior) to the most recent version from git (1.1pre10+), using ED25519. Sometimes, especially after some failed authentication attempts or timed out authentications, I get the following log messages: 2014-08-11 21:51:10 tinc.NNN[3376]: Connection with XXX (1.2.3.4 port 1) activated 2014-08-11 21:51:10 tinc.NNN[3376]:

On Thu, Mar 10, 2016 at 12:30 PM, Osiris <dovecot at flut.demon.nl> wrote: > On 09-03-16 13:14, djk wrote: >> On 09/03/16 10:44, Florent B wrote: >>> Hi, >>> >>> I don't see any SSL configuration option in Dovecot to disable >>> "Client-initiated secure renegotiation". >>> >>> It is advised to disable it as it can

On 09/03/16 10:44, Florent B wrote: > Hi, > > I don't see any SSL configuration option in Dovecot to disable > "Client-initiated secure renegotiation". > > It is advised to disable it as it can cause DDoS (CVE-2011-1473). > > Is it possible to have this possibility through an SSL option or other ? > > Thank you. > > Florent ssl_protocols = !SSLv3

Hi all, I tried Tinc 1.1 from git on 4 nodes, each one in a datacenter. They were able to ping each other, etc... but I had problem with multicast, nothing seemed to pass (all is OK with Tinc 1.0.23). I checked logs and on every nodes I have a lot of: Failed to decrypt and verify packet And Error while decrypting: error:00000000:lib(0):func(0):reason(0) So I get back to 1.0.23 which works

From: Chia-I Wu <olvaffe at gmail.com> [ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ] This is motivated by having meaningful ftrace events, but it also fixes use cases where dma_fence_is_later is called, such as in sync_file_merge. In other drivers, fence creation and cmdbuf submission normally happen atomically, mutex_lock(); fence = dma_fence_create(...,

From: Chia-I Wu <olvaffe at gmail.com> [ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ] This is motivated by having meaningful ftrace events, but it also fixes use cases where dma_fence_is_later is called, such as in sync_file_merge. In other drivers, fence creation and cmdbuf submission normally happen atomically, mutex_lock(); fence = dma_fence_create(...,

If the fence context has notifies enabled, each of the fences' FENCE_FLAG_SIGNALED_BIT will be updated from the interrupt. We can rely on this status for reporting the current fence_is_signaled() and so avoid an expensive uncached read. Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: dri-devel at lists.freedesktop.org Cc:

I've being using the same non-nat config for a 7960 for about a year with no issues. I have just upgraded cvs head from the 16th of July to todays. About a minute after I make a call I get the message chan_sip.c:1132 retrans_pkt: Maximum retries exceeded on transmission 000b46a0-8661007f-5c457e72-2b0dba2c@192.168.123.20 for seqno 102 (Critical Response) I don't get this for other

I've seen other request info on this config before. I've got the system up and running, Zap/Modem has been working for several days, no errors/warnings. Simply added info for broadvoice and I can dial into my system via the remote, but dial out from my box renders the following: I get one ring on the remote line, then on the console chan_sip.c:675 retans_pkt: Maximum retries exceeded

We have an interesting issue: One of our providers has two softswitches. Calls coming from the first one are handled fine by asterisk, calls coming from the second one and going through the first one are euhm... dropped half a second into the RTP stream. I have opened a ticket at Digium for it: http://bugs.digium.com/view.php?id=10449 The output of "sip debug" is funny from line

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 5921 bytes Desc: image001.jpg Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20040928/74245e28/attachment.jpeg

On Wed, Nov 18, 2015 at 08:25:28AM +0100, Armin Schindler wrote: > But I have a question regarding "Subnet=" possibilities. When I have more than > one Server acting as host for VMs and need to have automatic routing to > all VMs on these servers, can I use tinc to create this routing automatically? > > My idea is to have a script which is started when a VM is

With pleasure we announce the release of tinc version 1.1pre10. Here is a summary of the changes: * Added a benchmark tool (sptps_speed) for the new protocol. * Fixed a crash when using Name = $HOST while $HOST is not set. * Use AES-256-GCM for the new protocol. * Updated support for Solaris. * Allow running tincd without a private ECDSA key present when ExperimentalProtocol is not

With pleasure we announce the release of tinc version 1.1pre10. Here is a summary of the changes: * Added a benchmark tool (sptps_speed) for the new protocol. * Fixed a crash when using Name = $HOST while $HOST is not set. * Use AES-256-GCM for the new protocol. * Updated support for Solaris. * Allow running tincd without a private ECDSA key present when ExperimentalProtocol is not

With pleasure we announce the release of tinc version 1.0.24. Here is a summary of the changes: * Various compiler hardening flags are enabled by default. * Updated support for Solaris, allowing switch mode on Solaris 11. * Configuration will now also be read from a conf.d directory. * Various updates to the documentation. * Tinc now forces glibc to reload /etc/resolv.conf after it

With pleasure we announce the release of tinc version 1.0.24. Here is a summary of the changes: * Various compiler hardening flags are enabled by default. * Updated support for Solaris, allowing switch mode on Solaris 11. * Configuration will now also be read from a conf.d directory. * Various updates to the documentation. * Tinc now forces glibc to reload /etc/resolv.conf after it

On Tue, May 19, 2015 at 09:39:13AM +0200, Florent B wrote: > Any news about that option ? Can't compile on Wheezy... I removed the info-in-builddir option for now. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature

On Wed, Jul 15, 2015 at 02:35:33PM +0200, Florent B wrote: > I have found the problem, replacing > > AC_CONFIG_MACRO_DIRS([m4]) > > with > > AC_CONFIG_MACRO_DIR([m4]) > > in configure.ac seems to solve the problem. > > It is about automake version, I have 1.11.6 (wheezy) and it needs 1.14 > to use DIRS. > > How to make it work for every version ?