FEDAnet project

Dear visitors,

I'm not very familiar with Windows/* platform, so I have insufficient background to understand how to support FEDAnet on Windows. Well, there's a deliberate decision to make it impossible or at least hard to run the node implementation (well, let's call it a full version of fedaserv) on Win machines; however, I feel we actually need some level of support for running point software on them, just to allow node masters popularize the network among those Windows users who won't switch from Windows even for a ton of gold.

The problem is that Windows don't natively support the tun/tap userspace VPN implementation framework, on which FEDAnet depends heavily. As planned, the FEDAnet itself shall provide connectivity between IPv6 subnets corresponding to nodes and points, while all the application software will use this connecivity in a more or less usual manner, that is, connecting to each other using TCP (and perhaps sometimes UDP as well). For all this to work, there must be a clear way to pass a packet to FEDAnet for delivery, and to inject a packet back to the local TCP/IPv6 stack implementation once the packet is delivered from a remote node. Both in Linux and BSDs, FEDAnet is going to use virtual interfaces of the tun type (usually named feda0) for this purpose.

Initially I planned to support a kind of special functioning mode, in which the "client" daemon opens some ports locally on its own and forwards traffic between them and the node (which runs somewhere else, presumably on a server or the like). Well, perhaps this is not too hard to achieve for UDP. For TCP, however, I suddently realized I'd have to implement a good working replacement for the TCP itself, which, roughly speaking, is all about providing a virtual stream connection atop of unreliable packets: for TCP, those are IP packets, and for FEDAnet, they would be UDP dgrams, but the problem is essentially the same: all those transfer windows, MTU path discoveries, confirmation packets and all the mess. Having tun/tap interfaces on decent operating systems, we can leave all the trouble to the existing TCP/IP stack, which is already there in the kernel, ready to serve us. On Windows there's no tun/tap interface, so we can't: the implementation is there, but there's no way to access it.

What solutions I see here. First, there perhaps will be something for Android, actually there must be no big problem to create it, as Android is a (bad kind of) Linux, and it supports the tun/tap interface. Perhaps we can make an Android device serve as a "router", which the client application(s) running on a Windows PCs (and perhaps organized as large multi-purpose executables) will use to connect to servers in FEDAnet. An appropriate IPv6 address and route will have to be configured on such a PC, but this is solvable (well, even by that bundle application itself).

Another direction I see is that WSL thing. I'm not sure if it really supports tun/tap, but chances are it does. To use it, we'll perhaps need to prepare 'special' minimalistic Linux distro which only solves the task of running fedaserv in a simplified (client) mode (which, BTW, isn't implemented as of now). Well, any steps in this direction should only be taken once someone confirms (experimentally) that fedaserv can run on WSL and provide IPv6 connectivity for the whole machine (that is, for applications running on the host Win/* system natively). Unfortunately, this approach has a fundamental flaw: WSL is a relatively new thing, and the versions of Windows that support it won't run on older machines.

May be I overlook something here. Any opinions/suggestions?

P.S. Folks, one more thing: no matter what we discuss around Windows, there must be no steps towards any devices produced by Apple, be it an iPhone, or a MacBook, or whatever. Ideally, no FEDAnet software should ever run on those. I realize this is perhaps not achievable to the full extent, and eventually someone will come up with a 'port' to macs, but we should at least try not to help those lunatics in any way.