search

cmeng-git / atalk-android

xmpp/jabber client for android
Apache License 2.0
155 stars 56 forks source link

Crash on file share #196

Closed licaon-kter closed 1 year ago

licaon-kter commented 1 year ago

3.0.2/3.0.3 F-Droid, ejabberd server

Login, send messages, omemo or not, works fine.

Storage needed for 3.0.2 but not 3.0.3, attach via document picker.

OMEMO enabled or not.

XEP-0363 is available but not used.

In chat widget says "waiting for contact to accept your file".

Stack trace:

FATAL EXCEPTION: AsyncTask #13
Process: org.atalk.android, PID: 29462
java.lang.RuntimeException: An error occurred while executing doInBackground()
    at android.os.AsyncTask$4.done(AsyncTask.java:415)
    at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383)
    at java.util.concurrent.FutureTask.setException(FutureTask.java:252)
    at java.util.concurrent.FutureTask.run(FutureTask.java:271)
    at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:305)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
    at java.lang.Thread.run(Thread.java:923)
Caused by: java.lang.AbstractMethodError: abstract method "javax.xml.namespace.QName org.jivesoftware.smack.packet.FullyQualifiedElement.getQName()"
    at org.jivesoftware.smackx.jingle_rtp.AbstractXmlElement$Builder.addChildElements(AbstractXmlElement.java:453)
    at org.jivesoftware.smackx.jingle.element.JingleContentDescription$Builder.addPayload(JingleContentDescription.java:96)
    at org.jivesoftware.smackx.jingle.element.JingleContentDescription.<init>(JingleContentDescription.java:63)
    at org.jivesoftware.smackx.jingle_filetransfer.element.JingleFileTransfer.<init>(JingleFileTransfer.java:31)
    at org.jivesoftware.smackx.jingle_filetransfer.component.JingleFileTransferImpl.getElement(JingleFileTransferImpl.java:153)
    at org.jivesoftware.smackx.jingle_filetransfer.component.JingleFileTransferImpl.getElement(JingleFileTransferImpl.java:45)
    at org.jivesoftware.smackx.jingle.component.JingleContentImpl.getElement(JingleContentImpl.java:342)
    at org.jivesoftware.smackx.jingle.component.JingleSessionImpl.createSessionInitiate(JingleSessionImpl.java:163)
    at org.jivesoftware.smackx.jingle.component.JingleSessionImpl.sendInitiate(JingleSessionImpl.java:128)
    at org.jivesoftware.smackx.jet.JetManager.sendEncryptedFile(JetManager.java:136)
    at org.atalk.android.gui.chat.MetaContactChatTransport.jingleFileSend(MetaContactChatTransport.java:758)
    at org.atalk.android.gui.chat.MetaContactChatTransport.sendFile(MetaContactChatTransport.java:699)
    at org.atalk.android.gui.chat.MetaContactChatTransport.sendFile(MetaContactChatTransport.java:658)
    at org.atalk.android.gui.chat.ChatFragment$SendFile.doInBackground(ChatFragment.java:2585)
    at org.atalk.android.gui.chat.ChatFragment$SendFile.doInBackground(ChatFragment.java:2529)
    at android.os.AsyncTask$3.call(AsyncTask.java:394)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    ... 4 more
cmeng-git commented 1 year ago

Please explain what the following mean? Are your referring to permissions?

Storage needed for 3.0.2 but not 3.0.3, attach via document picker.

The is no change in sources/features between 3.0.2 and 3.0.3 in those logcat bug areas, no sure where the problem is. Need more info on the following: a. Are the testing between 2 aTalk clients? b. Is the problem reproducible, please give a more detail steps so I can perform debug here.

Can you also provide me the actual "session-initiate" content being sent, I need to figure what element is failing QName. e.g.

