omemo encryption not available (option is greyed out)

Hello, I am trying to set up an encrypted chat, but I cannot chose omemo. My server works (prosody). I can use omemo encryption with both conversations and gajim. I tried to send unencrypted messages with atalk first (this sometimes help with establishing an omemo enabled chat), but atalk won't let me disable otr (on one device at a time). I disabled all otr options in the settings. Still I always get a 'message send failed' from one device. (Both devices are moto g falcon (2013) running lineageos (android 7).

I also tested zrtp calls -- they work when both devices are on the same wifi, but a connection cannot be established when one device uses the mobile network.

Please forward me the debug log to take a look on omemo problem. Refer to online help i.e. https://atalk.sytes.net on how to send the debug log.

I also tested zrtp calls -- they work when both devices are on the same wifi, but a connection cannot be established when one device uses the mobile network.

You are likely behind an advance (corporate?) firewall that does not allow NAT connection. Or the firewall has blocked the UDP traffic. You need to setup an STUN/TURN server in order to overcome the firewall restrictions.

Thanks for the quick reply. I attached the log-file. I connect everything on my network via wireguard (mullvad) vpn. The vpn client runs on my router (openwrt). I do not want to allow Upnp, maybe a single port would be enough? I already tried to set up a stun-server on my vps, but did not manage to get it working. Maybe I will give it another try. But I am not sure that is the only problem: we also did not manage to connect the two devices make an atalk call when both where using the mobile network.

I am trying to set up an encrypted chat, but I cannot chose omemo.

From the debug log, I found that your network connection is very unstable. Immediately after the Omemo Manger has initialized, the network get disconnected; and this happened for 12 consecutive attempts. This is the likely reason why the Omemo chat is grayed out since the setting up of Omemo has not completed successfully.

2019-02-17 01:03:01.795 INFO: [838] org.atalk.crypto.omemo.AndroidOmemoService.initializationFinished().120 Initialize OmemoManager successful for tester@xmpp.example.com/atalk
2019-02-17 01:03:35.085 WARNING: [837] org.jivesoftware.smack.AbstractXMPPConnection.callConnectionClosedOnErrorListener() Connection XMPPTCPConnection[tester@xmpp.example.com/atalk] (0) closed with error
javax.net.ssl.SSLException: Read error: ssl=0xa97f6280: I/O error during system call, Software caused connection abort
    at com.android.org.conscrypt.NativeCrypto.SSL_read(Native Method)
    at com.android.org.conscrypt.OpenSSLSocketImpl$SSLInputStream.read(OpenSSLSocketImpl.java:758)
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:287)
    at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:350)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:179)
    at java.io.InputStreamReader.read(InputStreamReader.java:184)
    at java.io.BufferedReader.read1(BufferedReader.java:221)
    at java.io.BufferedReader.read(BufferedReader.java:297)
    at org.jivesoftware.smack.util.ObservableReader.read(ObservableReader.java:42)
    at org.kxml2.io.KXmlParser.fillBuffer(KXmlParser.java:1535)
    at org.kxml2.io.KXmlParser.peekType(KXmlParser.java:1007)
    at org.kxml2.io.KXmlParser.next(KXmlParser.java:357)
    at org.kxml2.io.KXmlParser.next(KXmlParser.java:321)
    at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1246)
    at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:998)
    at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1014)
    at java.lang.Thread.run(Thread.java:761)

I connect everything on my network via wireguard (mullvad) vpn

aTalk has not been tested running behind NAT via VPN. Not sure what VPN will do to the peer to peer connections setup; also if ICE uses in aTalk will respect your VPN connection as it is pending on external STUN reported public IP for the connected devices. Sorry I am unable to offer any help on this type of setup since I am not familiar in this area.

We also did not manage to connect the two devices make an atalk call when both where using the mobile network.

I need you to perform the call setup again, and send me the debug log. By the way, you may want to send the log to my email directly.

Thanks for sharing your test results. I have re-tested two devices between wifi and mobile networks. The video call setup has no problem.

I see the exact same error message as you If I setup a non-working STUN/TURN in account ICE settings. i.e. "Error: Could not establish connection (ICE failed and no relay found)",

Can you try to remove the accout ICE STUN/TURN settings and see if the video call setup is OK; if your current setup is not restricted by Symmetric NAT's?

