View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011711 | GNUnet | ARM service | public | 2026-08-03 00:28 | 2026-08-06 10:39 |
| Reporter | Jllx | Assigned To | schanzen | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 0.29.0 | ||||
| Summary | 0011711: can't bootstrap (again :( ) | ||||
| Description | linked to https://bugs.gnunet.org/view.php?id=11629 so I tried today again and now it don't connect... after gnunet-arm -s I monitor connections states using # gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT DXYV direct tcp,udp 4 0 0 1857 ms so it seems to be connected to DXYV and # gnunet-pils -1 82D13WPCJXQ4ZPYKS3XNAEKSSYCM0KG7Z1GKNTK99A391CXJ2MD0 (but not sure it's relevant, since it also output the same result later) # gnunet-core -s Mon Aug 03 00:14:29 2026: Awaiting initiation (R) DXYV (timeout in 0 ms) so it's waiting initiation I do this several time and after some time it ends like this : # gnunet-transport -a No virtual links. # gnunet-core -s nothing displayed # gnunet-pils -1 82D13WPCJXQ4ZPYKS3XNAEKSSYCM0KG7Z1GKNTK99A391CXJ2MD0 still display something # gnunet-arm -I Services (excluding stopped services): (started: 19 / stopped: 16) cadet (binary='gnunet-service-cadet', status=started) core (binary='gnunet-service-core', status=started) dht (binary='gnunet-service-dht', status=started) gns (binary='gnunet-service-gns', status=started) hostlist (binary='gnunet-daemon-hostlist', status=started) namecache (binary='gnunet-service-namecache', status=started) nat (binary='gnunet-service-nat', status=started) nse (binary='gnunet-service-nse', status=started) peerstore (binary='gnunet-service-peerstore', status=started) pils (binary='gnunet-service-pils', status=started) rest (binary='gnunet-rest-server', status=started) revocation (binary='gnunet-service-revocation', status=started) rps (binary='gnunet-service-rps', status=started) setu (binary='gnunet-service-setu', status=started) statistics (binary='gnunet-service-statistics', status=started) topology (binary='gnunet-daemon-topology', status=started) transport (binary='gnunet-service-transport', status=started) communicator-tcp (binary='gnunet-communicator-tcp', status=started) communicator-udp (binary='gnunet-communicator-udp', status=started) done it several time today and it always end like this, is RTT Round Trip Time ? if yes the value varies slightly during my polling from 1857ms to 1859ms so it don't seems to be a "ghost" message (previous message not updated and still displayed, as for gnunet-pils -1 output) | ||||
| Tags | No tags attached. | ||||
|
|
I think I put the wrong catergory : should rather be gnunet-core ? |
|
|
Yeah but this is fine. I can confirm your issue, my peers also disconnected. A simple restart of thepeers would solve the issue temporarily, but I have to investigate this new issue that arises after a day or so of running the peer :( |
|
|
Currently again starting long test. You may try to re-connect. Leaving this bug open until we have a stable connect for a couple of days. |
|
|
ok right now : # gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT PBM3 dv (2 hops) - 4 0 0 0 ms V512 dv (2 hops) tcp 4 0 0 182 ms 7Y6R dv (2 hops) tcp 4 0 0 276 ms DXYV direct tcp 4 0 71 29 ms # gnunet-core -s Tue Aug 04 21:21:18 2026: Hello sent (I) 7Y6R (timeout in 0 ms) Tue Aug 04 21:21:18 2026: Hello sent (I) V512 (timeout in 0 ms) Tue Aug 04 21:21:18 2026: Connected (R) DXYV (timeout in 299 s) |
|
|
for information, I redone the gns test to resolv, it did succeed in 1h20min... ;) I now have more peer reported by gnunet-transport -a but I'm still puzzled where to find the sql database containing peers... my gnunet configuration is "system wide" and I find strange that the database could be stored in root home directory... (and there is nothing in /root/.cache/ related to gnunet) so if you know where to look, you're welcome! |
|
|
Ah I see I understand now what you mean by system wide. This also explains why you have no namestore and identity services running (those must be started per user) and why gnunet-identity hangs when you run it as root (the identity service is not running as that user). To find all paths, you can run $ gnunet-config -f -s paths obviously, GNS should not take over an hour. I guess this warrants some research. |
|
|
Connections seems to be stable for around 12 hours now, can you occasionally try to resolve: $ gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt this record expires every 30 mins (at which point it is re-resolved in the network). If the connections remain stable, and the resolution works, we are good. |
|
|
Ok so basically, the connection is stable now for over 12h, I can also see your peer occasionally (82D1). From my side, this issue is resolved. |
|
|
seems so, it did reconnected on every location I was (it's a laptop so it's normal that I disconnect when I move) I've only 4 active links at most, every time the same hosts... is it normal? shall I not have more hosts after a day of connection (supposing that the host are stored in cache...) trying host resolution right now (couldn't during the day) |
|
|
I looked the path, what is strange is that I have a mix between my user and root paths (since I start the service using root account [is there a better security practice?]) but I found the sql peer database, there are lot of entries related to transport-communicator-url (some have 45 bytes long values, others have 67 bytes long values) a few peerstore-peer-hello-uri with big data in it and some that seems related to time : transport-dv-learn-monotonic-time, transport-backchannel-monotonic-time with 17 bytes values > you have no namestore yes seems so, I looked in the namestore/sqlite.db database and it's empty there is one entry in the namecache/sqlite.db my primary goal is to have gns (dns is mandatory for lot of services) that's why I start with START_SYSTEM_SERVICES = YES in /etc/gnunetd.conf I followed the tutorial and set START_USER_SERVICES = NO but maybe I should set it to yes to have identity and namecache? I begin to have some interesting experience, I can't help for coding, but maybe I can complete the https://docs.gnunet.org/latest/installing.html ? is there a traceroute like feature in gnunet? because I wonder how many hosts there is between me and info.higepi.gnunet.gns.alt, because higepi.gnunet.gns.alt is still in cache and I started the query 50 min ago... |
|
|
Only a few peers is expected, because the fixed I had to make affect the wire format, so "old" i.e. non git head peers will no longer be able to connect. Your path chose the "system configuration" which means that some gnunet services run as a system user (e.g. "gnunet" or root) and those are shared between all actual gnuent users. This is so that multiple users can share the same node (Peer ID, DHT) but have their own user-specific identities. This means that after you start the system services, you also need to start the remaining services for a user (gnunet-arm -s as user). That will start users services (identity, namestore etc) Generally, for testing, it is easier to only start the whole peer as user. |
|
|
ok the name resolution did succeed, but took ages... 2026-08-05T21:25:27.527848+0200 gnunet-gns-35901 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `TXT' records under `info.higepi.gnunet.gns.alt' ... 2026-08-06T02:02:18.690705+0200 gnsrecord-35901 DEBUG Determined expiration time for block with 2 records to be Thu Aug 06 02:32:04 2026 <<< 2 record(s) found: TXT: `Thu Aug 06 02:02:04 2026: Connected (R) M0J8 (timeout in 248 s)' TXT: `Thu Aug 06 02:02:04 2026: Awaiting initiation (R) E2R1 (timeout in 0 ms)' Record set expires in 29 m. 5h... I will create a ticket in gns, since it's not a bootstrap issue I also found some interesting information in https://docs.gnunet.org/latest/users/configuration.html for my "better security pratice" question and also configuration |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-03 00:28 | Jllx | New Issue | |
| 2026-08-03 00:40 | Jllx | Note Added: 0029355 | |
| 2026-08-04 17:27 | schanzen | Note Added: 0029363 | |
| 2026-08-04 17:43 | schanzen | Target Version | => 0.29.0 |
| 2026-08-04 17:43 | schanzen | Assigned To | => schanzen |
| 2026-08-04 17:43 | schanzen | Status | new => assigned |
| 2026-08-04 20:18 | schanzen | Note Added: 0029364 | |
| 2026-08-04 21:23 | Jllx | Note Added: 0029365 | |
| 2026-08-05 00:06 | Jllx | Note Added: 0029366 | |
| 2026-08-05 06:52 | schanzen | Note Added: 0029370 | |
| 2026-08-05 06:59 | schanzen | Note Added: 0029371 | |
| 2026-08-05 20:58 | schanzen | Note Added: 0029375 | |
| 2026-08-05 21:06 | Jllx | Note Added: 0029376 | |
| 2026-08-05 22:12 | Jllx | Note Added: 0029377 | |
| 2026-08-06 10:05 | schanzen | Note Added: 0029379 | |
| 2026-08-06 10:05 | schanzen | Note Edited: 0029379 | |
| 2026-08-06 10:06 | schanzen | Note Edited: 0029379 | |
| 2026-08-06 10:39 | Jllx | Note Added: 0029380 |
