[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
- [GNUnet-developers] Troubleshooting CADET,
peter <=
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, peter, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, Christian Grothoff, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, carlo von lynX, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, ng0, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, Julius Bünger, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, ng0, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, xrs, 2017/10/28