2022-11-10 09:56:24.733 6913-7344/org.atalk.android D/SMACK: SENT (0): 
    <iq to='leopard@atalk.sytes.net/atalk' id='4XHHJ-17' type='set'>
      <jingle xmlns='urn:xmpp:jingle:1' initiator='swordfish@atalk.sytes.net/atalk' action='session-initiate' sid='8LSFQEKY8CZ5ZEB5P26BD9JI'>
        <content name='cont-H4G6YZ1JUJZ25SP1' creator='initiator' senders='initiator'>
          <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
            <file>
              <date>
                2022-07-17T03:49:58.000+00:00
              </date>
              <media-type>
                image/jpeg
              </media-type>
              <name>
                swordfish.jpg
              </name>
              <size>
                7914
              </size>
              <hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>
                JPEMSj5h1xvkfRsQMdXP2kbyI8g9z9FL67W8sdmECQc=
              </hash>
            </file>
          </description>
          <transport xmlns='urn:xmpp:jingle:transports:s5b:1' dstaddr='54ffd53c2203777c7914d9b8b095bf34f28ff9d4' mode='tcp' sid='CWG7MDDRU7S13U921KU89M9S'>
            <candidate cid='EJTXSQH4QUG7M4BT' host='10.175.62.187' jid='swordfish@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='XD81LY3DZG4LC2FV' host='fe80::1004:3eff:fe07:ba63%wlan0' jid='swordfish@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='4US7LAGJ2VLSTTAF' host='192.168.1.167' jid='swordfish@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='RNT9M4ASI3QU6WIF' host='42.60.99.4' jid='proxy.atalk.sytes.net/55238004' port='7777' priority='0' type='proxy'/>
          </transport>
          <security xmlns='urn:xmpp:jingle:jet:0' name='cont-H4G6YZ1JUJZ25SP1' cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding:0' type='eu.siacs.conversations.axolotl'>
            <encrypted xmlns='eu.siacs.conversations.axolotl'>
              <header sid='646419288'>
                <key rid='176863614'>
                  MwohBaUE/m6PP1GhNcX0PLjWFtoLV8vTZuy3svy1ZMTYn6EXEAQYASIw4TTNyZMMiJ4xKHRYAXqXDCxYE4B1B487uYTBhvJw0ypkPeRCyXevYuRvaW8GYcRBtekKA45KzFI=
                </key>
                <iv>
                  3vnNUQKiHFRUa/tE
                </iv>
              </header>
              <payload>
                DKazPr5A8Bx+DO36llo8dkL2J0fxppfdtVFBYsFR5LUbbgVwW38ULdmp5FWjOpAzZ2wugAAg3DuYXF7n
              </payload>
            </encrypted>
          </security>
        </content>
      </jingle>
    </iq>
licaon-kter commented 1 year ago

The is no change in sources/features between 3.0.2 and 3.0.3

There's something different, .2 complains it can't access file if Storage is not granted, but .3 does not.

a. Are the testing between 2 aTalk clients?

No, sending from aTalk to Conversations

b. Is the problem reproducible

Yes, step 1. Attach file, see error

Can you also provide me the actual "session-initiate" content being sent, I need to figure what element is failing QName

This is from the in-app debug info or where from exactly? I don't want to run the server in debug mode :(

cmeng-git commented 1 year ago

Please note that aTalk may fail unexpectedly if the storage permission is not granted. Currently aTalk design does not provide check at every file access for the permission. There is no different between 2 and 3 in this aspect. The observed error can occurred if aTalk needs to make a copy of the user selected file via document picker (direct access to aTalk is denied) and the storage permission is not given.

Storage needed for 3.0.2 but not 3.0.3, attach via document picker. There's something different, .2 complains it can't access file if Storage is not granted, but .3 does not.

aTalk implement Jet protocol as per below, which is not supported by Conversation: XEP-0391: Jingle Encrypted Transports 0.1.2 (2018-07-31)

If you need to send omemo encrypted file to Conversations, your server must support HttpFileUpload protocol; which aTalk will attempt to use if found the recipient cannot support Jet Security (see png attached).

XEP-0363 is available but not used.

JetSecurity

Your previous logcat indicated a QName access failure, resulted from an Element inclusion in the session-initiate. I am unable to produce your observed problem, hence cannot ascertain what Element is causing the problem. Cannot see the attached file. You need to provide me detailed steps on how to reproduce the problem if requested info cannot be provided.

Yes, step 1. Attach file, see error

licaon-kter commented 1 year ago

As with any other issue that I report I always feel that we are lost in translation. :confused:

/end rant

The observed error can occurred if aTalk needs to make a copy of the user selected file via document picker (direct access to aTalk is denied) and the storage permission is not given.

I've specifically mentioned "storage permission" status so I don't get lectured about it. It makes no difference.

your server must support HttpFileUpload protocol; which aTalk will attempt to use if found the recipient cannot support Jet Security (see png attached).

I've specifically mentioned "XEP-0363 is available" to get this issue forward further instead of being repeated what the app would do but it did not.

Cannot see the attached file.

I did not attach any picture, I've just written the steps to repro, as I can repro this just by attaching a file in aTalk.

Will attach pics next.

cmeng-git commented 1 year ago

I appreciate in future, it would be better for you to state the steps and observation clearer in the initial bug report instead of a shorten description to avoid any misunderstanding. It is not my intention for me to lecture anyone, it is a waste of my time and yours. All my previous comments are trying to answer to your comments/questions which I might have mis-interpreted.

There's something different, .2 complains it can't access file if Storage is not granted, but .3 does not.