Do you know of any working STUN/TURN server that are reliable and free that I can test with?

Thanks for providing the test STUN/TURN server: Actually my earlier test was carried out with two devices between wifi and mobile network, but no ICE STUN/TURN is specified or used. It was working without any problem;

For the last two days, I was testing with the STUN/TURN server provided. Yesterday testing always failed with "Error: Could not establish connection (ICE failed and no relay found)"

Following is a log of the media call setups and my observation in today testing

ice4j is able to use the TURN relay and was offered to the calling party as possible transport candidates.
In the first case, when the calling party is trying to validate the relay connectivity, all the relay candidates failed due to timeout.
In the second case, the calling party is able to validate the relay connectivity, the relay candidates connectivity are validated OK but failed again at later stage.
Before the actual media data sending, the relay connectivity failed, again due to timeout. The candidates are discarded for use by ice4j.

Conclusion: It seems that the STUN/TURN server must have good response time, otherwise ice4j will discard the offered transport candidates due to timeout.

Note: Even though the TURN relays failed in the test, there is no problem with the video call setup using other offered transport candidates in all the tests today. Actually I did once successfully set up the call using the TURN relay, but I did not capture the log, and unable to produce the good result again due to failing timeout.

Video works fine, although video graphics quality is low (Maybe it need manually up bit rates?).

aTalk will attempt to use the user specified resolution settings; however it will drop/adjust the video quality (bit rate) according to the received data error bitrate.

============= TURN relay failed due to timeout ==================

03-06 11:34:02.909 16483-22371/org.atalk.android I/aTalk: [260] org.ice4j.ice.Component.log() Add remote candidate for audio.RTP: 223.111.157.35:61245/udp/relay
03-06 11:34:02.909 16483-22371/org.atalk.android I/aTalk: [260] org.ice4j.ice.Component.log() Add remote candidate for audio.RTCP: 223.111.157.35:49197/udp/relay
03-06 11:34:02.939 16483-22371/org.atalk.android I/aTalk: [260] org.ice4j.ice.Component.log() Add remote candidate for video.RTP: 223.111.157.35:58006/udp/relay
03-06 11:34:02.939 16483-22371/org.atalk.android I/aTalk: [260] org.ice4j.ice.Component.log() Add remote candidate for video.RTCP: 223.111.157.35:53330/udp/relay

03-06 11:34:04.269 16483-22462/org.atalk.android I/aTalk: [271] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 192.168.1.30:5020/udp/host -> 223.111.157.35:61245/udp/relay (audio.RTP), failing.
03-06 11:34:04.469 16483-22472/org.atalk.android I/aTalk: [276] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 192.168.1.30:5021/udp/host -> 223.111.157.35:49197/udp/relay (audio.RTCP), failing.
03-06 11:34:04.649 16483-22478/org.atalk.android I/aTalk: [281] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 192.168.1.30:5022/udp/host -> 223.111.157.35:58006/udp/relay (video.RTP), failing.
03-06 11:34:04.829 16483-22483/org.atalk.android I/aTalk: [286] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 192.168.1.30:5023/udp/host -> 223.111.157.35:53330/udp/relay (video.RTCP), failing.

============= TURN relay intermittent pass and failed ==================

