similar to: PMTU - ICMP type 3/subtype 4 on 2.4.x

Dear Guus, while improving the PMTU Discovery algorithm, I found the following behavior in the method "send_udppacket": 1) The code checks, whether the data size is smaller than the MTU, thus if it fits into a single UDP packet. If not, you send the packet via TCP. 2) The data is compressed, changing its size. (Usually, making it smaller, but that's not always

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"

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 Wed, May 13, 2015 at 04:41:30PM +0200, Florent B wrote: > I have MTU problems when all these conditions are true: > - a client is running Ubuntu (ICMP messages about PMTUd are ignored on > it by default) I have no experience with Ubuntu, but I find it hard to believe it would block ICMP Fragmentation Needed packets out of the box. > - a client is accessing us from a particular

On Thu, May 14, 2015 at 10:12:40AM +0200, Florent B wrote: > > I have no experience with Ubuntu, but I find it hard to believe it would > > block ICMP Fragmentation Needed packets out of the box. > > I can confirm you that this is the case. Ubuntu ignores those ICMP > packets... :( (rp_filter settings) > > You can see it here : https://mellowd.co.uk/ccie/?p=5662

Hello Everyone,   Trying to help someone recover the contents of an SPSS.sav file using read.spss. This seemed to work well but produced a warning message. My code and the warning are displayed below.   Spent some time looking for previous questions about this warning. Found a lot of questions posted but wasn't able to figure out what the problem is.   Is there anyone out there who can explain

BioInformatics Scientist Job Code: 10-TR25 Location: Cambridge, MA Description We are seeking a highly motivated, independent bioinformatics scientist to join a group of scientists, analysts and programmers to develop tools and methodologies for large-scale gene expression data analysis. The group supports a variety of research projects in target and drug discovery as well as biomarker

Hello, this could be ip address of the different interface on the same box. I think it works like expected. The only exception would be if the sip peer ignores the icmp packet unreachable. But I doubt this is the case. Anyway you get problems also when calling to LTE phone without using sip provider. Let first concentrate on these calls LTE to LAN. Are you sure you do not block incoming icmp

On Thu, May 14, 2015 at 10:12:40 +0200, Florent B wrote: > On 05/13/2015 05:00 PM, Guus Sliepen wrote: > > I have no experience with Ubuntu, but I find it hard to believe it would > > block ICMP Fragmentation Needed packets out of the box. > > I can confirm you that this is the case. Ubuntu ignores those ICMP > packets... :( (rp_filter settings) > > You can see it

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 10:07, schrieb Marek Greško: Hi > this is a correct response: > > From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set > (mtu = 1492) > > So PMTU discovery is working. No problem here. You got correct message > to lower the packet size from 62.156.246.57. This is probably the last > hop before your site. No, the last hop is 62.156.246.65:

Hello, if you need clampmss then it is highly probable there is a PMTU discovery problem. The clampmss does not work for UDP. 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 your site? I mean trying to ping from sites with higher MTU than yours without lower MTU links in the path. You

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

https://bugzilla.netfilter.org/show_bug.cgi?id=662 Phil Oester <netfilter at linuxace.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |netfilter at linuxace.com Resolution|

+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) { +//

Hello, this is a correct response: >From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set (mtu = 1492) So PMTU discovery is working. No problem here. You got correct message to lower the packet size from 62.156.246.57. This is probably the last hop before your site. Marek 2020-06-23 9:40 GMT+02:00, Luca Bertoncello <lucabert at lucabert.de>: > Am 23.06.2020 09:28,

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

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