Hi,
I hope the recent release (0.21.1) fixes the issues you have seen.
BR
Martin
On Wed, 2024-03-13 at 19:53 +0100, Martin Schanzenbach wrote:
did you install using meson? then you may be missing dhtu.conf
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)
```
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
gnunet.log