Re: [GNUnet-developers] Troubleshooting CADET

[Schanzenbach, Martin]

Hi Peter,

I am not going to respond to the individual steps inline as I do not have 
anything particular to add there.
But I have experienced exactly the same issue. Unfortunately, I am not sure 
what the underlying problem is.
Maybe Christian knows of some open blocking bugs in cadet.

Personally, I have wondered if maybe the peers that are currently running (as 
in the current GNUnet P2P network which are served by through the gnunet.org 
hostlist) might not all be on the same version.
I am not sure what happens if a node encounters traffic that it does not 
understand due to a very old GNUnet version (0.10.x).
For example: As far as I remember, nodes drop blocks that are routed to/through 
them if they cannot validate them (using the respective block plugin).

Maybe try testing it using a dedicated P2P network of your own nodes?

BR
Martin

> On 26. Oct 2017, at 14:53, peter <address@hidden> wrote:
> 
> I often experience trouble connecting two nodes with gnunet-cadet
> whether I run both of them on the same PC or not. Here is what I do:
> 
> I set up two config files files as described in the gnunet-c-tutorial,
> I'll call them $cfg1 and $cfg2.
> 
> Then, if I'm testing both nodes on the same PC I run
> 
> $ gnunet-arm -s -c $cfg1
> $ gnunet-arm -s -c $cfg2
> 
> And then try to connect two gnunet-cadet programs:
> 
> $ gnunet-cadet -c $cfg2 -o my_secret_port
> 
> and
> 
> $ gnunet-cadet -c $cfg1 $PEER2_ID my_secret_port
> 
> Now on my work PC these two nodes sometimes connect and sometimes they
> don't. I feel as if it's less likely that they connect right after I
> start gnunet-arm after I haven't had them (the arm programs) running for
> a prolonged period.
> 
> On my hope PC it seems that if I issue the command:
> 
> $ gnunet-peerinfo -c $cfg2 -p `gnunet-peerinfo -c $cfg1 -g`
> 
> right after starting gnunet-arm the two cadets connect with a much
> higher probability. However, today I wanted to test this same thing on a
> digital ocean's droplet (not firewalled). So I - again - set up two
> nodes over there, tried to connect them, but without success for (I
> believe) more than an hour (even with the gnunet-peerinfo trick). The,
> all of the sudden I could connect.
> 
> Pushing my luck further, I then tried to connect my work PC with the one
> on the droplet. I don't know how many times I tried to connect in either
> direction (work PC -> droplet and droplet -> work PC) but without luck.
> Then I did the above gnunet-peerinfo trick and all of the sudden I could
> connect.
> 
> Unfortunately, I left my PC for about one hour and now I can't connect
> my work PC to the droplet again. I am still being able to connect two
> gnunet-cadets when they run on the same PC (either my local one or the
> droplet). Doing the gnunet-peerinfo trick is not helping this time.
> 
> When I do
> 
> gnunet-cadet -c $one_of_the_configs --peers
> 
> on both PCs, I can see
> 
> ...
> ID_OF_THE_OTHER_PEER tunnel: Y, paths: 6
> ...
> 
> and
> 
> ...
> ID_OF_THE_OTHER_PEER tunnel: Y, paths: 2
> ...
> 
> Not sure if my interpretation of this is correct, but I'm assuming it
> means that there should be at least one path either direction a message
> can hop between the two nodes.
> 
> Are these problems with establishing connections something you guys are
> aware of? Or am I doing something incorrectly?
> 
> Many thanks,
> 
> Peter
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP