[Top][All Lists]

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

Re: [GNUnet-developers] gnunet-cadet information about a specific tunnel

From: t3sserakt
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

Hi Christian,

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"

log messages.

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?

Happy hacking!


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!


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?



GNUnet-developers mailing list

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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