FEDAnet project

Main News

Proposal Readings Download Backbone License Donate

Feedback Guestbook

previous • index • next

Backbone info and problems

Tue Mar 24 15:07:05 2026 UTC

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

comment on this

From Parthen (unverified) Wed Mar 25 20:18:29 2026 UTC

"There are two types of people: those who back up their data, and those who will"

I, well, stupidly lost my key a couple of months go.

I already generated a stronger one, so I think I will publish it up somewhere (well, where exactly?).

I'm a bit of busy right now, so it will be around 1-6 of April.

From Andrey Stolyarov Wed Mar 25 21:32:53 2026 UTC in reply to this comment

Re: "There are two types of people: ...

Well, in order to "publish" your new key:

bring up your node at its permanent location (VPS?);
bring up a point at your home machine, and be sure to enable both allow_nodehash and intro_issue in your serv.conf:
```
allow_nodehash yes
intro_issue yes
```
at your home machine, launch the fedactl program (a.k.a. fedserv daemon's control console), enable log messages with log debug, then issue the following commands, one by one:
```
intro 45.13.38.102 52871
intro 89.207.254.147 5081
```

From Yury K. Wed Mar 25 14:03:36 2026 UTC

Fixed my point

Hi,

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've redeployed my point to use 254. It seems to be working well:

root@main:~# curl -s http://[feda:c508:097b:d6c3:47a4:a317:feda:feda]/ | head

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Apache2 Debian Default Page: It works</title>

But in the log I get many errors like these (only these 2 IPs):

Mar 25 14:00:52 [1017780] peer 132.145.107.156:65242 says (as plain) we caused error (01, cmd code known but unexpected)
Mar 25 14:00:52 [1017780] peer 132.145.107.156:65242 says (as plain/plus) our cmd ED caused error (0b, UNKNOWN error code)
...
Mar 25 14:00:57 [1017780] failed decrypting association request from 107.174.224.199:65242

Not sure if it's something that I misconfigured or something else.

P.S. Updated my simple page: http://[feda:5c86:ff1:8726:6d5:188c:feda:feda]/

From Andrey Stolyarov Wed Mar 25 15:45:25 2026 UTC in reply to this comment

Re: Fixed my point

> I've redeployed my point to use 254

Thanks! I've just updated the "backbone info" page.

> 0b, UNKNOWN error code

That's one of several bugs already found in 0.0.50, I hope to publish 0.0.51 later today.

> Mar 25 14:00:57 [1017780] failed decrypting association request from 107.174.224.199:65242

This is a protocol implememntation flaw, the problem is that it is relatively hard to reproduce this situation intentionally, despite it manifestates quite often on its own. I'm going to try addressing this issue in the forthcoming release, but I can't guarantee my attempt will be successful.

From Ilya Tue Mar 24 17:24:29 2026 UTC

Node Crashing

I was surprised to find that my node went down, it seems to always crash after running for couple of hours. Here are the logs before crashing:

Mar 11 15:18:32 fenex fedaserv[110505]: peer XXXX says (as plain) we caused error (01, cmd code known but unexpected)

This message repeats many times. The logging was set to "normal". I now set it to debug2 and will report once it crashes again.

From Andrey Stolyarov Tue Mar 24 17:32:51 2026 UTC in reply to this comment

Re: Node Crashing

What version do you run?

And be careful, debug2 produces a lot of messages, watch your disk space :-)

P.S. shown your node on the backbone_info page, it is now active.

From Ilya Tue Mar 24 18:25:11 2026 UTC in reply to this comment

Re: Re: Node Crashing

0.0.40, I will update now, maybe its fixed.

From Andrey Stolyarov Tue Mar 24 18:51:01 2026 UTC in reply to this comment

Re: Re: Re: Node Crashing

Well, I suppose you upgraded the version. What I'm seeing now on my side looks like a storm :-) Impression is that your node sends a lot of duplicate datagrams, specially of the "please associate" type; but this impression may be false. Anyway, the software is obviously buggy.

What's very strange here is that it only happens with your node, while my fedaserv which demonstrates strange behaviour has a lot of active peers.

I'll look into this matter.

From Ilya Tue Mar 24 18:56:45 2026 UTC in reply to this comment

Re: Re: Re: Re: Node Crashing

Yes, it looks like my node sends a lot of duplicates.

