FEDAnet project

Version 0.0.72

1 Jul 2026 19:10:00 +0000

I've just uploaded fedanet-0.0.72.tbz2, in which a minor fix is made to the code. Thanks go to a guy with nickname posyx for reporting where to look. Hopefully, this fixes both issues with non-intel platforms (primarily ARM), and with NetBSD. Looks like it was because "default" char is unsigned there, while in one weird part of the code it was assumed to be signed.

I'm not sure if this will really work on ARMs as well as on NetBSD (as I have neither of them right now), so if you have any of them, please update and report back your experience, both positive or negative.

Test site is back

24 Jun 2026 01:29:34 +0000

Someone recalled there was a test web site inside FEDAnet. The site was running on a machine inside my home network, but for some reasons I had to stop keeping that machine running 24x7. As of now, the site on the same IPv6 address feda:c508:097b:d6c3:47a4:a317:3700:feda runs on one of my VPS machines (I won't tell you on which, heh; anyway, you can't access it from outsite, only from within FEDAnet).

Besides, I got tired copy-pasting that IPv6 address which is, just like all IPv6 addresses, impossible to remember. Hence, now the domain name fedatest.feda.croco.net now resolves to that address. This is not very consistent, as the address is not accessible from the Internet, while the domain name is; however, I still couldnt't find a solution for DNS service inside FEDAnet.

Well, enjoy :-)

fedanet 0.0.71: reportedly works with OpenBSD

11 May 2026 14:00:00 +0000

FEDAnet source tarball version 0.0.71 uploaded; it contains a minor fix that covers the (previously unknown to me) difference in the tun/tap facility API between FreeBSD and OpenBSD. Yes, they are different. Slightly but sufficient to be incompatible. The new version is reported to compile and run on OpenBSD. Thanks go to EVI for reporting the trouble and trying the fixed version (which involved a lot of work).

Another change since the last release is that logging modules are separated into a library, named loghorn. This is the first time the library gets published. However, this change is not visible to users who don't bother reading the code. I only publish this release because of the achieved compatibility with OpenBSD.

Let's wait for someone with a NetBSD machine :-)

fedanet 0.0.70: now with FreeBSD support

5 May 2026 18:33:20 +0000

FEDAnet source tarball version 0.0.70 is available in the download section. It now compiles and (hopefully) works on FreeBSD; to build there, use

  gmake FLAVOR=freebsd

Please note this build mode uses clang which seems to be the FreeBSD default now; if you have gcc and want to compile with it instead of clang, use

  gmake FLAVOR=freebsd CC=gcc

or, even better

  gmake FLAVOR=freebsd CC="gcc -fdiagnostics-color=never -fno-diagnostics-show-caret"

Special thanks today go to G.Nerc=Y.uR who provided me with access to a FreeBSD-based VPS and performed a lot of configuring, which made my work possible.

I'd like also to thank everyone who supported this project monetarily.

It is a pity I couldn't finish this work to the magnificient moment of 1777777777 seconds since Epoch, which happend two days ago, May 03, early in the morning. Well, better late than never.

... and yet another one

5 Apr 2026 10:13:20 +0000

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.

FEDAnet 0.0.55

2 Apr 2026 23:03:20 +0000

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.

And yet another bugfix (fedanet 0.0.52)

28 Mar 2026 01:34:26 +0000

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.

Quick dirty bugfix (fedanet 0.0.51)

25 Mar 2026 21:16:53 +0000

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.

Backbone info and problems

24 Mar 2026 15:07:05 +0000

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

fedanet 0.0.50: let's begin building the backbone

24 Mar 2026 00:43:20 +0000

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.

What do we do with Win/*: request for suggestions

4 Mar 2026 02:45:35 +0000

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.

fedanet 0.0.40

2 Feb 2026 02:40:00 +0000

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

fedanet 0.0.37

28 Dec 2025 11:40:00 +0000

FEDAnet 0.0.37 is available, primarily to fix another bug, but also some new features are implemented for that control console (take a look at the show command). Enjoy :-)

fedanet 0.0.35

25 Dec 2025 12:44:26 +0000

UPD (Dec 26, 2025): A quick bugfix is published as the version 0.0.36.

As you might already know, I like beautifully-looking numbers. Today it is 1766666666 seconds since Epoch, which in FEDAnet time (minutes since Epoch) becomes 29444444. Besides that, today is December 25, which is my birthday.

Unfortunately, not too many things there are to publish today, but nevertheless I think it is a good idea to share a snapshot of the source code. It is now available in the download section.

Sources were notably reworked to reduce the size of the feda_rx module. Active peers are now mentioned in the logs with both their ip:port and node_id.point pairs, and also with their names should a name is given in the configuration file. The server, being signaled with SIGUSR1, prints to the logs the list of all established cryptographic associations with the peers. A couple of minor bugs are fixed, as well as protocol flaws, so that reestablishing the association after, e.g., one of the peers got restarted, now works smoothly.

Besides that, the server is now able to create a local socket for a control console, which is enabled with control_socket yes in the configuration file. The (very primitive) program named fedactl connects to the socket and provides some controlling capabilities.

Some new message types are introduced in the protocol, but, unfortunately, it is not yet possible to get any practical use out of them. Sorry, this is the question of the next release.

Thanks everyone who supported the project!

Quick dirty bugfix

23 Nov 2025 19:08:41 +0000

Colleagues,

I'm publishing the version 0.0.31 of the FEDAnet sources, which fixes a file descriptor leak in the fedaserv daemon. Long things short, in the previous version, if it works long enough, it runs out of available file descriptors; as a result, it starts to refuse to recognize any remote peers, claiming it doesn't know their nodes (which is wrong; the real cause is that it can't read the appropriate information due to lack of FDs).

The fix is quick and dirty. I found the bug during an unrelated code reworking, and I didn't bother with branches, so I just put all things (hopefully) together again, and here is the new version. It may in fact introduce even more bugs, I only checked my own network of servers to be working with the new version of the code.

More serious refactoring of the code is pending, as the key module named fsrv_rx became overcomplicated and urgently needs to be decomposed, simply to make the code manageable again. I've got no idea how long will this take.