You mentioned that there is a difference in 3.0.2 and 3.0.3 behavior when storage permission is not granted; I am trying to explain to you there is no difference in sources in this area. The difference you observed can be due to picked document location. Also from the reported logcat, the problem is unlikely due to storage permission not granted; and I am not sure why you want to disable the storage permission for the test.

XEP-0363 is available but not used. My understand from this statement is that your server supports it, but it was disabled for the test. If it means otherwise, you need to make this statement clearer.

I did not attach any picture, I've just written the steps to repro, as I can repro this just by attaching a file in aTalk. I tried to reproduce by just attaching a file in aTalk and sending to conversation, but I did not encounter the problem as you had mentioned. My previous attached png reflects exactly as what aTalk has implemented.

licaon-kter commented 1 year ago

XEP-0363 is available but not used.

It means that my server has it but aTalk does not try to contact the server to upload the file.

3.0.2/.3, Storage permission granted (but same behaviour with or without)

Attach picture, document picker appears, choose one from the first view, the so called "Recents" screen:

two (do note that not all "recent" files trigger this, from the same folder one might, while another might not; by folder I mean Downloads not random folders; this error does not crash)

Anyway, main issue: attach picture, document picker appears, choose Gallery (Simple Gallery Pro to be precise), choose picture:

one

...and then it crashes....

The chat view might freeze or might continue to work, stack trace in OP was captured with the app Scoop.

The observed error can occurred if aTalk needs to make a copy of the user selected file via document picker (direct access to aTalk is denied) and the storage permission is not given.

I see that sometimes pictures (resized?) are created in Downloads/aTalk/tmp so that part appears to work.

your server must support HttpFileUpload protocol; which aTalk will attempt to use if found the recipient cannot support Jet Security

After how long will aTalk give up on JET and try use http_upload?

cmeng-git commented 1 year ago

Thanks for spending time to provide a more detailed description of the problem. Followings are my comments based on your recent update.

The first file send instant indicates that the returned file path pointed to an non-existence file in the storage i.e. "File MUST NOT be null and MUST exist"

In the second file send instant, it looks like MyGlideApp.loadImage() is able to retrieve the content based on the returned file path, since the thumbnail is displayed properly. aTalk seems also to be able to get the absolute path info i.e. displaying of the file send UI . However aTalk crashes upon further process of the file content in (suspected) JingleFile element which is used in

JetManager.sendEncryptedFile(file, jingleFile, recipient, omemoManager);

I found that both the send instants actually referred to the same file name. The Recent document UI seems also has the problem of getting a valid file path. I am not sure what is the returned path exact info content from SImpleGalleryPro which causes aTalk to crash on further process. Currently I am unable proceed further to investigate this problem, as I cannot produce this error condition on my side; however will continue to monitor for this error. Meantime I have enclose some of the suspected statements in try/catch loop to avoid aTalk crashes.

What is OP and app Scoop in the below statement. Was the first stack trace captured using this approach when the problem happen.

The chat view might freeze or might continue to work, stack trace in OP was captured with the app Scoop.

By the way, how is conversation, running on the same device, behaves when sending the same file.

I see that sometimes pictures (resized?) are created in Downloads/aTalk/tmp so that part appears to work.

Yes, aTalk will make a local copy in Downloads/aTalk/tmp when the given file content:// cannot be accessed directly. aTalk just copy the content pointed to by the given content:// path without any content changes.

After how long will aTalk give up on JET and try use http_upload?

aTalk will attempt to use JET if the client advertises its support. Conversations advertises the JET support but without full implementation. aTalk will immediate throw JET security error when the client replied "session-accept" does not contain the JET info as per request in aTalk "session-initiate". After the JET security error, aTalk "Retry" option will be offered to user, but fallback to use HTTPFileUpload utility. aTalk continues to use HTTPFileUpload protocol for the next 10 file send attempts to the failed client. After this aTalk reverts to use JET file sending protocol.

