gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] Troubleshooting CADET


From: peter
Subject: [GNUnet-developers] Troubleshooting CADET
Date: Thu, 26 Oct 2017 14:53:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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




reply via email to

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