I looked into the code. Idle tunnel means no channel, but it is checked only if
CADET_TUNNEL_KEY_UNINITIALIZED and the destroy_tunnel task is scheduled and triggered after 90 seconds On 21.03.19 21:16, t3sserakt wrote: > > 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnunet-developers > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
