|Subject:||Re: [GNUnet-developers] gnunet-cadet information about a specific tunnel|
|Date:||Thu, 21 Mar 2019 21:16:11 +0100|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1|
is this major issue of identifying a specific tunnel documented somewhere?
Is this issue the reason why I only see the output of GNUNET_i2s_full (peer) where the tunnel is to be identified? Then the only additional information the '-t' option was giving is the identifiers of channels and connections.
Maybe I describe the problem I am searching after a bit more in detail, to let you know why I hoped the '-t' option could give me helpful information.
When I am testing the connectivity between nodes via cadet.
Sometimes the creation of a functioning channel I can use for
sending messages between nodes back and forth is within seconds,
sometimes it need minutes or hours, or I stop the testing, because
it takes to long. These tests are exploratory by doing manual real
world tests. No automatic testing.
In the case of not being able to send messages from one node to the other, I see - using the '-P' and '-T' option - on one node there is both a tunnel and a channel to the other node, on the other node I never see a channel and sometimes a tunnel. How is it possible to have one node having tunnel and channel to the other node, if the other nodes knows nothing about this channel and tunnel.
In the logs of the node sometimes knowing of a tunnel and
sometimes not, I see the tunnel is created and destroyed (because
being idle) in short intervals. So it looks like there is some
basic connectivity between those nodes, otherwise the tunnel would
not be created again and again, right?
So my best guess at the moment is, that we maybe might have a similar problem with the reliability of message send back and forth between nodes for channel creation.
Another finding is, that despite the fact that on one node
gnunet-cadet is showing me the existence of a tunnel all the time
I see a lot of
"Trying to make KX progress on Tunnel XXXX in state CADET_TUNNEL_KEY_AX_AUTH_SENT"
Before I start searching for the needle in the haystack, do you have any idea where to start my search in the code, or if it might be another reason to look after than reliability of channel creation messages?
On 20.03.19 08:47, Christian Grothoff wrote:
Hi t3ss, Well, what the old '-t' option showed wasn't really useful for current CADET, and it wasn't obvious to me what we would want to show that wasn't covered by the '-P', '-p' and '-T' options post #5385. Furthermore, there is the major issue of identifying a specific 'tunnel'. So right now, the '-p' option covers (most of?) this, and usually I would say that if there were more information to be returned, it could probably be included in the existing -pPT option family. That said, if you have some information to be returned that is not easily covered by extending -pPT, I'm not against re-introducing '-t'. It just didn't seem to serve any useful purpose anymore. Happy hacking! Christian On 3/20/19 7:15 AM, t3sserakt wrote:Hey Christian, after the fix of #5385 gnunet-cadet had no "-t" option anymore to show info about a specific tunnel. why that? Do we "only" need to reimplement this option with the asynchronous API that was introduced with #5385? Cheers t3ss
Description: OpenPGP digital signature
|[Prev in Thread]||Current Thread||[Next in Thread]|