2022-11-11 11:03:47.701 15735-16148/org.atalk.android D/SMACK: SENT (0): 
    <iq to='parrot@atalk.sytes.net/Conversations.lxYf' id='VDWE7-16' type='set'>
      <jingle xmlns='urn:xmpp:jingle:1' initiator='swordfish@atalk.sytes.net/atalk' action='session-initiate' sid='UAETIW62V4ZYZFRSKRZJMM2P'>
        <content name='cont-WWV5UI8G76WHUPAT' creator='initiator' senders='initiator'>
          <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
            <file>
              <date>
                2022-11-11T00:51:03.000+00:00
              </date>
              <media-type>
                image/jpeg
              </media-type>
              <name>
                IMG-20221107-WA0003.jpg
              </name>
              <size>
                77936
              </size>
              <hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>
                RaVQ+DWjQ464BEgs6j1LbTktP2r2c+tXAxhla3h/JnQ=
              </hash>
            </file>
          </description>
          <transport xmlns='urn:xmpp:jingle:transports:s5b:1' dstaddr='0a6391963f0581c17cf6ec75f42d8872c3c7236d' mode='tcp' sid='7GW7NLZ3AB3GIUGRLNQGTKYH'>
            <candidate cid='HFKCZHYLCQS5MPW4' host='10.175.62.187' jid='swordfish@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='N5AIWKZDE9SQ4E7H' host='fe80::1004:3eff:fe07:ba63%wlan0' jid='swordfish@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='5DW86STCHXF4VYSW' host='192.168.1.167' jid='swordfish@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='JDTRIG326B173M3S' host='42.60.99.4' jid='proxy.atalk.sytes.net/55238004' port='7777' priority='0' type='proxy'/>
          </transport>
          <security xmlns='urn:xmpp:jingle:jet:0' name='cont-WWV5UI8G76WHUPAT' cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding:0' type='eu.siacs.conversations.axolotl'>
            <encrypted xmlns='eu.siacs.conversations.axolotl'>
              <header sid='646419288'>
                <key prekey='true' rid='1952378827'>
                  MwgaEiEFGHWBTe0/unx7UiYyhrTMe/zpK9R/ZkfeSY+OyEWLD1IaIQV/iXNtFvWTc9FCFRZWKDFf9sFUvLBXNpJreYZymc6RNyJiMwohBTqmc/z6AV62ESOHrjKRGqGIwzzlB3W1C5OR0BF6JRxvEHEYACIw4dXge2NhdwdeVEaadMIH+22Yozql4aMzBwsPljQ7zJPIU5J2ddAvuU+18CIBC/JhhBoVwoYqsiEoADAB
                </key>
                <key rid='522622186'>
                  MwohBZO/siYPqubkPHpyYkVBZ73xrr19nhl6SY4Cc6SjWThCEAQYACIwSz8HXL/gtlaf+qwLI/t6IcbHZppMlPLAgRaSg3fy4qm/fNerF2yUfxWEQZjT9PcRR/fqyEPAiPY=
                </key>
                <iv>
                  0Pzg/q17NOLVjyl5
                </iv>
              </header>
              <payload>
                wzGbA3ygVCuKOeYQukU4V9T3JZ3IeSSkaqYVYN+nYvk2ABjOgOYZzzOsoXNFiRpnov6avxW4MRcShM68
              </payload>
            </encrypted>
          </security>
        </content>
      </jingle>
    </iq>
2022-11-11 11:03:48.380 15735-16149/org.atalk.android D/SMACK: RECV (0): 
    <iq xml:lang='en' to='swordfish@atalk.sytes.net/atalk' from='parrot@atalk.sytes.net/Conversations.lxYf' type='result' id='VDWE7-16'/>

2022-11-11 11:03:48.396 15735-16149/org.atalk.android D/SMACK: RECV (0): 
    <iq xml:lang='en' to='swordfish@atalk.sytes.net/atalk' from='parrot@atalk.sytes.net/Conversations.lxYf' type='set' id='UsezAtoPZ87q'>
      <jingle xmlns='urn:xmpp:jingle:1' sid='UAETIW62V4ZYZFRSKRZJMM2P' action='session-accept'>
        <content name='cont-WWV5UI8G76WHUPAT' creator='initiator' senders='initiator'>
          <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
            <file>
              <date>
                2022-11-11T00:51:03.000+00:00
              </date>
              <media-type>
                image/jpeg
              </media-type>
              <name>
                IMG-20221107-WA0003.jpg
              </name>
              <size>
                77936
              </size>
              <hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>
                RaVQ+DWjQ464BEgs6j1LbTktP2r2c+tXAxhla3h/JnQ=
              </hash>
            </file>
          </description>
          <transport xmlns='urn:xmpp:jingle:transports:s5b:1' sid='7GW7NLZ3AB3GIUGRLNQGTKYH'>
            <candidate port='46925' priority='8257536' jid='parrot@atalk.sytes.net/Conversations.lxYf' type='direct' host='192.168.1.37' cid='1f859e5c-d3f3-4c63-91b2-0120c12fcb65'/>
          </transport>
        </content>
      </jingle>
    </iq>

2022-11-11 11:03:48.452 15735-16168/org.atalk.android D/(JingleFileTransferImpl.java:182)#onSessionTerminated: mState set to: pending, =org.jivesoftware.smackx.jingle.element.JingleReason@6746268

