[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUnet

From: t3sserakt
Subject: Re: GNUnet
Date: Tue, 1 Nov 2022 10:09:35 +0000

I also like to add that there are several interpretations of the term "connection" in GNUnet.

First and foremost there are direct connections between peers via the Transport layer of GNUnet.

If you start your peer it automatically tries to establish direct connections to other peers (it knows), and when succeeded your peer is already "connected" to GNUnet. But those "connection" is not E2E encrypted, which is the responsibility of the Core layer. The output of


gives you all the E2E encrypted direct connections.

Then there are connections in terms of the Cadet routing layer. This means your peer knows of paths to others peers. If you like to send a message to another peer the Cadet layer sets up a so called tunnel, which one also could interpret as some kind of connection.

I guess you tried gnunet-cadet, because you wrote

"tried to connect to the other peer and port"


gnunet-cadet -P

lists peers you might have paths to, which means it should be able to send message via the Cadet layer to that peer.

There some issues with the Transport and Cadet layer, which might make sending messages via the Cadet layer unreliable. We are right now working on a redesign of the Transport layer to get rid of those problems. Unreliable means, sometimes sending messages via Cadet is not a problem at all working instantaneously, sometimes an initial message needs some minutes, and after that the following message are received instantaneously, and sometimes messages to not arrive at all, and you have to restart the peers to try again.

The probability of getting a connection is higher if have a direct connection between peers. You can import

gnunet-peerinfo -p HELLO

the hello string you get by

gnunet-peerinfo -sg

to achieve a direct connection to the peer you imported the hello string from.

If the peers are natted this might also be an issue. Easiest way to make a natted peer reachable is to open the port 2086 (default GNUnet port) in your router.

I hope this might help.

- t3sserakt

On 01.11.22 03:14, Martin Schanzenbach wrote:

Can you elaborate on what exactly you are trying to achieve?
If you start two peers those will not necessarily automatically connect
to each other directly.
By nature of the p2p overlay, the peers may be connected only
indirectly, which is fine.
You do need to have at least one connection for the routing to work,
usually this is to peer Y924.
You can check your (direct) connections with

$ gnunet-core

It is also sometimes prudent to wait a bit until the connections are set


On 31.10.22 21:46, Rowan de Jong wrote:
Dear Mr/Mrs,

Our names are Rowan de Jong and Mart van der Veen, we are students from the
Netherlands from the school De Lage Waard. We are making a report about GNUnet
and we have some questions. We have a problem, me and my friend’s GNUnet
systems do not connect with eachother. We followed all the steps on your site,
but after one of us tried to connect to the other peer and port it didn’t
connect. Is there someone who could help us? We would really appreciate it.

Thanks in advance!


Rowan de Jong and Mart van der Veen

Attachment: OpenPGP_0x524982A0100F7490.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]