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.

Looks like I issued the wrong command to pack the archive, so it is actually tar.gzip, not tar.bzip2. I've just renamed the file on the server to .tgz which reflects the real format of the file. Sorry for the inconvenience.

FEDAnet 0.0.40 has been published.

This version supports some interesting new features. First of all, the fedaserv daemon is now capable of working as FEDAproxy, serving as many users as you want (the technical limit is more than 1000 of them, as the socket descriptors seem to be the only limiting factor). See the file doc/fedaproxy.txt for details, but to be short, new peer types named proxy, proxyuser and direct are implemented—and, well, seem to work.

Another implemented peer type is named nodenets. This mostly makes sense for configuration of fedaserv instances running as nodes (that is, with point number 254 a.k.a. 0xFE); in case there's a peer of the nodenets type in the configuration file, datagrams that have pseudopoints 0x00, 0xFF and possibly 0xFE (the latter is for the case there's no virtual network interface locally) are forwarded to that peer. This makes it easier to run various infrastructure (such as web/mail/dns/whatever servers) in a location different from that where the node is being run. To know what to do, the fedaserv instance that receives this type of traffic (in case it is not the node, that is, has the point other than 254) must have the line nodenets all or nodenets some in its configuration file (some means this instance shall accept traffic for pseudopoints 0x00 and 0xFF, while all means all the three pseudopoints: 0x00, 0xFE and 0xFF),

There are also a lot of new means to explore what's going on within a running fedaserv; launch the fedactl program and try help and help show.

This news item is dated as 1770000000 seconds since Epoch, but, believe it or not, I only noticed the upcoming interesting date during the active preparations for this release; it gets published today because I only managed to catch the last known bug just yesterday, so it would be published today anyway.

Thanks for those who are still here :-)