2019-03-06 11:42:15.131 1531-8372/org.atalk.android I/aTalk: [1657] org.ice4j.ice.ConnectivityCheckClient.log() Pair succeeded: 10.128.95.167:5028/udp/host -> 223.111.157.35:64622/udp/relay (audio.RTP). Local ufrag 91rg1d58hg33u
2019-03-06 11:42:15.131 1531-8372/org.atalk.android I/aTalk: [1657] org.ice4j.socket.MergingDatagramSocket.log() Adding allowed address: 223.111.157.35:64622/udp
2019-03-06 11:42:15.132 1531-8372/org.atalk.android I/aTalk: [1657] org.ice4j.ice.ConnectivityCheckClient.log() Pair validated: 119.56.97.171:5028/udp/srflx -> 223.111.157.35:64622/udp/relay (audio.RTP). Local ufrag 91rg1d58hg33u
2019-03-06 11:42:15.601 1531-8374/org.atalk.android I/aTalk: [1659] org.ice4j.socket.MergingDatagramSocket.log() Adding allowed address: 223.111.157.35:50380/udp
2019-03-06 11:42:15.698 1531-8374/org.atalk.android I/aTalk: [1659] org.ice4j.socket.MergingDatagramSocket.log() Adding allowed address: 223.111.157.35:61349/udp
2019-03-06 11:42:15.971 1531-8373/org.atalk.android I/aTalk: [1658] org.ice4j.ice.ConnectivityCheckClient.log() Pair succeeded: 10.128.95.167:5031/udp/host -> 223.111.157.35:65366/udp/relay (video.RTCP). Local ufrag 91rg1d58hg33u
2019-03-06 11:42:15.974 1531-8373/org.atalk.android I/aTalk: [1658] org.ice4j.socket.MergingDatagramSocket.log() Adding allowed address: 223.111.157.35:65366/udp
2019-03-06 11:42:15.977 1531-8373/org.atalk.android I/aTalk: [1658] org.ice4j.ice.ConnectivityCheckClient.log() Pair validated: 119.56.97.171:5031/udp/srflx -> 223.111.157.35:65366/udp/relay (video.RTCP). Local ufrag 91rg1d58hg33u
2019-03-06 11:42:16.007 1531-8452/org.atalk.android I/aTalk: [1728] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 223.111.157.35:50518/udp/relay -> 192.168.1.30:5028/udp/host (audio.RTP), failing.
2019-03-06 11:42:16.046 1531-8455/org.atalk.android I/aTalk: [1731] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.144.191.141:5028/udp/host -> 223.111.157.35:64622/udp/relay (audio.RTP), failing.
2019-03-06 11:42:16.089 1531-8457/org.atalk.android I/aTalk: [1733] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 223.111.157.35:50518/udp/relay -> 42.60.7.13:5028/udp/srflx (audio.RTP), failing.

Thank for sharing the information with me. I am glad you finally get aTalk to work in your system setup. ice4j has a predefined priority when selecting transport candidate pair for used in media call setup.

You are right, my NAT is only a residential hub provided free by my ISP, and should only be a simple NAT type.

regards, CM Eng

On Wed, Mar 6, 2019 at 8:03 PM tsuku notifications@github.com wrote:

Coturn problem

I am sorry that I didn't tell you the STUN/TURN server had a problem yesterday.

Yesterday I reboot the VPS to test some things. I thought it didn't matter to coturn, because of auto start service. But it seems a problem in service coturn.

Yesterday at UTC-8 16:13 the VPS reboot (thanks for command last boot), about 19:00 I found NatTypeTester didn't work with my STUN/TURN server. I realized the server maybe problems. I check with service coturn status, display "active" work fine, it is confused to me. Finally, I directly run turnserver in putty, then works. It is my second time to run turnserver. NatTypeTester

https://github.com/HMBSbige/NatTypeTester

NatTypeTester can test the network NatType. It has some default STUN servers, which can test the NatType. I have tried my server, the Nat type is always FullCone (should be Symmetric). I think it is my server support TURN (relay media). Another NAT type tester tool is WinStun, also is the same result. I use STUNner to test NAT on Android.

Then I test with two wifi. Two wifi both are PortRestrictedCone. With setting my STUN/TURN server (Support TURN √), aTalk is successful to call. And check the "Call info", "ICE candidate extended type" is "stun server relexive". It means with help of the STUN server, p2p connection is built. Also, there is no STUN server ip displaying in "Audio info".

I have tried the public STUN server, also p2p connection can be built. If no STUN server, occur "Error: Could not establish connection (ICE failed and no relay found)".

I think your network is not Symmetric, only with setting STUN server, p2p connection can be successful to build. The p2p should be lower delay than relay server, ICE may select the lower. Successful NAT Type

My test with successful call on aTalk: two devices NAT Type the smallest required mode ICE candidate extended type both PortRestrictedCone STUN server p2p stun server reflexive Symmetric + PortRestrictedCone STUN/TURN server relay media turn relayed Symmetric + Symmetric STUN/TURN server relay media turn relayed the same LAN no any STUN server lan p2p host

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cmeng-git/atalk-android/issues/31#issuecomment-470082505, or mute the thread https://github.com/notifications/unsubscribe-auth/AHl0Nrvj_E3pPHkR0bosjpykwHGZDgCMks5vT66EgaJpZM4a_MMu .

The discussions of the issues have been taken offline and concluded.

