similar to: PMTU Discovery

Hi Guus, while checking the source code, I stumbled upon PMTU Discovery. I've got a question regarding the process of sending/receiving PMTU packets. As I understand, the packet flow is like this: 1 .Tinc creates a packet with a specific payload length to send it as an PMTU probe. (The data part is just some random bytes.) 2. This packet gets compressed and sent

We have an issue with some customers who refuse to accept ICMP traffic to their mail servers. It seems that they have put Mordac, preventer of information services in charge of their firewall policy (http://en.wikipedia.org/wiki/List_of_minor_characters_in_Dilbert#Mordac). My mail logs are showing that customers who specifically disallow ICMP traffic have many "Connection Reset"

Dear Guus, I've attached my first git commit to your repository. It does not contain any new functionalities, but it is a first try to interact with your git copy. Could you please verify, if you can push this commit to your repository? If it works, I'll send you the rest of my work, which contains: 1) some small improvements in logging (using flags instead of counters) 2) the

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

+0100 From: Daniel Schall <tinc-devel at mon-clan.de> Date: Thu, 6 Jan 2011 17:00:35 +0100 Subject: [PATCH] Improved PMTU discovery diff --git a/lib/dropin.c b/lib/dropin.c index 52fb5b8..2b803b1 100644 --- a/lib/dropin.c +++ b/lib/dropin.c @@ -165,8 +165,8 @@ #endif =20 #ifdef HAVE_MINGW -int usleep(long usec) { - Sleep(usec / 1000); - return 0; -} +//int usleep(long usec) { +//

Hi, I believe I have found a bug with regard to the LocalDiscovery feature. This is on tinc-1.1pre7 between two Windows nodes. Steps to reproduce: - Get two nodes talking using LocalDiscovery (e.g. put them on the same LAN behind a NAT with no metaconnection to each other) - Make one ping the other. Expected result: - The two nodes should ping each other without any packet loss, hopefully at

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

Am 23.06.2020 09:28, schrieb Marek Greško: Hi > if you need clampmss then it is highly probable there is a PMTU > discovery problem. The clampmss does not work for UDP. Is there a way to check if I have this problem? > I probably counted the size incorrectly. So you are able to ping with > size 1464 and not with 1466. How about trying same ping sizes from the > internet towards

Am 23.06.2020 08:43, schrieb Luca Bertoncello: And another thing, I discovered right now... > Could you suggest me something to restrict the problem? > Currently, I think the problem can be: > > 1) on Asterisk > 2) on my Gateway/Firewall A couple of years ago I added this entry in my firewall: /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS

I've got more changes on my to-do list, but I want to ensure I'm making my changes against the right branch. * I'm working with trunk now. I don't think its TCP tunneling is as secure as the UDP tunneling. It looks like its IVs and HMACs are added and verified in send_udppacket and receive_udppacket. The TCP connection encrypts but doesn't have these anti-modification

Hi everyone, you can find the current version of my enhanced tinc using subversion: svn://tardyon.mon-clan.de/tinc I allowed anonymous read access, so feel free to download the sources. Unfortunately, my enhancements are based on a rather old git-checkout from Guus. The version should run under windows and Debian/Ubuntu. Best, Daniel -----Original Message----- From: folkert [mailto:folkert

Hi, tinc experts abc to def at x.x.x.x port 655 options d weight 540 How’s the 540 weight been calculated? What does it mean? How can I leverage this weight? The d of after options mean direct?

Hello, I try to set up my Linux 2.4.x system to respond by "ICMP Destination Unreachable message" subtype 4 ("fragmentation needed and DF set") in order to support the Path MTU Discovery (RFC 1191) as a router. There is any /proc/xxx parameter to do this? Thanks Mugur _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl

On Thu, 7 Nov 2013, Ernst Kratschmer wrote: > Dear openssh developer, > > I want to use a Win7 client with putty to access a Linux host running an > openssh 6.2p2 through a VPN connection. These connection worked relatively > flawless with all versions of openssh up until openssh 6.1p1. Since the > openssh 6.2p2 upgrade the ssh connection fail consistently with a message:

Hi all, I am currently deploying tinc as an alternative to OpenVPN. My setup includes a lot of nodes and some of them are sitting together behind the same router on the same network segment. (E.g. connected to the same switch.) I noticed, that those nodes do never talk directly to each other via their private ip-addresses, but instead use the NATed address they got from the router.

Hello, I'm experiencing strange behavior on ssh-enabled file transfers (scp and rsync): When connecting to the Internet through an RTC PPP link to a certain provider, file transfers from a remote host (debian potato) to my local host (debian woody) get immediately stuck when issued from the local host, while they work very well when issued from the remote host. On the other hand, no

With pleasure we announce the release of tinc version 1.1pre12. Here is a summary of the changes: * Added a "--syslog" option to force logging to syslog even if running in the foreground. * Fixes and improvements to the DecrementTTL function. * Improved PMTU discovery and UDP keepalive probes. * More efficient relaying of UDP packets through intermediate nodes. * Improved

With pleasure we announce the release of tinc version 1.1pre12. Here is a summary of the changes: * Added a "--syslog" option to force logging to syslog even if running in the foreground. * Fixes and improvements to the DecrementTTL function. * Improved PMTU discovery and UDP keepalive probes. * More efficient relaying of UDP packets through intermediate nodes. * Improved

Hi all, At my work I`ve set up a VPN. When I connect to it, my colleagues see all the workgroups from my side of the VPN (I live on a campus with ~50 workgroups). Do you know how I block the workgroup discovery on through the VPN gateway? Is the broadcast done on a specific port? Is samba actively repeating the broadcast and their replies? Greetings Tjerk Jan

Dear All, It is not a typical R question (though I use R for this) but I thought someone will help me. For the list of P values, I have calculated FDR using p.adjust() in R (bioconductor). But my FDR values are same for all the P values. When do we get same FDR values? Does the smallest P values should less than 1/N? (where N is the number of P values) Thanks in advance. Kind regards, Ezhil