2022-11-11 11:03:48.490 15735-16148/org.atalk.android D/SMACK: SENT (0): 
    <iq to='parrot@atalk.sytes.net/Conversations.lxYf' id='VDWE7-17' type='set'>
      <jingle xmlns='urn:xmpp:jingle:1' action='session-terminate' sid='UAETIW62V4ZYZFRSKRZJMM2P'>
        <reason>
          <security-error/>
          <text>
            JetSecurity protocol not supported by client
          </text>
        </reason>
      </jingle>
    </iq>
licaon-kter commented 1 year ago

OP is short for "opening post" meaning first post of the issue.

Scoop is https://github.com/TacoTheDank/Scoop

Regarding JET, if aTalk has not crashed completely I sometimes can press Cancel, then Conversations shows File transfer has been canceled. Although it has never shown the transfer starting.

By the way, how is conversation, running on the same device, behaves when sending the same file.

No issues.

I am not sure what is the returned path exact info content from SImpleGalleryPro which causes aTalk to crash on further process.

It's not specific to SimpleGalleryPro either. I can use the "Images" selector in document picker (this is an AOSP11 based ROM fyi) or choose a file manager and then choose a picture, same behaviour.

Meantime I have enclose some of the suspected statements in try/catch loop to avoid aTalk crashes.

Great, non working features are ok, app crashes are not 👍

cmeng-git commented 1 year ago

One further clarification: a. Does aTalk also crashes when you send other image file (not the same as above)?

b. If you send the same image file without using omemo encryption, does the file send successfully or aTalk still crashes.

c. If send successfully, are you able to tell if aTalk uses JingleFile transfer protocol or via HTTPFileUpload?

licaon-kter commented 1 year ago

a. Does aTalk also crashes when you send other image file (not the same as above)?

Any file type, from any app

b. If you send the same image file without using omemo encryption, does the file send successfully or aTalk still crashes.

Interesting question.. the answer might be (as I said in the OP anyway) that it does not matter, crashes anyway.

But, there's an interesting bug/glitch when I test this.

So I disable OMEMO in the upper right icon.

Attach... it crashes... but look at the picture... the fish should not be there, right?

69TzHQRRSs23w5lBZAxu8g

If I open the keyboard the fish disappears

FktS3PAzQ_WzHCQ2sozaJA

cmeng-git commented 1 year ago

From your latest update, it seems that the sending file via JingleFileTransfer protocol s not working at all on your device; and the crashes has nothing to do with JET encryption.

From aTalk source for both encrypted and plain, the JingleFile object creation is the common process; possible the root cause of the problem.

JingleFile.fromFile(file, null, mimeType, HashManager.ALGORITHM.SHA3_256);

I am not sure if the problem arises is due to HashManager.ALGORITHM.SHA3_256 used in calculate the hash for the sending file. The hash element is part of the JingleFile properties, and JingleFile element is part of the \. From your OP, the crash is due to embedding the \ in the "session-initiate"

              <hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>
                f9EsKHigJ7YxAllI32rAyYCPczLyZHOloKU+ZX5KV/Q=
              </hash>

a. Are you able to send file via HTTPFileUpload (use when recipient is off line) successfully? Would like to verify the problem is no due file fetching.

b. Are you able to receive file sent from conversations using JingleFileTransfer protocol?

c. Can you install aTalk on another device (or AVD) which run android OS to verify JingleFileTransfer is actually working on other android models.

The "encryption" icon is the default icon being shown when the send file UI is first displayed; and this icon get updated when the file sending is working normally. When you open the keyboard, the UI will get redraw by android in UI thread. The problem you observed is likely that the encryption state get updated, but has no chance to change the icon image in UI thread due to crashes in aTalk underlying routine.

licaon-kter commented 1 year ago

a. Are you able to send file via HTTPFileUpload (use when recipient is off line) successfully?

Yes, if contact is offline files are sent ok via http_upload

b. Are you able to receive file sent from conversations using JingleFileTransfer protocol?

Nope

c. Can you install aTalk on another device (or AVD) which run android OS to verify JingleFileTransfer is actually working on other android models.

I now have one device with Android 11 (the one that the initial crashes were captured) and one with Android 9. Each has an account that's not used on other clients.

They both crash, Storage granted or not, OMEMO used or not.

Android 9 stack trace has slightly different line numbers:

java.lang.RuntimeException: An error occurred while executing doInBackground()
    at android.os.AsyncTask$3.done(AsyncTask.java:354)
    at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383)
    at java.util.concurrent.FutureTask.setException(FutureTask.java:252)
    at java.util.concurrent.FutureTask.run(FutureTask.java:271)
    at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
    at java.lang.Thread.run(Thread.java:764)
