*Thanks for responding. We tried the solutions you offered, but it still
doesn't work. I replied to the solutions below.*
*I put our question in the developer mailing list not knowing it was for
the developers. So I will move the conversation here. We are sorry for any
inconveniences.*
Rowan de Jong and Mart van der Veen
>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
>
>gnunet-core
>
>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"
>
>right?
*Yes, we tried the gnunet-cadet option.*
>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.
*If we use the gnunet-cadet -P. My pc displays 8 different peers including
my own. On one of the peers (Y924NSH) it says tunnel: Y, paths: 1.
The other ones say tunnel: N, paths: 0. On Mart's pc it lists 8 peers
including his own. The top one (same as Rowan's) says tunnel: N, paths: 1.
The other ones say * *tunnel: N, paths: 0. We thought maybe the problem
lays there. But we have no idea how to change/fix it.*
>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:
>> Hi!
>>
>> Can you elaborate on what exactly you are trying to achieve?
*We are trying to achieve a connection to chat and maybe later to upload
files from my pc to the pc of Mart.*
>> 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
>>
*If we check on Mart's pc. We get the message: wo nov 16 22:41:48 2022:
connection established Y924 (timeout in 299s). This is the same on
Rowan's pc.*
>> It is also sometimes prudent to wait a bit until the connections are set
>> up.
*We waited for 15 minutes after we opened a port and connected to it. But
we didn’t get any response.*
>>
>> Br
>> Martin
Thanks for responding. We tried the solutions you offered, but it still
doesn't work. I replied to the solutions below.
I put our question in the developer mailing list not knowing it was for the
developers. So I will move the conversation here. We are sorry for any
inconveniences.
Rowan de Jong and Mart van der Veen
>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 outp
