Main
News
Proposal
Readings
Download
License
Donate
Feedback
Guestbook
Mon Sep 8 23:10:00 2025 UTC
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.
From Ilya
Wed Sep 10 10:14:45 2025
UTC
Peer
wget -O 102028623c1cef4a81c1.pub https://files.catbox.moe/ek3hj2.pub
reply
From Andrey Stolyarov
Wed Sep 10 13:24:29 2025
UTC
in reply to
this comment
Re: Peer
Checked (rank 25), looks working. Any address to ping? :-)
reply
From Ilya
Wed Sep 10 13:35:37 2025
UTC
in reply to
this comment
Re: Re: Peer
The unknown node errors stopped, however, running curl [feda:c508:097b:d6c3:47a4:a317:3700:feda]:80 hungs indefinitely, here are repeating -vvv logs
reply
From Andrey Stolyarov
Wed Sep 10 14:34:20 2025
UTC
in reply to
this comment
Re: Re: Re: Peer
I noticed you use the point number 1. There are no special assumptions about this point number, it's just a point. So my node knows how to reach your point-1's subnet (that is, FEDA:(node-id):01xx:xxxx), as it has direct connection to it, but it doesn't know how to reach any other addresses within your node subnet, outsize of that 01xx:xxxx. It is very possible this is the problem.
The fedaserv instance running on behalf of its node must have the point number
256254 (0xFE; sorry, "256" was a typo). If a directly connected peer has this point number, it is assumed to be the valid next hop for the whole node's /96 block.The good news here is that no corrections are needed from my side: my node already knows your cert, so it will happily accept connections from any of your points.
reply
From Ilya
Wed Sep 10 14:47:02 2025
UTC
in reply to
this comment
Re: Re: Re: Re: Peer
So what should be done on my side? Should I create a new point? I tried actually, I ran "fedakeys -p zcrpoint 44" and then "fedakeys -p deploy [key file]", and it gave me error "FATAL: .fedanet/keys/feda.conf already exists, move/delete it and retry", thats why I worked with what I had and used FEDA:(node-id):FEDA:FEDA as an address, as described in the docs. Should I move feda.conf somewhere, run the command again, and move it back?
reply
From Andrey Stolyarov
Wed Sep 10 15:23:48 2025
UTC
in reply to
this comment
Re: Peer
Just remove .fedanet/keys/feda.conf AND .fedanet/keys/secret.key, you don't need them,
fedakeys deploywill create you new files :-) Then, at the location where you have your ZeroPoint, do fedakeys zcrpoint 254, copy the _p254.key to the location of your node, and performfedakeys -p deploy whatever_p254.key(-p suppresses the hash check, it might be useful if the node is to be run on a low-class machine).reply
From Ilya
Wed Sep 10 16:19:43 2025
UTC
in reply to
this comment
Re: Re: Peer
I'm sorry, I don't get it. Now that I deleted those files, zcrpoint complains
> fedakeys deploy will create you new files
this command takes filename as an argument, which one is it? the only "secret" files I have are zeropoint.key (and master key on a separate machine), I deleted the rest.
reply
From Andrey Stolyarov
Wed Sep 10 16:36:10 2025
UTC
in reply to
this comment
Re: Re: Re: Peer
Ah, okay. I didn't expect you having ZeroPoint in the same location as the node, this is generally not desirable. ZeroPoint is used only to create/sign other points' keys, so it should reside on your workstation, not on the server, and the node typically works on a server.
Together with the ZeroPoint, you can deploy any other point in the same location, but this is supposed to be your personal point (number 1? actually, any in the range 1..253, it's up to you). Well, likely you can deploy the "magic" point 254 together with the ZeroPoint, but, well, it looks strange for me to use the server machine to create/sign ordinary points' keys.
Now that you deleted your ZeroPoint deployment (sorry for this, again, I just didn't expect such a setup) you should first re-deploy the ZeroPoint (errr... remove that .fedanet/keys/zeropoint.key file first, or it will fail). If you already erased your
nodeID_p0.keyfile, use your master key to make a new one. If you really want so, you can do this all at the same location as your node is supposed to run, despite I strongly recommend to think again before you do. Even deploying the ZeroPoint at the same location with your master keys looks more natural to me.Once you deployed ZeroPoint, use it to create the key for point 254, and use the nodeID_p254.key to deploy the point at the location where the node is to be run.
reply
From Ilya
Wed Sep 10 18:26:35 2025
UTC
in reply to
this comment
Re: Re: Re: Re: Peer
Okay, now I finally got it working and was able to load your website
So those are the steps I've done:
1) deploy master from master key, then generate zeropoint key
2) copy zeropoint key from isolated machine to my main workstation and continue from there
3) on the workstation, deploy zeropoint from zeropoint key, then generate keys for other points (like 254)
4) copy keys for other points to my server, and continue from there
5) on the server, deploy the points, import certs, etc
P.S. I was actually able to access the website from my main workstation, by running
and then adding 127.0.0.1:7777 to the browser proxy settings. Actually, any software can be proxyfied this way using mgraftcp or proxychains, which makes me even question the need to write software for point end-users, since you won't be writing for Windows or Android.
reply
From Andrey Stolyarov
Wed Sep 10 20:07:59 2025
UTC
in reply to
this comment
Re: Re: Re: Re: Re: Peer
> 5) on the server, deploy the points, import certs, etc
This step sounds strange for me. Only the node (a.k.a. point 254) is supposed to run on the server. If you have other servers, it might be desirable to run fedaserv instances on them to build a nat-checking system, but I actually don't see any other valid purposes for other points to run on server machines.
To connect your workstation to FEDAnet, deploy a point (e.g. #1, or any other from the range 1..253) on it (perhaps in the same location with the ZeroPoint) and configure it to connect to your node. My site must become available directly once this is done.
reply
From Ilya
Wed Sep 10 20:47:01 2025
UTC
in reply to
this comment
Re: Re: Re: Re: Re: Re: Peer
Thanks, I got it now, it was all confused in my head :-).
reply
From Ilya
Thu Sep 11 09:24:26 2025
UTC
in reply to
this comment
Re: Re: Re: Re: Re: Re: Peer
I checked it today (was too sleepy yesterday), and pinging from my workstation doesnt work - the packets are being forwarded by my server to your site, server then receives the reply, but that reply is never forwarded back to the workstation. The workstation is behind a restricted NAT btw.
reply
From Andrey Stolyarov
Thu Sep 11 10:55:41 2025
UTC
in reply to
this comment
Re: Peer
Restricted NAT (and even symmetric NAT, which is much worse) must be okay for a point, at most it might require setting lesser
keepalive_intervalin the.fedanet/serv.conf. Try setting it, e.g., to 30. However, to me this doesn't look like the cause for the problem.I'd check two things now. First, does the IPv6 address on your workstation correspond to the point number you use there: FEDAnet addressing scheme is FEDA:(node-id):PPxx:xxxx, where PP is the point number (in hexadecimal), and xx:xxxx are the point's own address space — so each point has a /104 subnet. Second, is forwarding enabled within the node's serv.conf (there must be a line
forwarding yes).reply
From Ilya
Thu Sep 11 11:26:46 2025
UTC
in reply to
this comment
Re: Re: Peer
Nevermind, I made a spelling mistake when setting up IPv6, it works now
reply
From Yury K. (unverified) Tue Sep 9 22:23:04 2025 UTC
Seems to be working well!
I configured two of my servers and managed to connect them to each other. For some reason, when I tried "type default" in the peer config, it didn't work. So I tried "type natcheck" instead, and now it works — pings, TCP, and UDP.
Here's the config for my primary node:
Public key: http://4kd.xyz/5c860ff1872606d5188c.pub
By the way, I also run a single-page server: http://[feda:5c86:ff1:8726:6d5:188c:2a00:feda]:6080/
reply
From Andrey Stolyarov
Wed Sep 10 00:32:02 2025
UTC
in reply to
this comment
Re: Seems to be working well!
Public key checked and added to the collection. BTW, I've never seen rank 29 before :-) Perhaps I was the first guest to see your site, yes it works.
I'll look into the peer type problem tomorrow, as of now I'm too sleepy.
P.S. I edited your comment to add the <pre> tag for the peer configuration, otherwise it was inconvenient to copy-paste it.
reply
From Yury K. (unverified) Wed Sep 10 07:40:30 2025 UTC in reply to this comment
Re: Re: Seems to be working well!
Sorry, I forgot about pre. Thank you for adding it.
Screenshot of your site (spoiler alert!): http://4kd.xyz/feda-croco.png
reply
From Ivan (unverified) Tue Sep 9 09:37:47 2025 UTC
Latest news
It just appeared there, sorry for false alarm
reply
From Ivan (unverified) Tue Sep 9 09:36:52 2025 UTC
'Latest news' section
Somehow this message is not present in the 'Latest news' section on the Main page
reply
From Andrey Stolyarov
Tue Sep 9 14:41:09 2025
UTC
in reply to
this comment
Re: 'Latest news' section
This is called "browser's cache". Press F5.
reply