Caused by: java.lang.AbstractMethodError: abstract method "javax.xml.namespace.QName org.jivesoftware.smack.packet.FullyQualifiedElement.getQName()"
    at org.jivesoftware.smackx.jingle_rtp.AbstractXmlElement$Builder.addChildElements(AbstractXmlElement.java:453)
    at org.jivesoftware.smackx.jingle.element.JingleContentDescription$Builder.addPayload(JingleContentDescription.java:96)
    at org.jivesoftware.smackx.jingle.element.JingleContentDescription.<init>(JingleContentDescription.java:63)
    at org.jivesoftware.smackx.jingle_filetransfer.element.JingleFileTransfer.<init>(JingleFileTransfer.java:31)
    at org.jivesoftware.smackx.jingle_filetransfer.component.JingleFileTransferImpl.getElement(JingleFileTransferImpl.java:153)
    at org.jivesoftware.smackx.jingle_filetransfer.component.JingleFileTransferImpl.getElement(JingleFileTransferImpl.java:45)
    at org.jivesoftware.smackx.jingle.component.JingleContentImpl.getElement(JingleContentImpl.java:342)
    at org.jivesoftware.smackx.jingle.component.JingleSessionImpl.createSessionInitiate(JingleSessionImpl.java:163)
    at org.jivesoftware.smackx.jingle.component.JingleSessionImpl.sendInitiate(JingleSessionImpl.java:128)
    at org.jivesoftware.smackx.jingle_filetransfer.JingleFileTransferManager.sendFile(JingleFileTransferManager.java:143)
    at org.atalk.android.gui.chat.MetaContactChatTransport.jingleFileSend(MetaContactChatTransport.java:763)
    at org.atalk.android.gui.chat.MetaContactChatTransport.sendFile(MetaContactChatTransport.java:699)
    at org.atalk.android.gui.chat.MetaContactChatTransport.sendFile(MetaContactChatTransport.java:658)
    at org.atalk.android.gui.chat.ChatFragment$SendFile.doInBackground(ChatFragment.java:2585)
    at org.atalk.android.gui.chat.ChatFragment$SendFile.doInBackground(ChatFragment.java:2529)
    at android.os.AsyncTask$2.call(AsyncTask.java:333)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    ... 4 more

/LE:

Currently I am unable proceed further to investigate this problem, as I cannot produce this error condition on my side; however will continue to monitor for this error.

Just to check, you are testing with the version from F-Droid, yes?

cmeng-git commented 1 year ago

Sorry, forget to mention that item b should send as unencrypted mode as conversations does not support Jet. What is the error shown on aTalk on failure?

licaon-kter commented 1 year ago

While http_upload is limited (to force Jingle):

cmeng-git commented 1 year ago

Try the following to use JingleFileTransfer between aTalk and Conversations in non encrypted/omemo mode: Conversations installed version is 2.10.10+free; and my test server is ejabberd 20.12

a. Talk is able to send attachment to Conversation using JingleFileTransfer protocol, and file send is sucessful. b. Conversation always use HttpFileUpload protocol when sending attachment to aTalk. File received successfully; but not sure why Conversations is not using JingleFileTransfer protocol.

  1. Did you set any option in Conversations to make this happen?
2022-11-15 09:31:28.454 10138-10272/org.atalk.android D/SMACK: RECV (0): 
    <message xml:lang='en' to='leopard@atalk.sytes.net' from='xyz123@atalk.sytes.net/Conversations.WV9Y' type='chat' id='ad38e1a6-8663-42d3-b3c4-57639daa94d8'>
      <archived by='leopard@atalk.sytes.net' id='1668475885688727' xmlns='urn:xmpp:mam:tmp'/>
      <stanza-id by='leopard@atalk.sytes.net' id='1668475885688727' xmlns='urn:xmpp:sid:0'/>
      <request xmlns='urn:xmpp:receipts'/>
      <markable xmlns='urn:xmpp:chat-markers:0'/>
      <origin-id xmlns='urn:xmpp:sid:0' id='ad38e1a6-8663-42d3-b3c4-57639daa94d8'/>
      <x xmlns='jabber:x:oob'>
        <url>
          https://atalk.sytes.net:5443/upload/atalk.sytes.net/160ce91b31fe9fc0d13bad06ed50e0aacccbc854/Ux5kR9Ijxz4Rgfx3rSTY9MD2CnQYuihVnal7m218/IMG-20221107-WA0003.jpg
        </url>
      </x>
      <body>
        https://atalk.sytes.net:5443/upload/atalk.sytes.net/160ce91b31fe9fc0d13bad06ed50e0aacccbc854/Ux5kR9Ijxz4Rgfx3rSTY9MD2CnQYuihVnal7m218/IMG-20221107-WA0003.jpg
      </body>
    </message>

