I looked into the code. Idle tunnel means no channel, but it is
checked only if
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!
t3ss
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
_______________________________________________
GNUnet-developers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers
_______________________________________________
GNUnet-developers mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc