help-gnunet
[Top][All Lists]
Advanced

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

GNUnet cadet


From: Rowan De jong
Subject: GNUnet cadet
Date: Mon, 21 Nov 2022 17:04:03 +0100


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 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

 


reply via email to

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