Unable to recevie files through IBB

[PaoloP79]

Good morning,
I'm experiencing, what I think, is an erroneous behaviour of dino.

The reference scenario is as follow

• I've three node on a network, there is no routing betwee nodes, that means the can not talk directly each other, but only through their default gateway that is running an istance of openfire xmpp server.
• The only traffic allowed is xmpp
• On two node I'have another xmpp client, I will call it clientA
• On one node I'm testing dino (compiled from the master banch e62725db395d)

When I send a file (say a jpeg) between the two nodes running clientA I can see from their logs that they first try to directly connect each other. Of course this is impossible, so the initiator sends a "fallback to ibb" message (I'm plain, I don't know if it is a standard or custom message), then the parties establish a IBB session and the file is transferred without issue.

If I send the same file between a node running clientA and dino, what I see is that, as before, they first try to use SOCKS5 to exchange the file. Because the use of SOCKS5 fails the initiator (clientA) send, again as before, a "fallback to ibb" message to dino, but from the logs I see, it seems that this message is never received or ignored, anyway.

The following log shows that dino send back a candidate-error message, the other parties send a "fallback to ibb" message, but seems that is never recevied. The truth is that dino seems to hangs in an infinite loop in some place, because the CPU go to 100%.

XMPP OUT [<dino_jid>@my.xmpp.domain stream:0x55bba2907b00 thread:0x55bb9c942200 2024-02-13T08:11:01+0000]
<{jabber:client}:iq {jabber:client}:id='7e6136dc-6cb3-4a02-9933-ca4c6e1d2c48' {jabber:client}:type='set' {jabber:client}:to='<clientA_jid>@my.xmpp.domain/ClientA.ABDC'>
  <{urn:xmpp:jingle:1}:jingle {http://www.w3.org/2000/xmlns/}:xmlns='urn:xmpp:jingle:1' {urn:xmpp:jingle:1}:action='transport-info' {urn:xmpp:jingle:1}:initiator='<clientA_jid>@my.xmpp.domain/ClientA.ABDC' {urn:xmpp:jingle:1}:sid
='PmsEgJ6MT8qxxD1Au6N4Gg'>
    <{urn:xmpp:jingle:1}:content {urn:xmpp:jingle:1}:creator='initiator' {urn:xmpp:jingle:1}:name='2zgMf/fRGFm2gJbzuKgXrg'>
      <{urn:xmpp:jingle:transports:s5b:1}:transport {http://www.w3.org/2000/xmlns/}:xmlns='urn:xmpp:jingle:transports:s5b:1' {urn:xmpp:jingle:transports:s5b:1}:sid='WDLtWiCUr1DPT1riFOeeuw'>
        <{urn:xmpp:jingle:transports:s5b:1}:candidate-error />
      </{urn:xmpp:jingle:transports:s5b:1}:transport>
    </{urn:xmpp:jingle:1}:content>
  </{urn:xmpp:jingle:1}:jingle>
</{jabber:client}:iq>

XMPP OUT [<dino_jid>@my.xmpp.domain stream stream:0x55bba2907b00 thread:0x55bb9c942200 2024-02-13T08:11:01+0000]
<{urn:xmpp:sm:3}:r {http://www.w3.org/2000/xmlns/}:xmlns='urn:xmpp:sm:3' />

(dino:5612): GLib-Net-DEBUG: 08:11:01.814: CLIENT[0x55bb9cd3e7c0]: starting to write 483 bytes to TLS connection
(dino:5612): GLib-Net-DEBUG: 08:11:01.814: CLIENT[0x55bb9cd3e7c0]: claiming operation OP_WRITE
(dino:5612): GLib-Net-DEBUG: 08:11:01.814: CLIENT[0x55bb9cd3e7c0]: claiming operation OP_WRITE succeeded
(dino:5612): GLib-Net-DEBUG: 08:11:01.814: CLIENT[0x55bb9cd3e7c0]: yielding operation OP_WRITE
(dino:5612): GLib-Net-DEBUG: 08:11:01.814: CLIENT[0x55bb9cd3e7c0]: successfully write 483 bytes to TLS connection
(dino:5612): libdino-DEBUG: 08:12:05.671: connection_manager.vala:343: NetworkMonitor: Network reported offline
(dino:5612): libdino-DEBUG: 08:12:06.990: connection_manager.vala:343: NetworkMonitor: Network reported offline
XMPP OUT [<dino_jid>@my.xmpp.domain stream stream:0x55bba2907b00 thread:0x55bb9c942200 2024-02-13T08:12:37+0000]
<{jabber:client}:iq {jabber:client}:id='d8e5cb16-2901-4fa0-80dd-5e8ae48dc6f3' {jabber:client}:type='get' {jabber:client}:to='my.xmpp.domain'>
  <{urn:xmpp:ping}:ping {http://www.w3.org/2000/xmlns/}:xmlns='urn:xmpp:ping' />
</{jabber:client}:iq>

The next test I did was a try to forze the parties to use directly IBB insted of trying SOCKS5 before, so I commented the following lines in libdino/src/service/module_manager.vala

 //module_map[account].add(new Xep.Socks5Bytestreams.Module())
 //module_map[account].add(new Xep.JingleSocks5Bytestreams.Module());

This way what I can observe is that now, when I send a file from clientA to dino, the transfer is inititated directly using IBB, but dino show immediately that the transfer fails, while on clientA I can see that transfer is going on and termintate whitout issues.
This happen because it seems that dino give a dowload error even before the IBB session is opened, to be more precise the flow seems to be as follow

• IBB session establishement
• FAIL error from dino (and related message of failure on the GUI)
• IBB session open
• IBB data message receipt
• IBB session close

Follow what I think are relevant sections of the dino log file

(dino:6035): libdino-WARNING **: 08:16:36.942: file_manager.vala:266: Error downloading file: Establishing connection did not work
.........
.........
<{jabber:client}:iq {jabber:client}:type='set' {jabber:client}:id='pzpOFO--v9jX' {jabber:client}:from='<clientA_jid>@my.xmpp.domain/ClientA.ABDC' {jabber:client}:to='<dino_jid>@my.xmpp.domain/dino.c45a4464'>
  <{http://jabber.org/protocol/ibb}:open {http://www.w3.org/2000/xmlns/}:xmlns='http://jabber.org/protocol/ibb' {http://jabber.org/protocol/ibb}:sid='9oQUUvdnFYUAkqkmqydhjw' {http://jabber.org/protocol/ibb}:block-size='8192' {http://jabber.org/protocol/ibb}:stanza='iq' />
</{jabber:client}:iq>

XMPP OUT [<clientA_jid>@my.xmpp.domain/ClientA.ABDC stream:0x55d5646f7d50 thread:0x55d55e6c7000 2024-02-13T08:16:37+0000]
<{jabber:client}:iq {jabber:client}:id='pzpOFO--v9jX' {jabber:client}:to='<clientA_jid>@my.xmpp.domain/ClientA.ABDC' {jabber:client}:type='result' />

---

UPDATE!

I think I found what is happening, but, because I'm almost new to both vala and xmpp, I'm not yet able to understand if it is a consequence of the elimination of the SOCKS5 related modules or not.

First point: the message shown in the log reported below

(dino:6035): libdino-WARNING **: 08:16:36.942: file_manager.vala:266: Error downloading file: Establishing connection did not work

is a bit misleading and the message shown by the log should be "can't do non-async closes on in-band bytestreams".
The excecption is thrown inside the accept(....) function in xmpp-vala/src/module/xep/0234_jingle_file_transfer.vala. To me more precise the statement throwing the exception is at line 280

io_stream.output_stream.close();

From the knowledge I'have, at this point, of the dino code, io_stream is an object that has the methods defined in xmpp-vala/src/module/xep/0047_in_band_bytestreams.vala. I saw in this file the presence of close_async() method. So I modified the code to call it and the exception is no more thrown.

Second point: After the fix (let me call it so, even if I'm not shure if it is a fix or not) now another excecption is thrown that say can't do non-async reads on in-band bytestreams. I was able to track the problem and I found that the exception is thrown inside the function download_file_internal(...) defined in ./libdino/src/service/file_manager.vala. To be more precise the allegedly faulty code is

 while ((read = yield input_stream.read_async(buffer, Priority.LOW, file_transfer.cancellable)) > 0) {
    buffer.length = (int) read;
    yield os.write_async(buffer, Priority.LOW, file_transfer.cancellable);
    buffer.length = 1024;
}

At this point I'm a bit confused. The statment yield input_stream.read_async(buffer, Priority.LOW, ile_transfer.cancellable)) seems to call the function input_stream.read()` instead of input_stream.read_async().``
As I said before I'm new to vala, I never saw it before reading the dino code, I read some documentation about async functions but, in truth, I'm unable to understand what is happening here.

If a developer is reading I would be very pleased is it can explain me the reason of this "strange behaviour".

Any help is apreciated, let me know if you need more informations.

Thankyou in advance