Thank you very much for this detailed problem description.
It looks like the HELLO from the bootstrap peer is broken.
I will spare some time on that problem, which is proving somewhat
difficult at present due to time constraints.
Please be patient.
Happy Hacking!
t3sserakt
On 1/20/26 22:47, 31a05b9c wrote:
peer discovery does not seem to be working correctly. this is probably
a configuration error, but finding it with the documentation alone failed
after spending way too long on this, so hopefully someone can help with
this.
[follows a dump of all trivial information which could be relevant]
all of the default services are started and none have failed.
version:
$ gnunet-core -v
gnunet-core v0.26.2
HOSTLIST is running, and is downloading HELLOs from some default server:
$ gnunet-statistics -s hostlist
hostlist # bytes downloaded from hostlist
servers: 846639
hostlist # valid HELLOs downloaded from hostlist
servers: 1278
hostlist bytes in
hostlist: 1040
hostlist # advertised hostlist
URIs: 0
hostlist # hostlist downloads
initiated: 9
hostlist # milliseconds between hostlist
downloads: 512000
hostlist # hostlist URIs read from
file: 0
'bytes in hostlist' does not grow as the other statistics do, so
it seems that all of the deleted HELLOs are being discarded.
the entire configuration file is:
[path]
GNUNET_HOME = /var/lib/gnunet
GNUNET_DATA_HOME = /var/lib/gnunet/data/
GNUNET_RUNTIME_DIR = /var/run/gnunet/
[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = YES
OPTIONS = -l /var/log/gnunet.log
[hostlist]
# SERVERS = EXTERNAL_DNS_NAME = domain.domain
BINDTOIPV4 = 1.2.3.4
BINDTOIPV6 = 2a03::1234
HTTPPORT = 12981
OPTIONS = -b -e -p -a
[communicator-tcp]
BINDTO = 1.2.3.4:2086 # to avoid 50 local addresses in HELLO
BINDTO6 = [2a03::1234]:2086
[communicator-udp]
BINDTO = 1.2.3.4:2086 # ditto
BINDTO6 = [20a3::1234]:2086
[nat]
BEHIND_NAT = NO
ALLOW_NAT = NO
ENABLE_UPNP = NO
ENABLE_IPSCAN = YES # HELLO is empty without this
EXTERNAL_ADDRESS = 1.2.3.4 # probably useless
HOSTLIST's server is reachable and produces a hostlist containing only
the local peer.
none of the HELLOs HOSTLIST discovered result in any peers being known
to the rest of the system (as expected from them not being in the
hostlist)
$ gnunet-core -s # produces no output
$ gnunet-cadet -P # only the local peer
N8HP... tunnel: N, paths: 0
$ gnunet-hello -D # only the local peer
2026-01-20T22:17:06.625275+0100 pils-api-3914317 DEBUG Connection
to service successful!.
`N8HP' (expires: Thu Jan 22 22:13:02 2026):
|- udp://[2a03::1234]:2086
|- udp://1.2.3.4:2086
|- tcp://1.3.4.4:2086
(IPv6 TCP being absent is a separate question)
the log does contain this at the very start:
peerstore-3916477 ERROR Assertion failed at
../src/lib/hello/hello-uri.c:422.
peerstore-3916477 ERROR Unable to parse HELLO message
there is also:
nse-3916502 ERROR Assertion failed at
../src/service/nse/gnunet-service-nse.c:1369. Aborting.
arm-3916466 WARNING Service `nse' terminated with status signal/6,
will restart in 1 ms
NSE does not fail again when restarted, and this seems irrelevant
anyways.
the only other error is this (but this seems to just be abuse of a log
level):
pils-3916478 ERROR Successfully generated a new peer id EPK3MN -
inform clients
transport-3916488 WARNING Stored our new hello with peerstore
it seems noteworthy that peer EPK3MN does not actually exist anywhere
besides this message.
the only warnings in the log are (unique, exluding other log level
abuse):
core-3913576 WARNING No matching service entry `example' was found
in services info.
removing configuration which is not strictly necessary has no effect.
purging all of gnunet's data has no effect.
firewall logs do not record any interference.
absolutely everything else seems to be working, but it is not saving
the HELLOs.
[end of information dump]
this is too confusing to try to solve alone
