search for: udp_confirm

Hi all, I'm back again with my speed issues. The past issues where dependant of network I used. Now I run my tests in a lab, with 2 configurations linked by a Gigabit switch : node1: Intel Core i5-2400 with Debian 7.2 node2: Intel Core i5-3570 with Debian 7.2 Both have AES and PCLMULQDQ announced in /proc/cpuinfo. I use Tinc 1.1 from Git. When I run an iperf test from node2 (client) to

...able Options: pmtu_discovery clamp_mss Protocol: 17.0 Reachability: none, forwarded via H # tinc info H (tinc 1.1 git, direct connect) Node: H Node ID: 68050b57da8f Address: 3.4.5.6 port 443 Online since: 2015-05-13 22:40:07 Status: validkey visited reachable sptps udp_confirmed Options: pmtu_discovery clamp_mss Protocol: 17.7 Reachability: directly with UDP PMTU: 1439 # tinc info O (tinc 1.1, no direct connect) Node: O Node ID: 613b32c62e2a Address: 4.5.6.7 port 29115 Online since: 2015-05-13 23:16:08 Status: validkey visited re...

...local network is 1500 MTU !!! So nodes can ping each other but larger data does not go. test1=sllm1 test2=sllm2 test1:/usr/src/tinc# tinc -n coppint info sllm2 Node: sllm2 Address: 192.168.0.202 port 655 Online since: 2014-02-25 13:36:39 Status: validkey visited reachable sptps udp_confirmed Options: pmtu_discovery clamp_mss Protocol: 17.3 Reachability: directly with UDP PMTU: 1518 Edges: host1 host3 host4 host6 sllm1 Subnets: 1a:26:ce:e3:fb:13 6e:de:af:13:55:bf root at test2:~# tinc -n coppint info sllm1 Node: sllm1 Address: 192.168.0.200...

Hi, I propose that the "ad-hoc connections" (localdiscovery) are also displayed in the graph (graphdumpfile) as it is useful for debugging. I find the command-line tooling a bit cumbersome to find out where the problem is - maybe a web-interface can be added to tincd? Implementing a http server is trivial I found out. Folkert van Heusden -- Curious about the inner workings of your

...the node will use it until it gets an ANS_KEY message for the node, in which case it will suddenly revert back to non-local communication until LocalDiscovery kicks in again. Shouldn't there be some logic in ans_key_h() to prevent it from updating the node's UDP address if n->status.udp_confirmed is already true? - If I understand the code right, when local communication (as in LocalDiscovery) between two nodes suddenly stop working, they will potentially fall back to indirect communication instead of direct non-local communication, because they forgot about the address they got fro...