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

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

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!

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.

Ladies and gentlemen,

I'm afraid I've got a serious bug or flow within the association establishing protocol logic, which manifestates as repeated failed decrypting association request from message in the log. The problem is that I don't understand why this happens. Yesterday's evening I had it on my node, it was repeatedly complaining about several peers' requests, and restarting the daemon didn't change anything. Today I tried to add more debug messages to the daemon; this caused me to restart both the node and those of my own peers which were involved, and guess what happend — the problem disappeared and I can't cause it to happen again. Those of you who has some expirience in programming might know this is the most terrible types of bug.

Anyway, all we can do now is to wait for it to happen again. This post is just to keep you all informed, specially those of you who now try running nodes.

A new version of the source code tarball (0.0.30) has just been published. The good news is that this version is actually capable of running IPv6 tunnels over the IPv4 Internet. Unfortunately, the bad news is that almost nothing of the proposed key features are implemented. In this miserable version, the fedaserv instances can not find each other, can not exchange broadcast announces, can not act as a rendes-vous assistant for others, there's no database of known nodes' locations... well, there's almost nothing. Despite the IPv6 connectivity is somehow possible, I admit it is not very useful without all the infrastructure; folks, let's put it this way: I needed to convince myself I'm able to deal with IPv6 packets and their forwarding.

Long things short, a node in this version must run on a public ip:port pair, and all connections are to be configured manually. The best thing one can achieve is the two-ways connectivity between points of different nodes, provided that the nodes have an active cryptographic association between them (again, configured manually). For details, please see the file POORMANSVPN inside the tarball.

So, if you have a VPS or smth. like that to run a node, let's play tunnels. I decided not to interfere with my own NAT checking servers; my node, c508097bd6c347a4a317, is running at ip 45.13.38.102, port 5080. The nodecert file for it is here: c508097bd6c347a4a317.pub. If you want to try peering with me (and possibly other fanatics as well), please publish your addr/port and the nodecert file somewhere, and post a link here in the comments. If you can't publish the information anywhere, just copy-paste the nodecert file to the comment and add the IP/port information. I'm going to accept all certs with rank 20 and higher, and may be I'll even maintain a collection of the known certs as a single archive.

Guys, here's a little challenge. I run a single-page webserver on the address feda:c508:097b:d6c3:47a4:a317:3700:feda, port 80, as usual. Take a screenshot of it :-)

Thanks to everyone who supported the project.

A new version of the source code tarball has just been published. The changes are minor this time, but they affect the protocol, breaking backwards compatibility; hence it is given the vers. number 0.0.20 (not 0.0.11 as it could be expected for a minor change).

In a nutshell: I decided to obfuscate the nonce part of encrypted datagrams. The obfuscation is not intended to be “secret” in any way, it doesn't use any keys etc., and actually it can not be “secret” as nonces are open information by their very nature. However, before this change, the nonce was a 64-bit unsigned, stored in the LSB-first byte order, sequentially incrementing by 1 dgram to dgram, starting anywhere between 0x0100'0000'0000'0000 and 0x01ff'ffff'ffff'ffff (as the MSB is always set to 0x01 as the communication starts, while the other seven bytes are filled randomly). The actual nonce passed to the crypto functions is still just that; but in the datagrams it now looks much like random data, and one needs to know how to deobfuscate it to see the sequential numbers.

From the cryptographic point of view, this doesn't add anything to security, as the (de)obfuscation functions are open (just like all the source code here) and they do very simple things. Well, let it be :-)

Thanks to everyone who supported the project.

Today is the first time the full source code for the FEDAnet project is published. Welcome to the download page to get the archive named fedanet-0.0.10.tbz2. Besides everything else, there's the source code for the FEDAnet server (fedaserv), which, as of present, is only capable to respond to NAT check requests; well, actually it is also capable to establish cryptographic associations with peers, so that the NAT checking process, which requires more than one server, becomes possible. See the documentation within the archive.

The License text is also slightly changed. Only the wording (some broken English) has changed, but in its terms and conditions the License remains the same.

Thanks to everyone who supported the project with donations.

No beautifully-looking timestamp was any close to today's date, so let's celebrate Friday 13 :-)

You're welcome to the download page, where the feda-ng-0.0.03.tgz tarball is available. As usual, it contains everything needed to compile the node key generator (that feda-ng program), the challenge table manipulation program (feda-ct) and the cryptographic key&cert manipulation program (fedakeys); but the main novelty today is the program named natcheck, which lets the user to determine what type of NAT (if any) is in effect at the present internet connectivity. Run it as natcheck -v -v.

The check requires a system of servers (at least two of them), collaborating with each other. The servers I currently run are named nc1.feda.croco.net, nc2.feda.croco.net and nc3.feda.croco.net. By default, the first one is used as the main, and the other two play the sibling role. However, if the main server is for any reason not available, please try any of the other two, with a command like natcheck -v -v nc2.feda.croco.net.

Please expect all kinds of malfunction, the code is not mature enough now. And, well, NO, I'm not going to publish the server's source code right now: in its present state such a publishing would be a kind of exhibitionism. Definitely I'll make the server code available when the time comes; please be patient.

And one more thing guys: please share your results in comments here.

P.S.: For those who don't remember: the HTML tag you need to enclose listings and terminal output logs is <pre> :-)

Today is 1733333333 seconds since the Epoch, and being converted to the FEDAnet time, which is in minutes since Epoch, it gives the beautifully-looking number 28888888. This number is easy to remember, so it will perhaps be convenient to use it as the Earliest Possible FEDAnet timestamp.

Not much stuff we have to the date, unfortunately, but at least the key and certificate manipulation program named fedakeys is now able to create all types of the keys and certificates it is supposed to handle. It is far from being finished, as actually it is still unable to actually sign user messages nor encrypt files, but even this is more than nothing. So, you're welcome to the download page, where the feda-ng-0.0.02.tgz tarball is available. The current snapshot of the fedakeys program is included there.

The site devoted to the FEDAnet project is finally up and running. Not much of content is available now; stay tuned.