Sending from Conversations with OMEMO, nothing happens in aTalk, no error but no file or anything shown.

Conversations should proceed to use HttpFileUpload protocol to encrypted file transfer; unless your server does not support HttpFileUpload protocol.

Sending without OMEMO..

Your last ogcat shows that your Conversations client is able to use JingleFileTransfer protocol; however it crashes due to

at org.jivesoftware.smackx.jingle.element.JingleContentDescription$Builder.addPayload(JingleContentDescription.java:96)

when smack is adding the received JingleContentDescription payload during parse process. I really need to know what is the exact stanza content that was send from Conversations, to understand the root cause.

  1. Are you able to capture the info similar to the following to share with me:
2022-11-15 09:40:53.068 10138-10272/org.atalk.android D/SMACK: RECV (0): 
    <iq xml:lang='en' to='leopard@atalk.sytes.net/atalk' from='xyz123@atalk.sytes.net/Conversations.WV9Y' type='set' id='3-eLNIl8M6Ga'>
      <jingle xmlns='urn:xmpp:jingle:1' sid='ELDL19UEYYR7GLIRR8V5SB5Z' action='session-accept'>
        <content name='cont-DQUR3VLCAPNTNHIK' creator='initiator' senders='initiator'>
          <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
            <file>
              <date>
                2022-11-15T01:40:28.000+00:00
              </date>
              <media-type>
                image/jpeg
              </media-type>
              <name>
                3roVLNyiRZSSfIQGDnFj_g.jpg
              </name>
              <size>
                106048
              </size>
              <hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>
                myvsgCkj0KYyjYmtbXJ0TU+fh0+wJh9cMiLFe7x7N54=
              </hash>
            </file>
          </description>
          <transport xmlns='urn:xmpp:jingle:transports:s5b:1' sid='QHPGFBHCGXMANI4K94CU6QUV'>
            <candidate port='4905' priority='8257536' jid='xyz123@atalk.sytes.net/Conversations.WV9Y' type='direct' host='192.168.1.167' cid='997f620d-7fec-406a-922c-1e45d1458d6d'/>
            <candidate port='24773' priority='8257537' jid='xyz123@atalk.sytes.net/Conversations.WV9Y' type='direct' host='10.230.117.73' cid='1436a522-3ffc-4203-8b4d-b0c8b1a18935'/>
          </transport>
        </content>
      </jingle>
    </iq>

  1. Alternatively, can your try to send an attachment to my test client on my server i.e. swordish@atalk.sytes.net

  2. or provide me with a test account on your server, and then send the attachment via this test account.

licaon-kter commented 1 year ago

Did you set any option in Conversations to make this happen?

No, _"While httpupload is size limited server side (to force Jingle in Conversations)"

Eg. set limit to 2Mb serverside, then try to send a 3Mb file.

Conversations should proceed to use HttpFileUpload protocol to encrypted file transfer; unless your server does not support HttpFileUpload protocol.

I was not testing http_upload but Jingle, read above how to force Conversations.

Are you able to capture the info similar to the following to share with me

Conversations does not log that verbose.

cmeng-git commented 1 year ago

Please refer to XEP-0166: Jingle on : Table 1: Attributes of Jingle Element The "initiator" is : RECOMMENDED for session-initiate, NOT RECOMMENDED otherwise

However from the captured session-initiate sent from Conversations (see logcat below); Conversations has decided not to include this "initiator" in:

\

However in smack v4.4.6, the JingleSession class implementation, it expects the initiator parameter to be not null,

public JingleSession(FullJid initiator, FullJid responder, Role role, String sid)

Hence in FullJidAndSessionId.java#hashCode() method, the fullJid is null, and this causes aTalk to crash. 

    @Override
    public int hashCode() {
        int hashCode = 31 * fullJid.hashCode();
        hashCode = 31 * hashCode + sessionId.hashCode();
        return hashCode;
    }
    --------- beginning of crash
2022-11-16 09:57:02.816 21360-28531/org.atalk.android E/AndroidRuntime: FATAL EXCEPTION: Smack Cached Executor
    Process: org.atalk.android, PID: 21360
    java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
        at org.jivesoftware.smackx.jingle.FullJidAndSessionId.hashCode(FullJidAndSessionId.java:43)
        at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1020)
        at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1014)
        at org.jivesoftware.smackx.jingle.JingleManager.registerJingleSessionHandler(JingleManager.java:123)
        at org.jivesoftware.smackx.jingle.component.JingleSessionImpl.<init>(JingleSessionImpl.java:119)
        at org.jivesoftware.smackx.jingle.component.JingleSessionImpl.<init>(JingleSessionImpl.java:94)
        at org.jivesoftware.smackx.jingle_filetransfer.JingleFileTransferManager.handleJingleRequest(JingleFileTransferManager.java:113)
        at org.jivesoftware.smackx.jingle.JingleManager$1.handleIQRequest(JingleManager.java:103)
        at org.jivesoftware.smack.AbstractXMPPConnection$3.run(AbstractXMPPConnection.java:1561)
        at org.jivesoftware.smack.AbstractXMPPConnection$10.run(AbstractXMPPConnection.java:2146)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:920)
