FEDAnet project

Folks, I have to admit I've just uploaded yet another bugfix release, vers. 0.0.59. Two issues reported in comments (this and this) are addressed in the new version.

I apologise for having this many urgent bugfix releases in a row and hope this one will stay longer.

Please postpone the version upgrade. Looks like there's a bug in the code which effectively prevents fedaserv from working correctly. I'm going to upload the fixed version as soon as I manage to debug it.
UPD: version 0.0.56 is available, please use it instead of the (fatally buggy) 0.0.55.
UPD2: please use 0.0.58, the previous version contained yet another fatal bug.

Version 0.0.55 published. A lot of bugs fixed in the code, so please update as soon as possible.

The only new feature is the -t option for fedaserv, which allows to write a program that prepares the tunnel interface on its own and launches the fedaserv daemon with a prepared file descriptor. There's no way to use this flag launching the daemon without such a program. For those who're curious: this flag is added upon a request from someone who tries hard to let FEDAnet work under (damn) Android. Besides, I finally decided to get rid of those strange four bytes that the Linux version of the tun/tap subsystem adds in front of a packet unless you specify the IFF_NO_PI flag.

I have to admit there are still protocol flaws: sometimes these handshakes don't work. Well, the work is in progress, but I don't know when I manage to catch the protocol bug, so I decided not to postpone another source snapshot. Enjoy.

I've just published the version 0.0.52. It fixes several nasty bugs and features seriously updated file doc/poormansvps.txt, which contained obsolete things since 0.0.40, and with 0.0.50, became half-outdated.

Besides that, I've got some sad news today. The tun/tap subsystem API on FreeBSD (and perhaps other BSDs as well) differs from the Linux one significantly enough that there's no chance to build the software for non-Linux systems. If we manage to make it work for FreeBSD one day, we'll have to maintain even a separate version of documentation. Well, just to give you an idea: the program feda-if appears to be fully Linux-specific, to the extent that if we remove all Linux-specific functions from it, then it will disappear. Literally. Interfaces of this type are named differently and handled differently under BSDs.

Actually, it looks like it is even easier to work with tun network interfaces in BSDs than in Linux, and definitely it is possible to make a FreeBSD version; what I need to proceed with it is a machine with FreeBSD, and no, I don't have one and I even don't have a spare computer to install FreeBSD on. So... at least not now. Sorry.

Thanks everyone who follows the project.

Tarball for version 0.0.51 is downloadable. This is a fix for a couple of bugs (thanks to those who reported them) and an attempt to address one known but hard-to-reproduce protocol flaw.

I have to admit it is still buggy, and yes, I know it. Only it may be better than the previous version. Please update, and sorry for the inconvenience.

I've just composed a page with actual backbone information, and some problems revealed during its preparation:

• two of the previously-known nodes (namely ilya and parthen) are down;
• yury_k uses point number 42, which may be okay if the node is to consist of just one point, forever, and is not going to participate in the broadcast messaging; however, for a FEDAprotocol speaker to be considered running on behalf of its node, not just one point, the point number must be 254.

I don't have any ways of contacting owners of these nodes other than through the site, so, guys, please show up :-)

Ladies and gentlemen,

I'm pleased to announce the source tarball for the version 0.0.50; the tarball is available in the downloads section.

Long things short, this time the fedaserv daemon instances just became capable of exchanging node keys, checking them and storing the results.

The problem I had to solve is that taking a yespower hash is a resource-consuming thing; low-end VPS machines are barely capable to perform it and it is too much stress for them, and older 32-bit computers can not do it at all. Besides that, even for a more or less powerful hardware this hash taking is obviously risky in respect of DoS attacks.

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 :-)