*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