======= Jingle session-initiate from Conversations ========
2022-11-16 09:49:10.553 21360-27758/org.atalk.android D/SMACK: RECV (0): 
    <iq xml:lang='en' to='swordfish@atalk.sytes.net/atalk' from='parrot@atalk.sytes.net/Conversations.lxYf' type='set' id='6zDi3z-9mx54'>
      <jingle xmlns='urn:xmpp:jingle:1' sid='Dj4AyNIx6IXpEiEG6l+8HA' action='session-initiate'>
        <content name='CGV235kZ7LwAnTX+TQ2hJQ' creator='initiator' senders='initiator'>
          <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
            <file>
              <size>
                98117
              </size>
              <name>
                c59fe592-d472-489d-bf70-9f7043a827ba.jpg
              </name>
            </file>
          </description>
          <transport xmlns='urn:xmpp:jingle:transports:ibb:1' sid='6irzyqPefCsrhrJh5EXbcA' block-size='8192'/>
        </content>
      </jingle>
    </iq>

======= Jingle session-initiate from aTalk ========
2022-11-16 09:52:10.702 21360-27758/org.atalk.android D/SMACK: RECV (0): 
    <iq xml:lang='en' to='swordfish@atalk.sytes.net/atalk' from='leopard@atalk.sytes.net/atalk' type='set' id='3L7QD-21'>
      <jingle xmlns='urn:xmpp:jingle:1' initiator='leopard@atalk.sytes.net/atalk' action='session-initiate' sid='NYTFNKAMRFFSSSLDMS92EWD6'>
        <content name='cont-GLJ7AD2IRTYB87ZE' creator='initiator' senders='initiator'>
          <description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
            <file>
              <date>
                2022-11-15T01:40:28.000+00:00
              </date>
              <media-type>
                image/jpeg
              </media-type>
              <name>
                3roVLNyiRZSSfIQGDnFj_g.jpg
              </name>
              <size>
                106048
              </size>
              <hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>
                myvsgCkj0KYyjYmtbXJ0TU+fh0+wJh9cMiLFe7x7N54=
              </hash>
            </file>
          </description>
          <transport xmlns='urn:xmpp:jingle:transports:s5b:1' dstaddr='2dad010be69ad15681e64b6823b14fdf68eb2d48' mode='tcp' sid='SL3QGNKPWHUCSB6L2GI1D6IU'>
            <candidate cid='6KXGDL6P92RG6CNJ' host='fe80::362d:dff:fe00:ae96%wlan0' jid='leopard@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='JI71ULSQCU471WST' host='fe80::342d:dff:fe00:ae96%p2p0' jid='leopard@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='FFBMNRR7XKHVBDKN' host='192.168.1.37' jid='leopard@atalk.sytes.net/atalk' port='7777' priority='100' type='proxy'/>
            <candidate cid='2YG68H9WWDM2WHDS' host='42.60.99.4' jid='proxy.atalk.sytes.net/55238004' port='7777' priority='0' type='proxy'/>
          </transport>
        </content>
      </jingle>
    </iq>
cmeng-git commented 1 year ago

I have fixed the problem with modifications to the smack classes to take care of the missing initiator in session-initiate stanza. The fixes will be in the next aTalk official release.

I can prepare a temporary debug version for your testing if you want. Please send me an email if you wish to have the debug version for testing.

licaon-kter commented 1 year ago

You have me in your swordfish roster ;)

cmeng-git commented 1 year ago

Have just released v3.0.4, should fixed all the observed problem in JingleFileTransfer. There is a fdroid-debug version in aTalk release directory, or wait for the official release for your testing.

Please refer to: XEP-0065: SOCKS5 Bytestreams, and take note of the following findings for JingleFileTransfer:

a. The atalkuser accounts test server supports proxy for local host only, so clients behind NAT will fallback to use IBB protocol.

b. Conversations v2.10.10 does not offer transport-candidate for type proxy, so it too will fallback to use IBB if one the Conversations client is behind firewall.

c. aTalk supports proxy transport-client, it should work with Conversations behind firewall.