Am 13. März 2024 19:29:33 MEZ schrieb t3sserakt <t3ss@posteo.de>:
I guess the log level of your peer is not DEBUG.
Please start the peer like this
GNUNET_FORCE_LOG=';;;;DEBUG' GNUNET_FORCE_LOGFILE='gnunet.log' gnunet-arm -s
On 13.03.24 17:46, marty1885 wrote:
Hi,
Thanks for the direction. I looked into my GNUnet logs and see DHT is spamming "No DHT underlays configured" message.
I have attached a debug log. GNUnet generated more then 10MB in less then 1 minutes.
2024-03-14T00:38:24.453491+0800 dht-3589431 ERROR No DHT underlays configured!
2024-03-14T00:38:24.477297+0800 dht-3589432 ERROR No DHT underlays configured!
2024-03-14T00:38:24.501079+0800 dht-3589433 ERROR No DHT underlays configured!
2024-03-14T00:38:24.518726+0800 dht-3589434 ERROR No DHT underlays configured!
2024-03-14T00:38:24.535907+0800 dht-3589435 ERROR No DHT underlays configured!
2024-03-14T00:38:24.555994+0800 dht-3589436 ERROR No DHT underlays configured!
2024-03-14T00:38:24.576093+0800 dht-3589437 ERROR No DHT underlays configured!
...
On Wednesday, March 13th, 2024 at 6:45 PM, t3sserakt <t3ss@posteo.de> wrote:
Hey Martin,
the actual log of the bootstrap peer begins 9 in the morning on the 12th. I can not see any log entry for your peer CCXH in the bootstrap peer logs.
Do you have any output if you grep for "Abort" in yours peer log file?
You could start your peer with log level DEBUG to see more details what your peer is doing, and could provide us the log entries of your log running for a minute after starting the peer with log level DEBUG.
- t3sserakt
On 13.03.24 11:10, marty1885 wrote:
Hi,
Yes. I've restarted GNUnet several times. For safety I've restarted it once again after reeving your reply. Still can't bootstrap.
Martin
On Tuesday, March 12th, 2024 at 10:15 PM, Schanzenbach, Martin <schanzen@gnunet.org> wrote:
Hi,
did you try again the last few days?
We are currently observing better connectivity after fixing a
configuration mistake on the bootstrap peer.
Best
Martin
On 10.03.24 15:41, marty1885 wrote:
I deleted the databases for namestore and peerstore to get all processes running (peerstore and namestore was failing). But still no peer connections.
`❯ gnunet-arm -I Services (excluding stopped services): (started: 23 / stopped: 22) cadet (binary='gnunet-service-cadet', status=started) core (binary='gnunet-service-core', status=started) datastore (binary='gnunet-service-datastore', status=started) dht (binary='gnunet-service-dht', status=started) fs (binary='gnunet-service-fs', status=started) gns (binary='gnunet-service-gns', status=started) hostlist (binary='gnunet-daemon-hostlist', status=started) identity (binary='gnunet-service-identity', status=started) namecache (binary='gnunet-service-namecache', status=started) namestore (binary='gnunet-service-namestore', status=started) nat (binary='gnunet-service-nat', status=started) nse (binary='gnunet-service-nse', status=started) peerstore (binary='gnunet-service-peerstore', status=started) reclaim (binary='gnunet-service-reclaim', 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) zonemaster (binary='gnunet-service-zonemaster', status=started)`
On Sunday, March 10th, 2024 at 3:00 PM, Schanzenbach, Martin schanzen@gnunet.org wrote:
Hi,
what does gnunet-arm -I output? Are all of the services running?
For example, the peerstore database layout changed, so you probably have
to delete your old database ($HOME/.local/share/gnunet/peerstore/sqlite.db).
The road to a stable TNG will also be bumpy, so we rely on reports such
as this to iron out the remaining bugs with it.
BR
Martin
On 10.03.24 06:08, marty1885 wrote:
Thanks for the reply.
I tried a few commands and still feels like my node is really not connected. DHT can't put, NSE returns a very small network size and GNS cannot resolve.
Is this expected?
```
❯ gnunet-core -si
Current local peer identity: CCXHBE49GRQVFAVFQ3BXVXPHHD63NG6ZNY31R0F59KVDZQA42PTG
(no further output)
❯ gnunet-dht-put -k "hello" -d "world" -e 40m
(hangs, this used to return almost immidately)
❯ gnunet-nse
1710047156276913 1.688203 0.755488 1.474102
❯ gnunet-gns -u gnunet.gns.alt -t PKEY
Looking for `PKEY' records under` gnunet.gns.alt'
(no output)
```
On Saturday, March 9th, 2024 at 11:39 PM, Schanzenbach, Martin schanzen@gnunet.org wrote:
Hi,
the behaviour of gnunet-core changed. You can check the new switches
with --help.
Long-term core connections are know to be problematic behind NATs, still.
But with a freshly started peer, "gnunet-core -i" should give you your
peer id, "gnunet-core -s" the connections (you can also combine the
switches).
The command should probably output the help when called without arguments.
BR
Martin
On 09.03.24 14:55, marty1885 wrote:
Hi all,
I've just built and installed the new GNUnet 0.21. But my node isn't connected to any peer after hours of waiting. Running gnunet-core shows no node is connected to me.
`❯ gnunet-core (no output)`
I have also checked `iotop` and can confirm gnunet-service-transport isn't doing much IO. While I was expecting at least hundreds of Kbps from experience in the past.
How can I connect to the network? Please let me know what information I can provide to diagnose the issue.
Best,
Martin