Re: Help with joining the gnunet

t3sserakt <[email protected]> Wed, 5 Jan 2022 09:16:19 +0000
Newsgroups	gmane.network.gnunet.general
Message-ID	<[email protected]>
Hey Bandura,

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 01 Jan 2022 16:39:34 +0000
> From: Bandura Yeo Borissowitsch <[email protected]>
> To: [email protected]
> Subject: Help with joining the gnunet
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hello,
>
> I wanted to ask if you can give me a "Hello" address with
> gnunet-peerinfo -gn so that I can connect to GnuNet.

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, and when succeeded your peer is already 
"connected" to GNUnet.

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.

> Mine is
> gnunet://hello/9KF98WY7H01DDF86AYZ0AY24760ZVEC9CTHGYXPJ321RECG82R50+20220102041317+tcp+tcp.0.[fd42:42:42:42::1009]:2086+20220102041317+tcp+tcp.0.[21a:f19a:3717:4c70:fe9a:3748:3d3f:fde2]:2086+20220102041317+tcp+tcp.0.[::1]:2086+20220102041317+tcp+tcp.0.10.8.0.11:2086+20220102041317+tcp+tcp.0.172.17.0.1:2086+20220102041317+tcp+tcp.0.10.0.2.2:2086+20220102041317+tcp+tcp.0.192.168.122.1:2086+20220102041317+tcp+tcp.0.192.168.84.87:2086+20220102041317+tcp+tcp.0.127.0.0.1:2086

A peer of mine

88RXABKJNMT426FY81N2DXN0M2X37SW5Q1NR005YPDZ1Q7A22CHG

has two paths

$ gnunet-cadet -p 9KF98WY7H01DDF86AYZ0AY24760ZVEC9CTHGYXPJ321RECG82R50
Path of length 4: EDCA *9KF9* EJ55 Y924
Path of length 3: EDCA *9KF9* EJ55

to your peer. So obviously your peer is already connected to GNUnet.

 From this

$ gnunet-cadet -P |grep 9KF98
9KF98WY7H01DDF86AYZ0AY24760ZVEC9CTHGYXPJ321RECG82R50 tunnel: N, paths: 2

you can see that my peer thinks we have no tunnel established, which is 
quite likely, because we did not try to "connect" via cadet.

If you like to do further experiments, you can contact me directly. 
Would be interesting, if you can "see" my peer, like I did yours. How is 
your node connected? Looks like it is behind some kind of NAT.

Sending messages via cadet is sometimes unreliable. To get this stable 
we are atm redesigning the transport layer, and after that we also might 
need to look after bugs in the cadet layer.

Happy hacking!

t3sserakt
pEpkey.asc (application/pgp-keys, 3 KB)