Prosody server 0.11.2 still has problem in discovery implementation that has led to the grey out of the omemo button. Prosody needs to rectify the problem.

Closing the issue as problems are not aTalk related.

===== Added info (Mail discussion) ======
I just find 0.9.12 is too old, released: 2017-01-10. Then I follow the instruction on prosody.im, add deb source.
Under latest version 0.11.2 (released: 2019-01-09) , aTalk can add contact. But omemo still cannot click.

I add the component pubsub like the following, then restart Prosody. But aTalk still cannot click OMEMO.
Component "pubsub.cloud" "pubsub"
Is my config too simple ?
https://prosody.im/doc/pubsub
https://prosody.im/doc/modules/mod_pubsub

-------------
Your setup is correct, the server does respond correctly to the pubsub.cloud as shown below:
=========
2019-03-07 16:05:44.967 21976-22212/org.atalk.android D/SMACK: SENT (2): 
    <iq to='cloud' id='oHj09-227' type='get'>
      <query xmlns='http://jabber.org/protocol/disco#items'>
      </query>
    </iq>
2019-03-07 16:05:45.096 21976-22214/org.atalk.android D/SMACK: RECV (2): 
    <iq type='result' id='oHj09-227' from='cloud' to='atalktest1@cloud/atalk'>
      <query xmlns='http://jabber.org/protocol/disco#items'>
        <item jid='proxy.cloud'/>
        <item jid='pubsub.cloud'/>
        <item jid='conference.cloud'/>
      </query>
    </iq>

2019-03-07 16:05:45.258 21976-22212/org.atalk.android D/SMACK: SENT (2): 
    <iq to='pubsub.cloud' id='oHj09-232' type='get'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
      </query>
    </iq>
2019-03-07 16:05:45.379 21976-22214/org.atalk.android D/SMACK: RECV (2): 
    <iq type='result' id='oHj09-232' from='pubsub.cloud' to='atalktest1@cloud/atalk'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
        <identity type='service' name='Prosody PubSub Service' category='pubsub'/>
        <feature var='http://jabber.org/protocol/disco#info'/>
        <feature var='http://jabber.org/protocol/disco#items'/>
        <feature var='http://jabber.org/protocol/pubsub'/>
        <feature var='http://jabber.org/protocol/pubsub#meta-data'/>
        <feature var='http://jabber.org/protocol/pubsub#multi-items'/>
        <feature var='http://jabber.org/protocol/pubsub#retract-items'/>
        <feature var='http://jabber.org/protocol/pubsub#publish-options'/>
        <feature var='http://jabber.org/protocol/pubsub#purge-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#config-node'/>
        <feature var='http://jabber.org/protocol/pubsub#create-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#persistent-items'/>
        <feature var='http://jabber.org/protocol/pubsub#item-ids'/>
        <feature var='http://jabber.org/protocol/pubsub#access-open'/>
        <feature var='http://jabber.org/protocol/pubsub#publish'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-items'/>
        <feature var='http://jabber.org/protocol/pubsub#subscription-options'/>
        <feature var='http://jabber.org/protocol/pubsub#publisher-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#create-and-configure'/>
        <feature var='http://jabber.org/protocol/pubsub#subscribe'/>
        <feature var='http://jabber.org/protocol/pubsub#modify-affiliations'/>
        <feature var='http://jabber.org/protocol/pubsub#outcast-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#instant-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#delete-items'/>
        <feature var='http://jabber.org/protocol/pubsub#member-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#delete-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-subscriptions'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-default'/>
      </query>
    </iq>
==============

However when aTalk requests for the disco#info for the jid='cloud', prosody should include all the pubsub.cloud disco#info in the list, but did not do so. So again the omemoManager failed when checking the server for omemo support.
=============
2019-03-07 16:50:15.843 24808-25512/org.atalk.android D/SMACK: SENT (0): 
    <iq to='cloud' id='80Wkk-85' type='get'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
      </query>
    </iq>
