FEDAnet project

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.

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 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 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.

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.