similar to: LocalDiscovery detecting nodes through tunnel

Hi, I am playing with LocalDiscovery again and have noticed that I do not see any LocalDiscovery broadcasts anymore. I am using tinc 1.1-pre9 in switch mode and have set LocalDiscovery = yes in tinc.conf. I do not see any broadcasts on any network and I also do not see anything in the debug output. What to do? -nik -- # apt-assassinate --help Usage: apt-assassinate [upstream|maintainer]

Hello tinc users! Has anyone been able to get LocalDiscovery to work properly? I'm not quite sure what I need to do other than enable it in tinc.conf, and it doesnt seem to be working. Has anyone else tried it? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160901/5698fc86/attachment.html>

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

We are testing tinc inside Google Compute within a single region and an external region. Two boxes are created as follows: /etc/tinc/test/tinc_test_1 Subnet = 10.240.0.0/16 Subnet = 10.240.0.4/32 Address = 104.154.59.151 /etc/tinc/test/tinc_test_2 Subnet = 10.240.0.0/16 Subnet = 10.240.0.5/32 Address = 104.197.132.141 /etc/tinc/test/tinc.conf Name = $HOST AddressFamily = ipv4 Interface = tun0

Hi, I'm using LocalDiscovery = yes to let tinc clients connect directly behind a NAT. Problem is that clients only start to talk directly after pinging each client from each client. Is there way to force direct connection after starting the tunnel. Ciao!

LocalDiscovery works by sending some of the MTU probe packets to the broadcast address (255.255.255.255). If the destination node receives one of these packets, it will update its UDP cache and reply, thus the two nodes will start using their local addresses to communicate. Now, I see two problems with this approach: - In case the two nodes are behind the same NAT and can reach other *but*

Hello list, I notice that the dialplan method SIPAddHeader is not working : in dialplan : /exten => s,n,SIPAddHeader(Privacy: id)/ in SIP invite no trace of this header : /INVITE sip:0473 at sip.domain.be SIP/2.0 Via: SIP/2.0/UDP 192.168.1.106:5063;branch=z9hG4bK-5b2b1b97 From: "VC" <sip:voip2 at sip.domain.be>;tag=729476652f511c67o2 To: <sip:0473 at sip.domain.be>

Good evening, I have a problem with SAMBA domain, I have many pc's with S.O Windows when I try to put then on a samba domain, then don't locate my domain. The OpenSuse Linux 10 show me any lines on the logfile, i'm put these lines below. I'm have OpenSuse Linux 10 + SAMBA 3 with LDAP authentication. Below the SMB.CONF + Slices of a LOG file. Thanks to all !

Hi, all I wanted to fetch data from Bloomberg for govt bonds, and analyse it further. I am having trouble in getting data as when I use field=PX_LAST, it is giving the prices but when I use field=CPN, or ISSUE_DT, it is not giving the results and just bouncing back <NA> for that. This is the piece of code: > library(rJava) Warning message: package 'rJava' was built

Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15

On Tue, Feb 14, 2017 at 11:21:34AM -0500, James Hartig wrote: > Those 2 boxes are in the same subnet and have addresses of 10.240.0.4 and > 10.240.0.5, respectively, on their eth0 interface. Port 655 on tcp and udp > is open to the world. The tinc_test_2 box has a ConnectTo of tinc_test_1. > When tinc_test_2 is started, it prints out: > UDP address of tinc_test_1 set to

Hi, I would like to suggest a couple of enhancements for the LocalDiscovery part: - LocalDiscoveryInterval=x how often to do the local discovery, 0=once - LocalDiscoveryAddress=y to what broadcast address to send the discoveries. like how NTP does this. this is usefull when there's a router between two segments which doesn't route the broadcastst e.g. 192.168.2.255 Folkert

Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. You say that tinc_test_1's eth0 interface is configured with 10.240.0.4, and tinc_test_2's eth0 interface is configured with 10.240.0.5. How are the public addresses

On Tue, Feb 14, 2017 at 1:22 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > > Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. I'm using tinc 1.1pre14. I noticed there's an option,

On 14 February 2017 at 18:59, James Hartig <james at levenlabs.com> wrote: > When you say "and to the local network" what IP does it try to send to > on the local network? The subnet address? No. The Subnet option deals with routing *inside* the VPN, not the underlying "real" network. In tinc 1.1, the address that local discovery probes are sent to is the local

Am Freitag, den 25.09.2015, 22:45 +0200 schrieb Marcus Schopen: > Hi Guus, > > Am Freitag, den 25.09.2015, 17:46 +0200 schrieb Marcus Schopen: > > Hmmm ... I've tried "LocalDiscovery = yes" > > in /etc/tinc/mytunnel/tinc.conf already, but that didn't help. Config on > > client A is: > > > > --------------- > > Name = clienta >

The Register is carrying a article written by Kevin Poulsen of Securtiy Focus, calling asterisk "..the most powerful tool for manipulating and accessing CPN data.." > http://www.theregister.co.uk/2004/07/07/hackers_gut_voip/ I hope NuFone doesn't drop asterisk-set-able callerid's after this article; i've been wanting that feature from voicepluse for a long time.

On Tue, Feb 14, 2017 at 3:43 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > Hang on a second. I've just re-read your original message and I > believe you are confused about what the "Subnet" option does. Again, > it deals with addresses *inside* the VPN. In the configuration you > posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal >

On Tue, Feb 14, 2017 at 1:46 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Tue, Feb 14, 2017 at 11:21:34AM -0500, James Hartig wrote: > >> Those 2 boxes are in the same subnet and have addresses of 10.240.0.4 and >> 10.240.0.5, respectively, on their eth0 interface. Port 655 on tcp and udp >> is open to the world. The tinc_test_2 box has a ConnectTo of

Hi Guus, Am Freitag, den 25.09.2015, 17:04 +0200 schrieb Guus Sliepen: > Ok, that means by default the UDP NAT timeout on the Cisco is extremely > short. > > > I check the manual of the the Cisco NAT for any TCP/UDP > > timeout settings, but there is no way to modify anything like "keeps > > TCP/UDP connections alive". > > It wouldn't be called