2019-03-07 16:50:15.981 24808-25513/org.atalk.android D/SMACK: RECV (0): 
    <iq type='result' id='80Wkk-85' from='cloud' to='atalktest1@cloud/atalk'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
        <identity type='im' name='Prosody' category='server'/>
        <identity type='pep' name='Prosody' category='pubsub'/>
        <feature var='urn:xmpp:blocking'/>
        <feature var='http://jabber.org/protocol/disco#info'/>
        <feature var='http://jabber.org/protocol/disco#items'/>
        <feature var='urn:xmpp:carbons:2'/>
        <feature var='http://jabber.org/protocol/commands'/>
        <feature var='msgoffline'/>
        <feature var='urn:xmpp:time'/>
        <feature var='jabber:iq:time'/>
        <feature var='vcard-temp'/>
        <feature var='jabber:iq:version'/>
        <feature var='http://jabber.org/protocol/pubsub#publish'/>
        <feature var='jabber:iq:private'/>
        <feature var='jabber:iq:roster'/>
        <feature var='urn:xmpp:ping'/>
        <feature var='jabber:iq:register'/>
        <feature var='jabber:iq:last'/>
      </query>
    </iq>
==============

Below is what jabberd responded correctly to the request for disco#info for jid='atalk.org'
==================
2019-03-07 16:58:48.156 24808-26531/org.atalk.android D/SMACK: SENT (1): 
    <iq to='atalk.org' id='80Wkk-206' type='get'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
      </query>
    </iq>
2019-03-07 16:58:48.180 24808-26532/org.atalk.android D/SMACK: RECV (1): 
    <iq xml:lang='en' to='swordfish@atalk.org/atalk' from='atalk.org' type='result' id='80Wkk-206'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
        <identity type='pep' category='pubsub'/>
        <identity name='ejabberd' type='im' category='server'/>
        <feature var='http://jabber.org/protocol/commands'/>
        <feature var='http://jabber.org/protocol/disco#info'/>
        <feature var='http://jabber.org/protocol/disco#items'/>
        <feature var='http://jabber.org/protocol/offline'/>
        <feature var='http://jabber.org/protocol/pubsub'/>
        <feature var='http://jabber.org/protocol/pubsub#access-authorize'/>
        <feature var='http://jabber.org/protocol/pubsub#access-open'/>
        <feature var='http://jabber.org/protocol/pubsub#access-presence'/>
        <feature var='http://jabber.org/protocol/pubsub#access-whitelist'/>
        <feature var='http://jabber.org/protocol/pubsub#auto-create'/>
        <feature var='http://jabber.org/protocol/pubsub#auto-subscribe'/>
        <feature var='http://jabber.org/protocol/pubsub#collections'/>
        <feature var='http://jabber.org/protocol/pubsub#config-node'/>
        <feature var='http://jabber.org/protocol/pubsub#create-and-configure'/>
        <feature var='http://jabber.org/protocol/pubsub#create-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#delete-items'/>
        <feature var='http://jabber.org/protocol/pubsub#delete-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#filtered-notifications'/>
        <feature var='http://jabber.org/protocol/pubsub#get-pending'/>
        <feature var='http://jabber.org/protocol/pubsub#instant-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#item-ids'/>
        <feature var='http://jabber.org/protocol/pubsub#last-published'/>
        <feature var='http://jabber.org/protocol/pubsub#manage-subscriptions'/>
        <feature var='http://jabber.org/protocol/pubsub#member-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#modify-affiliations'/>
        <feature var='http://jabber.org/protocol/pubsub#multi-items'/>
        <feature var='http://jabber.org/protocol/pubsub#outcast-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#persistent-items'/>
        <feature var='http://jabber.org/protocol/pubsub#presence-notifications'/>
        <feature var='http://jabber.org/protocol/pubsub#presence-subscribe'/>
        <feature var='http://jabber.org/protocol/pubsub#publish'/>
        <feature var='http://jabber.org/protocol/pubsub#publish-only-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#publish-options'/>
        <feature var='http://jabber.org/protocol/pubsub#publisher-affiliation'/>
        <feature var='http://jabber.org/protocol/pubsub#purge-nodes'/>
        <feature var='http://jabber.org/protocol/pubsub#retract-items'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-affiliations'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-default'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-items'/>
        <feature var='http://jabber.org/protocol/pubsub#retrieve-subscriptions'/>
        <feature var='http://jabber.org/protocol/pubsub#shim'/>
        <feature var='http://jabber.org/protocol/pubsub#subscribe'/>
        <feature var='http://jabber.org/protocol/pubsub#subscription-notifications'/>
        <feature var='http://jabber.org/protocol/rsm'/>
        <feature var='http://jabber.org/protocol/stats'/>
        <feature var='iq'/>
        <feature var='jabber:iq:last'/>
        <feature var='jabber:iq:privacy'/>
        <feature var='jabber:iq:register'/>
        <feature var='jabber:iq:version'/>
        <feature var='msgoffline'/>
        <feature var='presence'/>
        <feature var='urn:xmpp:blocking'/>
        <feature var='urn:xmpp:carbons:2'/>
        <feature var='urn:xmpp:mam:0'/>
        <feature var='urn:xmpp:mam:1'/>
        <feature var='urn:xmpp:mam:2'/>
        <feature var='urn:xmpp:mam:tmp'/>
        <feature var='urn:xmpp:ping'/>
        <feature var='urn:xmpp:sic:0'/>
        <feature var='urn:xmpp:sic:1'/>
        <feature var='urn:xmpp:time'/>
        <feature var='vcard-temp'/>
        <x type='result' xmlns='jabber:x:data'>
          <field

