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

[Christian Grothoff]

Well, that could be it, given that we do sometimes see very large
transport delays. Not sure, of course. Now, with transport working
properly, 90s should of course be sufficient...

On 3/22/19 9:49 AM, t3sserakt wrote:
> 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
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>>
>> _______________________________________________
>> 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
Description: OpenPGP digital signature