search for: davidnicol

Hello, I have tried for days on end with no success on this, so I thought I would post it here and see if someone can help me at all. *Here's the scenario:* I have 1 PC with a Static IP/Domain (a dyndns.org account - myserver.homeip.net) connected to a router, which in turn is the gateway to the internet. It also has a static local IP (192.168.1.2). I will call this the "server"

On 11 November 2015 at 21:57, David Nicol <davidnicol at gmail.com> wrote: > it is entirely possible to write code that uses threads on Win32 and forks > on POSIX by abstracting the communication bits generically. Signalling could > work over pipes on both. > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85...

Hi all I feel like I should know the answer to this question, like I read it someplace sometime, but it evades me right now. It's also an opportunity to say hello to the list and many thanks for writing and supporting tinc vpn! We make great use of it at rhizomatica. So, Let's take this example setup. I have two tinc nodes (A and B) behind a firewall NodeA and NodeB have 192.168.1.2

Hi Guus, Unfortunately, I often notice that even with the advanced UDP hole punching mechanisms that tinc uses, I still come across cases on my network where two nodes behind NATs cannot talk to each other because one of the nodes is behind a "strict" NAT that won't use consistent source ports for UDP packets that are sent to different destination addresses. More formally, this

i'm pretty sure the tinc that builds from macports is 32-bit On Wed, Dec 10, 2014 at 10:37 AM, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote: > Hello everyone! > > I have a PowerMac running 10.6.8 and I'd love to get it connected to my > VPN. However, even by compiling tuntaposx by hand on the said MacPro, I see > that the kernel module is apparently built for

On Wed, Nov 11, 2015 at 3:04 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > miniupnpc only provides a blocking API, there is no way to > integrate it into an event loop. That pretty much means we will need > to run the UPnP code in a separate thread. Which means using pthreads > on POSIX, and then we would either have a dependency on pthreads-Win32 > on Windows, or

On Mon, May 22, 2017 at 4:03 AM, Keith Whyte <keith at rhizomatica.org> wrote: > Is there a way to force NodeA or NodeB to "advertise" it's public IP to > the rest of the tinc network, or did I miss something really obvious? the config files can use DNS names, right? Have the nodes that you want to advertise their public IP addresses sign up with Dyndns or similar,

I have an account on a server, where I do not have access to root or kernel rebuilds on a *BSD box. I am setting up tinc VPN in several other servers. I would like to establish a tinc node on my virtual server and have the node relate to other programs on my server via UNIX sockets. Does such a tool (or tool-kit) exist, to allow me to run a tinc-compatible VPN node completely in user mode? I

Is anyone working on a completely user-mode tinc? My situation is that I have administrative control over part of my network but I also have nodes that live in virtual machines and in simple user accounts where I can create TCP connections and high-port listening sockets all I please, but I don't have access beyond that, and I would like to run a user-mode tinc daemon in those accounts to

dselect still shows tinc version 1.0pre7-2 -- is anyone maintaining debian releases? -- David L Nicol You have the right to free speech (as long as you're not dumb enough to actually try it!) -- The Clash (know your rights)

> > 3. It should be from any kind of license free agreement as the > > solution would be sold as a proprietary solution. your solution could include GPL software and still be sold; you would be selling your propprietary configuration of the components, and your support guarantee. Including the source and so on is not something that needs to be played up.

the attached patch is against ubuntu maverick latest git, and I believe it is final. It is forward-compatible, as there is space in it to define 29 more deferred things to wait for, if needed, as well as a flag bit reserved for strict versioning. Calling it with a flags field of 0xFFFFFFFA will wait for everything it knows how to wait for, including things it doesn''t know how to wait for

I have started rewriting the ioctl#21 patch using a less hacky architecture, including defining a new kind of structure that explicitly organizes information common to delayed/deferred systems, (the list of work pieces, and an atomic for counting active worker threads) and replacing the lists of work pieces, in ioctl#21-tracked deferred systems, with this structure instead. I started march 25,

I''ve been thinking about this for a while, from a perspective of how to make it work by allocating i-node numbers from a global pool, but yesterday I realized that offering the feature would be a bad idea because it violates the semantics of file systems. I will be happy to expand on that point if anyone disagrees with it. dln -- "It is merely a matter of persistence." --