|
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
[Prev in Thread] | Current Thread | [Next in Thread] |