Can not connect: SASL authentication failed using mechanism PLAIN

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install GTalkSMS

2. FIll in the necessary information in Connection settings:
2.1 address to notify: gmail address
2.2 login: someuser@domain.tld
2.3 password: somepassword
2.4 Server Settings:
2.4.1: host: daenney.net
2.4.2 port: 5222
2.4.3 name: daenney.net

3. Hit Start/Stop

What is the expected output?
The system logs in and GTalkSMS is ready to go

What do you see instead?
Can not connect: SASL authentication failed using mechanism PLAIN when using 
setup wizard, otherwise usually no error output or "Incorrect 
username/password".

Additional information:
Phone model: Samsung Galaxy S / i9000
XMPP server software: prosody

I've e-mailed an app log too but it doesn't seem to contain much relevant 
information. Strangely enough it seems to mostly complain about not being able 
to reach the server at first but near the end of the logs the SASL entry 
appears.

Original issue reported on code.google.com by daniele.sluijters on 29 Aug 2011 at 8:40

[GoogleCodeExporter]

If I had to guess: The SASL error is a side effect of the connection problems. 
It's concealing the real problem. But that's all I can tell atm. 
Try to capture the XMPP stanzas send between GTalkSMS and prosody, this will 
maybe reveal the underlying issue.

Original comment by fschm...@gmail.com on 31 Aug 2011 at 10:44

• Changed state: UserFeedBack

[GoogleCodeExporter]

I'd love to, unfortunately I have no idea how so if you could enlighten me on 
that subject, please do and I'll get those over to you asap.

Original comment by daniele.sluijters on 2 Sep 2011 at 9:48

[GoogleCodeExporter]

Never mind, prosody developers helped me out.

The first noticeable thing I see with Automatic server settings:
Sep 02 11:58:00 socket  debug   server.lua: starting ssl handshake
Sep 02 11:58:00 socket  debug   server.lua: accepted new client connection from 
82.74.214.201:34435 to 5223
Sep 02 11:58:00 socket  debug   server.lua: ssl handshake error: unknown 
protocol
Sep 02 11:58:00 socket  debug   server.lua: closed client handler and removed 
socket from list

That IP-address is my phone over WiFi.

When I set it to manual and disable encryption I can get a connection though. I 
had a mistake that the login that was being sent was sending 
<username>ringring@daenney.net</username> instead of 
<username>ringring</username> because I had misconfigured login.

Do note though that it seems GTalkSMS is using legacy auth, aka iq:auth instead 
of the new SASL-mechanisms that the new XEP's recommend. In the case of Prosody 
one needs to enable the legacyauth module otherwise this will fail, which is 
disabled by default.

Another thing, the client really ought not to send a username in the form of 
username@domain.tld in the <username> part of the stanza. It is invalid causing 
the server to "translate" it to nil or unknown causing the authentication 
errors.

Now, if I configure my phone with correct login, set it to manual on port 5222 
and tell it Encryption is Required it magically manages to log in:
Sep 02 12:26:56 c2s102ceac0     debug   Received[c2s_unauthed]: <starttls 
xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Sep 02 12:26:56 socket  debug   server.lua: we need to do tls, but delaying 
until send buffer empty
Sep 02 12:26:56 c2s102ceac0     debug   TLS negotiation started for 
c2s_unauthed...
Sep 02 12:26:56 socket  debug   server.lua: attempting to start tls on 
tcp{client}: 0x1060ca40
Sep 02 12:26:58 socket  debug   server.lua: ssl handshake done

Somehow when GTalkSMS is set to Automatic it attempts legacy-SSL over port 5223 
which in my case fails (I have no idea why) but when forced with encryption 
over 5222 it decently does new-style STARTTLS.

It would also seem that the original error reported by GTalkSMS/asmack doesn't 
reflect the cause at all which added to the confusion.

Anyhow, seems my issue is solved :-).

Original comment by daniele.sluijters on 2 Sep 2011 at 10:36

[GoogleCodeExporter]

Kudos to you for the detailed feedback (it will sure be appreciated by other 
prosody/gtalksms users) and the prosody dev's for looking into it. :-D

Smack should normally try SASL auth first, iq:auth is only a fallback. Not sure 
what went wrong here. Maybe the SASL methods from server and client didn't 
match.

The problem with the username is that for gTalk for example you have to enter 
the domain part, as google has it's own XMPP extension for handling multiple 
domains over the same XMPP server. Some XMPP server just cut off the domain 
part if they don't use them, others fail.

If you set GTalkSMS to automatic, it tries to resolve the SRV DNS resource 
records to find the suitable XMPP server. Did you set those? If you want to 
discuss this further, please reply to the mailing list. Ty

Original comment by fschm...@gmail.com on 2 Sep 2011 at 12:25

• Changed state: Done

[GoogleCodeExporter]

Hello,

Thanks for the kudos', always appreciated.

I wasn't aware Google did this at all, that explains why the client
doesn't handle it as I would expect. Perhaps as a future enhancement
one could check if the XMPP service is provided by Google and if not
strip the @domain.tld part. It would be nice to update the wiki in
that regard to clearly state this in the configuration guides.

iq:auth would then indeed be a fallback though I don't even see SASL
passing in my logs, I'd at least expect an error about it before the
fallback which is what bothers me. However it works for now though
I'll dive in a bit deeper once I get around to building Prosody trunk.

As for my SRV records:

XMPP client SRV records for _xmpp-client._tcp.daenney.net point to:

1.   xmpp.daenney.net on port 5222 with a TTL of 43200 and a priority of 10
  ----> Resolves to 94.142.245.160
  --------> Port 5222 is reachable.
  --------> Port 5223 (old style ssl) is reachable.
2.   xmpp.daenney.net on port 5223 with a TTL of 43200 and a priority of 10
  ----> Resolves to 94.142.245.160
  --------> Port 5223 (old style ssl) is reachable.
  --------> Port 5223 (old style ssl) is reachable.

XMPP SRV server records for _xmpp-server._tcp.daenney.net point to:

1.   xmpp.daenney.net.daenney.net on port 5269 with a TTL of 43200 and
a priority of 10
  ----> Resolves to 94.142.245.160
  --------> Port 5269 is reachable.
  --------> Port 5223 (old style ssl) is reachable.

Those seem to be in order as far as I can gather. Currently
xmpp.daenney.net just resolves to the same server as daenney.net but
those are supposed to become separate later on.

I just realized my _xmpp-server._tcp_daenney.net record looks weird.
Turns out I forgot a . in my registrar's DNS control panel which has
now been fixed. I never noticed the issue because *.daenney.net
resolves to the same server so it was picked-up by the wildcard, I
lucked-out there.

I still don't understand though, looking at those SRV-recrods, why I
see GTalkSMS trying old-style SSL over 5223 when set to automatic
instead of going for STARTTLS over 5222.

I'll see if I can nail down the behavior or settings-combination that
causes this over the weekend and provide the associated App and
prosody logs as well as a few pcap's so you can see what's going on.

Original comment by daniele.sluijters on 2 Sep 2011 at 12:52

[GoogleCodeExporter]

Issue 220 has been merged into this issue.

Original comment by fschm...@gmail.com on 1 Dec 2011 at 5:33