aTalk version 1.8.2 (to be released before end Apr 2019) has added provision to enable omemo messaging option on xmpp server installed with prosody 0.11.2 (released: 2019-01-09), or other xmpp services on servers having similar problems; only if the omemo setup is successful during aTalk initial launch.

Just release aTalk v1.8.2 to support Prosody xmpp implementation deviations.

Hi, I switched my server from prosody to ejabberd. Omemo works as expected now. (Although in a private group chat I had to first send an unencrypted message to every new member for the key exchange to happen.)

I am struggling (again) to set up a turn server for atalk. tsuku has used the following setup to get it working:

coturn

I use coturn to set up a STUN/TURN server. Debian is convenient with apt install coturn.

I just edit /etc/turnserver.conf with adding
listening-port= yours (the following also)
tls-listening-port=
listening-ip=
relay-ip=     (relay media)
external-ip=
It works with aTalk in any NAT (at least in my test).

There seems to be no kind of authentication set up here? I' like to have my setup as secure and privacy friendly as possible. I used this setup, which works well for nextcloud talk:

tls-listening-port=5349
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=<secret>
realm=mydomain.cp,
total-quota=100
bps-capacity=0
stale-nonce=600
cert=/etc/letsencrypt/live/mydomain.com/cert.pem
pkey=/etc/letsencrypt/live/mydomain.com/privkey.pem
cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384″
no-loopback-peers
no-multicast-peers
dh-file=/etc/nginx/ssl/dhparams.pem
no-tlsv1
no-tlsv1_1
no-stdout-log

Atalk seems to expect a username/password combination for auth. Would it be possible for atalk to work with a secret passphrase instead the username/password combination? Otherwise I would have to set up a second turnserver as static-auth-secret and username/passwort auth cannot work at the same time if I understood correctly.

P.S.: I also tried to setup coturn with usernames and passwords, but always got an error when starting a phone call from atalk, I think it was "credentials not found", or "credentials don't match", depending on how I changed the settings.

P.P.S: Winstun reports on both my turnservers:

Nat with Independend Mapping and Independent Filter - VoIP will work with STUN Preserves port number Does not supports hairpin of media

aTalk seems to expect a username/password combination for auth. Would it be possible for atalk to work with a secret passphrase instead the username/password combination?

aTalk uses ice4j.jar, a third party library to handle the stun/turn; any new features implementation need to be from the library developer. It is too big a task for aTalk to handle.

aTalk uses ice4j.jar, a third party library to handle the stun/turn; any new features implementation need to be from the library developer. It is too big a task for aTalk to handle.

Well, fair enough. I managed to set it up in the end. (Now I have 2 turnservers, one for nextcloud and one for atalk/jitsi, because they require different configurations). Here are the settings that work for me for atalk, if anyone is interested:

listening-port=42xxx tls-listening-port=42xxx external-ip=xxx min-port=42xxx max-port=42xxx fingerprint user=atalk1:0xxxx user=atalk2:0xxxx realm=xxx.org total-quota=100 bps-capacity=0 stale-nonce=600 cert=/home/xxx/etc/certificates/xxx.org.crt cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384" dh2066 no-stdout-log log-file=/home/xxx/logs/turn.log simple-log no-multicast-peers no-tlsv1 no-tlsv1_1

Cheers.

Thanks for your sharing.

cmeng-git / atalk-android

omemo encryption not available (option is greyed out) #31

coturn