View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011713 | GNUnet | GNS | public | 2026-08-06 10:48 | 2026-08-09 12:07 |
| 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 | 0011713: GNS takes ages to resolv | ||||
| Description | during bootstrap issue investigation https://bugs.gnunet.org/view.php?id=11711 @schanzen did create a TXT dns record in `info.higepi.gnunet.gns.alt' that expire every 30 min when trying to get this records : $ gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug 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... | ||||
| Tags | No tags attached. | ||||
|
|
This needs testing (and some bug hunting). I cannot reproduce such long lookups, but my peers are also rather close to each other and one of them is publishing this record. |
|
|
I tried to fix this in the last couple of commits. Maybe you can test on your side. |
|
|
I now have a cleaner setup of gnunet : multiuser services are started using a init.d openrc script, using gnunet user with home directory /var/lib/gnunet, access mode rwx------ I now also start user services for my user when I try to resolve `gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug` with the user, I have lot of util-client-179138 DEBUG Failed to establish connection to `gns', no further addresses to try, will try again in xxx s. when I `su gnunet -c "gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug" ` there is no such error, and it faster fail ;) 2026-08-06T23:24:37.270459+0200 gnunet-gns-179694 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `TXT' records under `info.higepi.gnunet.gns.alt' ... 2026-08-06T23:27:37.421824+0200 gns-api-179694 DEBUG Received lookup reply from GNS service (0 records) <<< 0 record(s) found: 2026-08-06T23:27:37.421848+0200 util-scheduler-179694 DEBUG GNUNET_SCHEDULER_shutdown with latest update, I've much more peers : $ gnunet-transport -a PEER ROUTE VIA CORE-WIN STALLED PENDING RTT 0TG0 dv (2 hops) udp,tcp 4 0 0 856 ms E2R1 dv (2 hops) udp,tcp 4 0 0 605 ms PBM3 dv (2 hops) udp,tcp 4 0 4 553 ms V5T8 dv (2 hops) udp,tcp 4 0 2 367 ms V512 dv (2 hops) udp,tcp 4 0 0 132 ms 2GPG dv (2 hops) udp,tcp 4 0 0 275 ms 7Y6R dv (2 hops) udp,tcp 4 0 4 105 ms DXYV direct udp,tcp 4 0 0 0 ms YSEZ dv (2 hops) udp,tcp 4 0 0 421 ms and don't know if it's related to setup, or to your changes, but I feel like the connection and getting peers was much more fast, almost instant (I run the gnunet-transport command a few seconds after starting the service, and it was already populated |
|
|
by the way, how do I know my peer ID? |
|
|
su gnunet -c "gnunet-gns -t EDKEY -u higepi.gnunet.gns.alt -L debug" 2026-08-06T23:41:09.871528+0200 gnunet-gns-181169 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `EDKEY' records under `higepi.gnunet.gns.alt' ... 2026-08-06T23:44:10.052555+0200 gns-api-181169 DEBUG Received lookup reply from GNS service (0 records) <<< 0 record(s) found: 2026-08-06T23:44:10.052595+0200 util-scheduler-181169 DEBUG GNUNET_SCHEDULER_shutdown so both resolv did failed, but faster ;) (about 3min) maybe this could be great to have some "traceroute" like feature in gnunet-transport? not displaying ip addresses but peer ID instead? I don't know how the DHT is accessed, and if there is some "relays" (for example if I connect to DXYV, and ask for dns resolution, but since DXYV don't have the answer, it forward the request to it's own peer, so OTG0, E2R1... (is "dv (2 hops)" means that there is DXYV between me and the (for example) 0TG0?) if yes, this could be interesting to have some "on the fly info" like HH:mm:ss sending request to DXYV HH:mm:ss DXVY asked 0TG0 : no answer (duration ms) HH:mm:ss DXVY asked E2R1 : no answer (duration ms) HH:mm:ss DXVY asked PBM3 : PBM3 asked XYZA : no answer (duration ms) ... |
|
|
or maybe something like HH:mm:ss sending request to DXYV HH:mm:ss DXYV : no answer, forwarding request HH:mm:ss DXVY.0TG0 : no answer (duration ms between DXVY request and OTG0 answer) HH:mm:ss DXVY.E2R1 : no answer (duration ms between DXVY request and E2R1 answer) HH:mm:ss DXVY.PBM3 : no answer, forwaring request (duration ms between DXVY request and PBM3 answer) HH:mm:ss DXVY.PBM3.XYZA : no answer (duration ms between PBM3 request and XYZA answer) ... or if trusting ntp, instead of duration, UTC start time and answer time... (format HH:mm:ss.xms) this would help finding if this is a connection issue (for example PBM3 to XYZA connection is really slow) and if there is some issue reaching the target that have the DHT information I don't know if there is some kind of cache mecanism like dns has (when requesting a name in dns, if the dns server you connect to don't have the answer, it will try to resolve and cache the result, so next time you ask to resolve, it will answer you straight) but having such trace could help resolv issue linked to cache.... |
|
|
I am pretty sure we log this to some degree, but you are right that we may want to optionally have this more explit through a callback in the API. Unfortunately, I cannot reproduce the DHT issues anymore. However, I am seeing connectivity issues again with multiple peers behind NAT. (its a game of whack a mole) |
|
|
for me (behind NAT, but maybe gnunet use the ipv6 to solve the issue) the connections seems stable. but the gns still don't resolve (tried 3 times today, now that it's fast) |
|
|
Maybe try again today a couple of times. The publishing peer are not connected for some time yesterday. I think the GNS issue may still in the end be a connectivity issue. Because if your peer or the publishing peer loses connectivity to the network, of course resolution becomes impossible. May last couple of resolution tests, however, with the stable connections for around 24h, allowed me to successfully resolve. |
|
|
tried at 22:00 UTC+2 (paris/bruxel...) and still no answer |
|
|
got an answer (instant)!!!! previous try (unsuccessful): # su gnunet -c "gnunet-transport -a" PEER ROUTE VIA CORE-WIN STALLED PENDING RTT 55H0 dv (2 hops) udp,tcp 4 0 0 0 ms V512 dv (2 hops) udp,tcp 4 0 0 622 ms 25VY dv (2 hops) udp,tcp 4 0 0 141 ms 2GPG dv (2 hops) udp,tcp 4 0 0 412 ms 4SCZ dv (2 hops) udp,tcp 4 0 0 267 ms 8FAQ dv (2 hops) udp,tcp 4 0 4 180 ms DXYV direct udp,tcp 4 0 0 34 s # su gnunet -c "gnunet-gns -t EDKEY -u higepi.gnunet.gns.alt -L debug" 2026-08-08T22:05:12.205259+0200 gnunet-gns-1035772 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `EDKEY' records under `higepi.gnunet.gns.alt' 2026-08-08T22:08:12.385561+0200 gns-api-1035772 DEBUG Received lookup reply from GNS service (0 records) <<< 0 record(s) found: 2026-08-08T22:08:12.385583+0200 util-scheduler-1035772 DEBUG GNUNET_SCHEDULER_shutdown last try (successful) : # su gnunet -c "gnunet-transport -a" PEER ROUTE VIA CORE-WIN STALLED PENDING RTT 55H0 dv (2 hops) udp,tcp 4 0 0 0 ms M0J8 direct udp 4 0 0 0 ms V512 dv (2 hops) udp,tcp 4 0 0 224 ms 4SCZ dv (2 hops) udp,tcp 4 0 0 210 ms DXYV direct udp,tcp 4 0 60 0 ms J5YY dv (2 hops) udp,tcp 4 0 1 427 ms N78G dv (2 hops) udp,tcp 4 0 0 0 ms # su gnunet -c "gnunet-gns -t EDKEY -u higepi.gnunet.gns.alt -L debug" 2026-08-08T22:43:01.032108+0200 gnunet-gns-1153392 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `EDKEY' records under `higepi.gnunet.gns.alt' 2026-08-08T22:43:01.037577+0200 gnsrecord-1153392 DEBUG Determined expiration time for block with 1 records to be Sun Aug 09 22:33:27 2026 <<< 1 record(s) found: EDKEY: `000G056EKDRX45PDSVG8BCBH74A86X4DNK4FYNAJ0WVRX9B92H7SYVBG3M' Record set expires in 23 h. 2026-08-08T22:43:01.037606+0200 util-scheduler-1153392 DEBUG GNUNET_SCHEDULER_shutdown |
|
|
tried to get the TXT record since the EDKEY resolved # su gnunet -c "gnunet-transport -a" PEER ROUTE VIA CORE-WIN STALLED PENDING RTT E667 dv (2 hops) udp,tcp 4 0 0 809 ms M0J8 direct udp 4 0 0 0 ms V512 dv (2 hops) udp,tcp 4 0 0 224 ms 25VY dv (2 hops) udp,tcp 4 0 0 427 ms DXYV direct udp,tcp 4 0 54 0 ms J5YY dv (2 hops) udp,tcp 4 0 1 427 ms # su gnunet -c "gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug" 2026-08-08T22:47:53.848117+0200 gnunet-gns-1153756 DEBUG Loading block plugin `libgnunet_plugin_gnsrecord_gns' >>> Looking for `TXT' records under `info.higepi.gnunet.gns.alt' 2026-08-08T22:50:54.009106+0200 gns-api-1153756 DEBUG Received lookup reply from GNS service (0 records) <<< 0 record(s) found: 2026-08-08T22:50:54.009127+0200 util-scheduler-1153756 DEBUG GNUNET_SCHEDULER_shutdown since I suspected it was some host issue, I monitored the connections sadely most of the peers disapeared so if I'm connected to ----------55H0-------------V512----25VY---- 2GPG--- 4SCZ---FAQ----DXYV-------------------------: no answer ----------55H0---M0J8---V512--------------------------- 4SCZ-------------DXYV-----J5YY-----N78G-: answer E667-------------M0J8----V512---25VY-------------------------------------DXYV------J5YY--------------: no answer this means that I have to be connected to N78G to get an answer, and if I'm not connected to it, it won't resolve I don't remember seeing N78G before. |
|
|
this looks as if "recursive query" don't works anymore... before it tooks ages, but it eventually succeed, now, I've to have a connection to the host that have the DHT record to get an answer.... |
|
|
Thank you for the data. I will look into it. I can confirm that I have similar effects. |
|
|
Likely not an issue with N78G, but with the DHT itself and how it replicates/resolves data |
|
|
could be nice, if we know the peer to reach if we can "ping" it : gnunet-ping N78G or gnunet-traceroute N78G |
|
|
maybe this is a hint also : I have lot of "pending" on the only "direct" peer <code> PEER ROUTE VIA CORE-WIN STALLED PENDING RTT V5T8 dv (2 hops) udp,tcp 4 0 0 350 ms V512 dv (2 hops) - 4 0 0 0 ms DZ5J dv (2 hops) udp,tcp 4 0 0 871 ms DXYV direct udp,tcp 4 0 78 0 ms N78G dv (2 hops) udp,tcp 4 0 0 6 m ZPRG dv (2 hops) udp,tcp 4 0 0 161 ms </code> by the way, what "CORE-WIN" "STALLED" "PENDING" means? nothing in html documents.... |
|
|
since N78G was in peer list, I tried to resolve `su gnunet -c "gnunet-gns -t TXT -u info.higepi.gnunet.gns.alt -L debug"` pending on DXYV raised from 78 to 322 and N78G disappeared from list (it's RTT was 6m so, maybe it wasn't here long ago) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-06 10:48 | Jllx | New Issue | |
| 2026-08-06 11:17 | schanzen | Note Added: 0029384 | |
| 2026-08-06 22:58 | schanzen | Note Added: 0029396 | |
| 2026-08-06 23:38 | Jllx | Note Added: 0029397 | |
| 2026-08-06 23:44 | Jllx | Note Added: 0029398 | |
| 2026-08-06 23:58 | Jllx | Note Added: 0029399 | |
| 2026-08-07 00:14 | Jllx | Note Added: 0029400 | |
| 2026-08-07 10:12 | schanzen | Note Added: 0029401 | |
| 2026-08-07 10:12 | schanzen | Target Version | => 0.29.0 |
| 2026-08-07 15:49 | Jllx | Note Added: 0029404 | |
| 2026-08-08 08:25 | schanzen | Note Added: 0029410 | |
| 2026-08-08 08:25 | schanzen | Assigned To | => schanzen |
| 2026-08-08 08:25 | schanzen | Status | new => assigned |
| 2026-08-08 22:04 | Jllx | Note Added: 0029416 | |
| 2026-08-08 22:46 | Jllx | Note Added: 0029417 | |
| 2026-08-08 23:08 | Jllx | Note Added: 0029418 | |
| 2026-08-08 23:14 | Jllx | Note Added: 0029419 | |
| 2026-08-09 07:34 | schanzen | Note Added: 0029420 | |
| 2026-08-09 07:35 | schanzen | Note Added: 0029421 | |
| 2026-08-09 09:59 | Jllx | Note Added: 0029422 | |
| 2026-08-09 12:00 | Jllx | Note Added: 0029424 | |
| 2026-08-09 12:07 | Jllx | Note Added: 0029425 |