From Andrey Stolyarov Tue Mar 24 19:20:43 2026 UTC in reply to this comment

Re: Node Crashing

Well, just to make sure (hardly it can help, but just to eliminate the obvious possibilities):

1) can you please rebuild the binary from scratch, like unpack the tarball into an empty directory and build there

2) what is the operating system on the machine where it runs?

From Ilya Tue Mar 24 19:46:08 2026 UTC in reply to this comment

Re: Re: Node Crashing

1) done.

2) Debian aarch64

From Andrey Stolyarov Tue Mar 24 20:52:23 2026 UTC in reply to this comment

Re: Re: Re: Node Crashing

> 1) done.

Thanks. Nothing changed.

> 2) Debian aarch64

VERY interesting. Correct programs always work; incorrect programs work sometimes, and they'd better didn't.

If the problem is ARM-specific (or, better to say, if it manifestates on ARMs only; there's no doubt the program is buggy), hardly I can do anything on this right now. Well, may be you try running fedaserv under valgrind? It should be there in the repository.

From Ilya Tue Mar 24 21:18:36 2026 UTC in reply to this comment

Re: Re: Re: Re: Node Crashing

==459118== HEAP SUMMARY: ==459118== in use at exit: 643 bytes in 8 blocks ==459118== total heap usage: 28 allocs, 20 frees, 19,077 bytes allocated ==459118== ==459118== LEAK SUMMARY: ==459118== definitely lost: 0 bytes in 0 blocks ==459118== indirectly lost: 0 bytes in 0 blocks ==459118== possibly lost: 0 bytes in 0 blocks ==459118== still reachable: 643 bytes in 8 blocks ==459118== suppressed: 0 bytes in 0 blocks ==459118== Rerun with --leak-check=full to see details of leaked memory ==459118== ==459118== For lists of detected and suppressed errors, rerun with: -s ==459118== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==459119== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==459119== at 0x497C124: sendto (sendto.c:27) ==459119== by 0x10D753: perform_send_to (fsrv_rx.c:243) ==459119== by 0x114CEB: the_fd_handler_write (fsrv_rx.c:3436) ==459119== by 0x114DA7: the_fd_handler (fsrv_rx.c:3453) ==459119== by 0x13CA4B: handle_fds (sue_base.c:299) ==459119== by 0x13CCB7: sue_sel_go (sue_base.c:363) ==459119== by 0x10B1BB: main (fedaserv.c:323) ==459119== Address 0x4a58f22 is 34 bytes inside a block of size 128 alloc'd ==459119== at 0x4865058: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so) ==459119== by 0x128BEB: twmalloc (servtwml.c:10) ==459119== by 0x11C837: make_txitem (fsrv_txq.c:52) ==459119== by 0x11C9A3: make_txitem_4ip (fsrv_txq.c:90) ==459119== by 0x10D9A3: send_plaintext_128 (fsrv_rx.c:298) ==459119== by 0x10ED83: send_change_key (fsrv_rx.c:765) ==459119== by 0x1144A3: handle_encrypted_dgram (fsrv_rx.c:3255) ==459119== by 0x114967: handle_incoming_dgram (fsrv_rx.c:3369) ==459119== by 0x114A8F: the_fd_handler_read (fsrv_rx.c:3398) ==459119== by 0x114D93: the_fd_handler (fsrv_rx.c:3451) ==459119== by 0x13CA4B: handle_fds (sue_base.c:299) ==459119== by 0x13CCB7: sue_sel_go (sue_base.c:363) ==459119==

From Andrey Stolyarov Tue Mar 24 22:16:02 2026 UTC in reply to this comment

Re: Node Crashing

Damn :( Nothing like this happens on any of my machines.

UPD (25.03.26): BTW, found the bug: call to send_change_key from handle_encrypted_dgram was using wrong (still uninitialized) parameter for the nonce part. The array it used was really intended to hold the desired data, but the data wasn't copied there at the moment of the call. However, this can not affect anything as (heh, in fact) this value is never checked. So this doesn't explain what we saw yesterday.

From Ilya Wed Mar 25 13:30:48 2026 UTC in reply to this comment

Re: Re: Node Crashing

Well, at least with the new version my node doesn't crash anymore :)

From Andrey Stolyarov Wed Mar 25 13:35:02 2026 UTC in reply to this comment

Re: Node Crashing

It continues to misbehave, and we don't know what to do. Actually, nothing is good here.