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 [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
