What steps will reproduce the problem? 1. Install GTalkSMS on any Android-Phone, configure it like below and connect to Prosody. 2. The server gets the connection request but doesn't do anything afterwards. What is the expected output? The user gets logged in or I get more details in the prosody server log. What do you see instead? GTalkSMS is stuck at "Waiting..." and retries the connection after a given time interval. The prosody server gets all the connection requests but doesn't do anything afterwards. With ejabberd as xmpp server and the same GTalkSMS settings there were no problems at all. What version of the product are you using? On what operating system? GTalkSMS 5.0.1.84 (Source: https://github.com/Yakoo63/gtalksms/releases/tag/5.0.1.84) Prosody 0.11.6 (on Debian 10 (buster), Kernel 4.19.132-1) Lua 5.2 Lua module ssl: 0.7.1 Please provide any additional information below. Configuration option of GTalkSMS Encryption: Required --- Log with some kind of "error" from GTalkSMS (gets repeated several times): 09-23 22:06:57.701 E/gtalksms( 8261): [XmppManager@connectAndAuth:562] Xmpp login failed 09-23 22:06:57.701 E/gtalksms( 8261): org.jivesoftware.smack.sasl.SASLErrorException: SASLError using PLAIN: text 09-23 22:06:57.701 E/gtalksms( 8261): at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:342) 09-23 22:06:57.701 E/gtalksms( 8261): at org.jivesoftware.smack.tcp.XMPPTCPConnection.login(XMPPTCPConnection.java:244) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.XmppManager.connectAndAuth(XmppManager.java:560) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.XmppManager.initConnection(XmppManager.java:387) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.XmppManager.start(XmppManager.java:185) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.XmppManager.xmppRequestStateChange(XmppManager.java:256) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.MainService.connectTransport(MainService.java:152) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.MainService.onHandleIntentTransportConnection(MainService.java:180) 09-23 22:06:57.701 E/gtalksms( 8261): at com.googlecode.gtalksms.MainService$ServiceHandler.handleMessage(MainService.java:134) 09-23 22:06:57.701 E/gtalksms( 8261): at android.os.Handler.dispatchMessage(Handler.java:102) 09-23 22:06:57.701 E/gtalksms( 8261): at android.os.Looper.loop(Looper.java:154) 09-23 22:06:57.701 E/gtalksms( 8261): at android.os.HandlerThread.run(HandlerThread.java:61) --- Log from prosody server: Sep 23 22:05:06 c2s5568c2fc7cd0 info Client connected Sep 23 22:05:06 c2s5568c2fc7cd0 info Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384) Sep 23 22:06:00 c2s5568c2fe6670 info Client connected Sep 23 22:06:00 c2s5568c2fe6670 info Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384) Sep 23 22:06:40 c2s5568c3003390 info Client connected Sep 23 22:06:40 c2s5568c3003390 info Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384) Sep 23 22:06:57 c2s5568c301c0b0 info Client connected Sep 23 22:06:57 c2s5568c301c0b0 info Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384) Sep 23 22:07:30 c2s5568c3039b40 info Client connected Sep 23 22:07:31 c2s5568c3039b40 info Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384) Sep 23 22:09:33 c2s5568c2e2eb90 info Client disconnected: connection closed Sep 23 22:09:56 c2s5568c2fae110 info Client disconnected: connection closed Sep 23 22:10:06 c2s5568c2fc7cd0 info Client disconnected: connection closed Sep 23 22:11:00 c2s5568c2fe6670 info Client disconnected: connection closed Sep 23 22:11:40 c2s5568c3003390 info Client disconnected: connection closed --- I already checked the password and username twice, tried to activate "allow_unencrypted_plain_auth", switched to "Encryption: Optional" within GTalkSMS but nothing helped so far. I've set "c2s_require_encryption = true" in the options of prosody but also enabling PLAIN auth and unencrypted connections doesn't change anything. It also doesn't matter if the username or password are correct. It seems to be stuck before the authentication process. I localized the section in the source code (https://github.com/Yakoo63/gtalksms/blob/11d4388ff27e318f3e5e5aa1c76f25db8eb10b98/src/com/googlecode/gtalksms/XmppManager.java#L544) where GTalkSMS throws the error. Maybe someone can help me debug this any further as I don't know what to do next. Regards codiflow

Using a different XMPP server with ejabberd 20.03.68 as server software everthing works like it should.

Hi, thanks for the report Could you provide debug logs? In case this is related to #1560, does this happen with every password you try?

• tags Status-NeedInfo

Hi Zash, > Could you provide debug logs? What kind of logs do you mean? All logs I got are already included in my bug report. > In case this is related to #1560, does this happen with every password you try? Thats a good question. I don't remember if I tried a different password but id doesn't contain any special characters. Its length is 24 characters with only upper- and lowercase letters and digits. So I don't think this should be any problem. Hope this helps any further.

The provided logs are only contain 'info' level messages. There's usually a lot more logged at the 'debug' level (see your logging config)

What version of the product are you using? On what operating system? GTalkSMS 5.0.1.84 (Source: https://github.com/Yakoo63/gtalksms/releases/tag/5.0.1.84) Prosody 0.12.0 (on Debian 10 (buster) After waiting for the new release 0.12.0 I tried to login again using GTalkSMS with debugging activated. The problem still persists and I don't know whats the cause. I only identified the following log message which seems to be pointing to some failure: Sending[c2s_unauthed]: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Please find the logs here: https://pic8.co/sh/Kgfqhp.png Or if you prefer text: Mar 18 13:44:14 connKQ6UiEl9PJgQ debug New connection FD 18 (XXX.XXX.XXX.XXX, 55421, YYY.YYY.YYY.YYY, 5222) on server FD 9 (*, 5222) │Mar 18 13:44:14 connKQ6UiEl9PJgQ debug Connected (FD 18 (XXX.XXX.XXX.XXX, 55421, YYY.YYY.YYY.YYY, 5222)) │Mar 18 13:44:14 c2s561902b05200 info Client connected │Mar 18 13:44:14 runner5R-K1idj36vM debug creating new coroutine │Mar 18 13:44:14 c2s561902b05200 debug Client sent opening <stream:stream> to redacteddomainname.de │Mar 18 13:44:14 c2s561902b05200 debug Sending[c2s_unauthed]: <?xml version='1.0'?> │Mar 18 13:44:14 c2s561902b05200 debug Sent reply <stream:stream> to client │Mar 18 13:44:14 c2s561902b05200 debug Not offering authentication on insecure connection │Mar 18 13:44:14 c2s561902b05200 debug Sending[c2s_unauthed]: <stream:features> │Mar 18 13:44:14 c2s561902b05200 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls' xml:lang='en'> │Mar 18 13:44:14 c2s561902b05200 debug Sending[c2s_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'> │Mar 18 13:44:14 connKQ6UiEl9PJgQ debug Start TLS after write │Mar 18 13:44:14 c2s561902b05200 debug TLS negotiation started for c2s_unauthed... │Mar 18 13:44:14 connKQ6UiEl9PJgQ debug Prepared to start TLS │Mar 18 13:44:14 connKQ6UiEl9PJgQ debug Starting TLS now │Mar 18 13:44:14 connKQ6UiEl9PJgQ debug TLS handshake complete (TLSv1.2 with ECDHE-RSA-CHACHA20-POLY1305) │Mar 18 13:44:14 c2s561902b05200 debug Client sent opening <stream:stream> to redacteddomainname.de │Mar 18 13:44:14 c2s561902b05200 debug Sending[c2s_unauthed]: <?xml version='1.0'?> │Mar 18 13:44:14 c2s561902b05200 debug Sent reply <stream:stream> to client │Mar 18 13:44:14 c2s561902b05200 info Stream encrypted (TLSv1.2 with ECDHE-RSA-CHACHA20-POLY1305) │Mar 18 13:44:14 c2s561902b05200 debug Channel binding 'tls-unique' supported │Mar 18 13:44:14 c2s561902b05200 debug SASL mechanisms supported by handler: SCRAM-SHA-1, SCRAM-SHA-1-PLUS, PLAIN │Mar 18 13:44:14 c2s561902b05200 debug Offering usable mechanisms: SCRAM-SHA-1, SCRAM-SHA-1-PLUS, PLAIN │Mar 18 13:44:14 c2s561902b05200 debug Sending[c2s_unauthed]: <stream:features> │Mar 18 13:44:14 c2s561902b05200 debug Received[c2s_unauthed]: <auth xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'> │Mar 18 13:44:14 c2s561902b05200 debug Sending[c2s_unauthed]: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> │Mar 18 13:44:15 connzwYEXrUU00xx debug New connection FD 19 (XXX.XXX.XXX.XXX, 55422, YYY.YYY.YYY.YYY, 5222) on server FD 9 (*, 5222) │Mar 18 13:44:15 connzwYEXrUU00xx debug Connected (FD 19 (XXX.XXX.XXX.XXX, 55422, YYY.YYY.YYY.YYY, 5222)) │Mar 18 13:44:15 c2s561902b1dbe0 info Client connected │Mar 18 13:44:15 runnerBJElVuk5Dxlx debug creating new coroutine │Mar 18 13:44:15 c2s561902b1dbe0 debug Client sent opening <stream:stream> to redacteddomainname.de │Mar 18 13:44:15 c2s561902b1dbe0 debug Sending[c2s_unauthed]: <?xml version='1.0'?> │Mar 18 13:44:15 c2s561902b1dbe0 debug Sent reply <stream:stream> to client │Mar 18 13:44:15 c2s561902b1dbe0 debug Not offering authentication on insecure connection │Mar 18 13:44:15 c2s561902b1dbe0 debug Sending[c2s_unauthed]: <stream:features> │Mar 18 13:44:15 c2s561902b1dbe0 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls' xml:lang='en'> │Mar 18 13:44:15 c2s561902b1dbe0 debug Sending[c2s_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'> │Mar 18 13:44:15 connzwYEXrUU00xx debug Start TLS after write │Mar 18 13:44:15 c2s561902b1dbe0 debug TLS negotiation started for c2s_unauthed... │Mar 18 13:44:15 connzwYEXrUU00xx debug Prepared to start TLS │Mar 18 13:44:15 connzwYEXrUU00xx debug Starting TLS now │Mar 18 13:44:15 connzwYEXrUU00xx debug TLS handshake complete (TLSv1.2 with ECDHE-RSA-CHACHA20-POLY1305) │Mar 18 13:44:16 c2s561902b1dbe0 debug Client sent opening <stream:stream> to redacteddomainname.de │Mar 18 13:44:16 c2s561902b1dbe0 debug Sending[c2s_unauthed]: <?xml version='1.0'?> │Mar 18 13:44:16 c2s561902b1dbe0 debug Sent reply <stream:stream> to client │Mar 18 13:44:16 c2s561902b1dbe0 info Stream encrypted (TLSv1.2 with ECDHE-RSA-CHACHA20-POLY1305) │Mar 18 13:44:16 c2s561902b1dbe0 debug Channel binding 'tls-unique' supported │Mar 18 13:44:16 c2s561902b1dbe0 debug SASL mechanisms supported by handler: SCRAM-SHA-1, SCRAM-SHA-1-PLUS, PLAIN │Mar 18 13:44:16 c2s561902b1dbe0 debug Offering usable mechanisms: SCRAM-SHA-1, SCRAM-SHA-1-PLUS, PLAIN │Mar 18 13:44:16 c2s561902b1dbe0 debug Sending[c2s_unauthed]: <stream:features> │Mar 18 13:44:16 c2s561902b1dbe0 debug Received[c2s_unauthed]: <auth xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'> │Mar 18 13:44:16 c2s561902b1dbe0 debug Sending[c2s_unauthed]: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

GTalkSMS does not appear to be developed anymore. The referenced version seems to use the obsolete asmack build(system?) of the smack library from before smack worked on android. The problem was most likely in smack somewhere, hopefully it has since been fixed in later version. Given how simple SASL PLAIN is and how it works with other clients I don't think there is a problem on the Prosody side, so I will close this.

• tags Status-CantFix

Unbelievable – I digged DEEP into this issue playing around with ejabberd and prosody a while during a migration and the issue is so RIDICULOUS... Using App Manager I found out that there seems to be a bug in GTalkSMS which leads to saving the content in the password field "encrypted" (saving the DOT SYMBOLS instead of the plain text value). This also explains why I saw strange strings like the following during unencrypted auth (depending on the password length): <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">AGd0YWxrc21zAOKAouKAouKAouKAouKAouKAog==</auth> <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">AGd0YWxrc21zAOKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAouKAog==</auth> So as Zash already mentioned prosody is fine, ejabberd is fine and GTalkSMS is fine too (apart from this ridiculous bug). You can easily resolve this by using App Manager (https://f-droid.org/de/packages/io.github.muntashirakon.AppManager/) and setting the password value manually in "GTalkSMS.xml" within "Shared settings": https://pic8.co/sh/B5ePKA.png Here's a screenshot of the wrong value in the database: https://pic8.co/sh/y6O1ZN.png Thanks a lot to all contributing to this issue *laugh*