Ejabberd: Login problems from Conversations after upgrade to 20.12
I upgraded docker container from ejabberd/ecs:20.07to ejabberd/ecs:20.12.
Now Conversations users cannot login anymore.
error.logshows:
2020-12-23 22:59:50.443659+01:00 [error] <0.956.0> ** Generic server <0.956.0> terminating
** Last message in was {'$gen_event',
{xmlstreamelement,
{xmlel,<<"response">>,
[{<<"xmlns">>,
<<"urn:ietf:params:xml:ns:xmpp-sasl">>}],
[{xmlcdata,
<<"Yz1iaXdzLHI9S2RQbHdpS3VXT28zZm1PZFdERVlNdE56MS1BdXVrMnN4Wkk4MWVOdk8zLWZWZ1Atam5wYW45OXVEZHJCSVRyUkhXLVh6SU9qUWhtdE0zWVFvcFlLNWlWODY2OGozdE5ONFRPNGFpVzdsQUF2TDFkcE1xcG1YUV9ZQU5VdFJzaDNZSktyOVF3TThOVEZJSmdXL2U0bXlmSXU0bzRnPT0scD01WE5GdjYyVklyWlZqdDRpY1ZHZ3R0ZkFMZkE9">>}]}}}
** When Server state == #{pres_a => {0,nil},
owner => <0.956.0>,mgmt_stanzas_in => 0,
socket =>
{socket_state,fast_tls,
{tlssock,#Port<0.183>,
#Ref<0.3180631637.3530424321.47918>},
65536,#Ref<0.3180631637.3530424321.47910>,
{state,70000,70000,70000,1608760790443344},
none},
shaper => c2s_shaper,mgmt_queue_type => ram,
sasl_state =>
{sasl_state,<<"***SERVER***">>,
<<"SCRAM-SHA-256">>,
{state,4,sha256,false,<<>>,
<<72,117,88,250,100,11,223,118,114,96,
255,30,87,174,185,6,29,138,130,24,53,
252,240,98,47,131,192,151,234,45,166,
119>>,
<<68,37,86,29,114,109,95,24,42,155,89,62,
150,133,134,58,193,183,225,162,15,72,
117,5,150,251,99,72,156,216,15,125>>,
<<"***USER***">>,ejabberd_auth_mnesia,
#Fun<ejabberd_c2s.1.131037462>,
<<"n=***USER***,r=KdPlwiKuWOo3fmOdWDEYMtNz1-Auuk2sxZI81eNvO3-fVgP-jnpan99uDdrBITrRHW-XzIOjQhmtM3YQopYK5iV8668j3tNN4TO4aiW7lAAvL1dpMqpmXQ_YANUtRsh3YJKr9Q,r=KdPlwiKuWOo3fmOdWDEYMtNz1-Auuk2sxZI81eNvO3-fVgP-jnpan99uDdrBITrRHW-XzIOjQhmtM3YQopYK5iV8668j3tNN4TO4aiW7lAAvL1dpMqpmXQ_YANUtRsh3YJKr9QwM8NTFIJgW/e4myfIu4o4g==,s=wqnlsRUYI3b6ku5DBMRZDA==,i=4096">>,
<<"KdPlwiKuWOo3fmOdWDEYMtNz1-Auuk2sxZI81eNvO3-fVgP-jnpan99uDdrBITrRHW-XzIOjQhmtM3YQopYK5iV8668j3tNN4TO4aiW7lAAvL1dpMqpmXQ_YANUtRsh3YJKr9Q">>,
<<"wM8NTFIJgW/e4myfIu4o4g==">>},
#Fun<ejabberd_c2s.1.131037462>,
#Fun<ejabberd_c2s.3.131037462>,
#Fun<ejabberd_c2s.4.131037462>},
lserver => <<"***SERVER***">>,
codec_options => [ignore_els],
stream_id => <<"814510091305028662">>,
stream_authenticated => false,
mgmt_max_queue => 5000,tls_enabled => true,
ip => {{84,156,209,224},52220},
stream_version => {1,0},
mod => ejabberd_c2s,tls_required => true,
mgmt_timeout => 300000,
csi_queue => {0,#{}},
mgmt_resend => if_offline,lang => <<"en">>,
xmlns => <<"jabber:client">>,
sasl_mech => <<"SCRAM-SHA-256">>,user => <<>>,
tls_options =>
[compression_none,
{protocol_options,<<"no_sslv3|no_tlsv1_3">>}],
mgmt_ack_timeout => 60000,tls_verify => false,
resource => <<>>,
stream_state => wait_for_sasl_response,
stream_encrypted => true,
server => <<"***SERVER***">>,
mgmt_max_timeout => 300000,access => c2s,
stream_restarted => true,stream_header_sent => true,
mgmt_stanzas_req => 0,zlib => true,
mgmt_stanzas_out => 0,csi_state => active,
socket_monitor =>
#Ref<0.3180631637.3530293249.47911>,
stream_timeout => {30000,-576457710997},
stream_direction => in,mgmt_state => inactive,
stream_compressed => false}
** Reason for termination ==
** {badarg,[{crypto,do_exor,
[<<229,115,69,191,173,149,34,182,85,142,222,34,113,81,160,
182,215,192,45,240>>,
<<160,72,113,193,233,164,155,228,173,224,182,70,239,52,
124,66,156,61,108,114,129,38,27,98,242,110,163,23,20,
59,35,58>>],
[]},
{xmpp_sasl_scram,mech_step,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_sasl_scram.erl"},
{line,202}]},
{xmpp_sasl,server_step,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_sasl.erl"},
{line,125}]},
{xmpp_stream_in,process_sasl_response,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_stream_in.erl"},
{line,902}]},
{xmpp_stream_in,handle_info,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_stream_in.erl"},
{line,404}]},
{p1_server,handle_msg,8,
[{file,"/ejabberd/deps/p1_utils/src/p1_server.erl"},
{line,696}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,249}]}]}
2020-12-23 22:59:50.448702+01:00 [error] <0.956.0>@proc_lib:crash_report/4:508 CRASH REPORT:
crasher:
initial call: xmpp_stream_in:init/1
pid: <0.956.0>
registered_name: []
exception exit: {badarg,
[{crypto,do_exor,
[<<229,115,69,191,173,149,34,182,85,142,222,34,
113,81,160,182,215,192,45,240>>,
<<160,72,113,193,233,164,155,228,173,224,182,70,
239,52,124,66,156,61,108,114,129,38,27,98,242,
110,163,23,20,59,35,58>>],
[]},
{xmpp_sasl_scram,mech_step,2,
[{file,
"/ejabberd/deps/xmpp/src/xmpp_sasl_scram.erl"},
{line,202}]},
{xmpp_sasl,server_step,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_sasl.erl"},
{line,125}]},
{xmpp_stream_in,process_sasl_response,2,
[{file,
"/ejabberd/deps/xmpp/src/xmpp_stream_in.erl"},
{line,902}]},
{xmpp_stream_in,handle_info,2,
[{file,
"/ejabberd/deps/xmpp/src/xmpp_stream_in.erl"},
{line,404}]},
{p1_server,handle_msg,8,
[{file,
"/ejabberd/deps/p1_utils/src/p1_server.erl"},
{line,696}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,249}]}]}
in function p1_server:terminate/7 (/ejabberd/deps/p1_utils/src/p1_server.erl, line 878)
ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.126.0>]
message_queue_len: 0
messages: []
links: [<0.717.0>]
dictionary: [{already_terminated,true},
{'$internal_queue_len',0},
{rand_seed,{#{bits => 58,jump => #Fun<rand.13.8986388>,
next => #Fun<rand.10.8986388>,type => exsss,
uniform => #Fun<rand.11.8986388>,
uniform_n => #Fun<rand.12.8986388>},
[92615320350636863|18975685296798965]}}]
trap_exit: false
status: running
heap_size: 10958
stack_size: 27
reductions: 176245
neighbours:
2020-12-23 22:59:50.454216+01:00 [error] <0.717.0>@supervisor:do_restart/3:716 SUPERVISOR REPORT:
supervisor: {local,ejabberd_c2s_sup}
errorContext: child_terminated
reason: {badarg,
[{crypto,do_exor,
[<<229,115,69,191,173,149,34,182,85,142,222,34,113,81,160,
182,215,192,45,240>>,
<<160,72,113,193,233,164,155,228,173,224,182,70,239,52,
124,66,156,61,108,114,129,38,27,98,242,110,163,23,20,
59,35,58>>],
[]},
{xmpp_sasl_scram,mech_step,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_sasl_scram.erl"},
{line,202}]},
{xmpp_sasl,server_step,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_sasl.erl"},
{line,125}]},
{xmpp_stream_in,process_sasl_response,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_stream_in.erl"},
{line,902}]},
{xmpp_stream_in,handle_info,2,
[{file,"/ejabberd/deps/xmpp/src/xmpp_stream_in.erl"},
{line,404}]},
{p1_server,handle_msg,8,
[{file,"/ejabberd/deps/p1_utils/src/p1_server.erl"},
{line,696}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,249}]}]}
offender: [{pid,<0.956.0>},
{id,undefined},
{mfargs,{ejabberd_c2s,start_link,undefined}},
{restart_type,temporary},
{shutdown,5000},
{child_type,worker}]
qsodev
All 36 comments
Can you show your .yml config?
licaon-kter
on 24 Dec 2020
This crash seems to be result of client sending incorect response (it sends only 20 bytes/160 bits long response where for sha256 mechanism that it choosen it should be 32/256). Not completly sure why this happen - is that result of data that server sends previously? Could you share your config (i am mostly interested in what auth modules you have enabled and options for scram settings). If you would want to help even more, could you try starting debug shell (ejabberdctl debug), and inside of that call ejabberd_auth:get_password(<<"USER">>, <<"SERVER">>). (with . at end, and with using correct username/server), i don't need to know details from that but if you are getting just <<"...">>, or {scram, <<"...">>...} or {scram, sha_SOMETHING, ...} - in that case i would need to know what that sha is
prefiks
on 24 Dec 2020
You can disable SCRAM-SHA-256 in server by adding:
disable_sasl_mechanisms:
- "SCRAM-SHA-256"
to your config file, i guess this will make conversation use SCRAM-SHA-1 which probably will work.
prefiks
on 24 Dec 2020
stripped ejabberd.yml:
loglevel: 4
log_rotate_size: infinity
log_rotate_date: "$D0"
log_rotate_count: 1
log_rate_limit: 100
hide_sensitive_log_data: false
hosts:
- ******
- ******
certfiles:
- "/home/ejabberd/conf/ejabberd.pem"
listen:
-
port: 5222
ip: "0.0.0.0"
module: ejabberd_c2s
starttls: true
starttls_required: true
protocol_options:
- "no_sslv3"
- "no_tlsv1_3"
max_stanza_size: 65536
shaper: c2s_shaper
access: c2s
zlib: true
-
port: 5269
ip: "0.0.0.0"
module: ejabberd_s2s_in
shaper: s2s_shaper
max_stanza_size: 131072
-
port: 5280
ip: "0.0.0.0"
module: ejabberd_http
tls: true
request_handlers:
"/bosh": mod_bosh
s2s_use_starttls: required
outgoing_s2s_families:
- ipv4
outgoing_s2s_timeout: 60
auth_method: internal
shaper:
normal: 70000
fast: 99000
proxyrate: 70000
max_fsm_queue: 1000
###' ACCESS CONTROL LISTS
acl:
admin:
user:
- ****
local:
user_regexp: ""
loopback:
ip:
- "127.0.0.0/8"
###' SHAPER RULES
shaper_rules:
max_user_sessions: 10
max_user_offline_messages:
- 5000: admin
- 100
c2s_shaper:
- none: admin
- normal
s2s_shaper: fast
###' ACCESS RULES
access_rules:
local:
- allow: local
c2s:
- deny: blocked
- allow
announce:
- allow: admin
configure:
- allow: admin
muc_create:
- allow: local
pubsub_createnode:
- allow: local
register:
- allow
trusted_network:
- allow: loopback
language: "en"
## Configuration of modules that are common to all vhosts
modules:
***
Is this maybe related to this commit? https://github.com/processone/ejabberd/commit/1b7502acbc6687e925995238b7540f18bd44c091
qsodev
on 24 Dec 2020
No, that commit was just for problems with type checker program, but those didn't change anything in how program functions
prefiks
on 24 Dec 2020
You can disable SCRAM-SHA-256 in server by adding:
disable_sasl_mechanisms: - "SCRAM-SHA-256"to your config file, i guess this will make conversation use SCRAM-SHA-1 which probably will work.
This does unfortunately not help. It gives me a very similar error log entry but with SCRAM-SHA-1 failing.
qsodev
on 28 Dec 2020
Update: After some clean and recompiles, now I can reproduce the crash!
--
With ejabberd 20.12 (source code compiled), with your configuration, and Conversations 2.3.5+fcr (from Google Play), login works correctly for me:
2020-12-29 10:05:30.115260+01:00 [info] (<0.677.0>)
Accepted connection [::ffff:192.168.1.10]:51902
-> [::ffff:192.168.1.23]:5222
2020-12-29 10:05:30.294820+01:00 [info] (tls|<0.677.0>)
Accepted c2s SCRAM-SHA-256 authentication for user1@localhost
by mnesia backend from ::ffff:192.168.1.10
2020-12-29 10:05:30.305882+01:00 [info] (tls|<0.677.0>)
Opened c2s session for user1@localhost/Conversations._NdE
(ejabberd@localhost)1> ejabberd_auth:get_password(<<"user1">>, <<"localhost">>).
<<"mypass11">>
On the other hand, if I add
disable_sasl_mechanisms:
- "SCRAM-SHA-256"
then Conversations refuses to login, and shows an error like "SASL Mechanism degraded" (sorry, text translated from spanish).
badlop
on 29 Dec 2020
@badlop +fcr means F-Droid
Also why so old? 2.9.2 is latest
licaon-kter
on 29 Dec 2020
Ah, right, it was from F-Droid. But anyway, I get same results with Conversations 2.3.5+fcr and 2.9.2-fcr
- default options -> crash!!
disable_sasl_mechanisms: ["SCRAM-SHA-256"]-> Accepted c2s SCRAM-SHA-1auth_password_format: scram-> Accepted c2s SCRAM-SHA-1auth_password_format: scramanddisable_sasl_mechanisms: ["SCRAM-SHA-256"]-> Accepted c2s SCRAM-SHA-1
badlop
on 29 Dec 2020
Oh, ok, since plain is the default: https://docs.ejabberd.im/archive/20_04/toplevel/#auth-password-format
licaon-kter
on 29 Dec 2020
@badlop Would you be apply this patch to deps/xmpp and see if this helps with that crash?
```
diff --git a/src/scram.erl b/src/scram.erl
index c2d60d2..5fc9a3b 100644
--- a/src/scram.erl
+++ b/src/scram.erl
@@ -53,7 +53,19 @@ client_signature(Algo, StoredKey, AuthMessage) ->
-spec client_key_xor(binary(), binary()) -> binary().
client_key_xor(ClientProof, ClientSignature) ->
- crypto:exor(ClientProof, ClientSignature).
+ SizeDiff = size(ClientProof) - size(ClientSignature),
+ {P, S} =
+ if
+ SizeDiff > 0 ->
+ Pad = SizeDiff8,
+ {ClientProof, <
+ SizeDiff < 0 ->
+ Pad = -SizeDiff
+ {<
+ true ->
+ {ClientProof, ClientSignature}
+ end,
+ crypto:exor(P, S).
-spec server_signature(algo(), binary(), binary()) -> binary().
```
prefiks
on 29 Dec 2020
It should no longer crash, but let see if it also will allow to login. Per scram spec what client sends should have same size as hashed value (if i am reading it correctly), but clearly it isn't in this situation, let see if padding will help there.
prefiks
on 29 Dec 2020
With that patch, ejabberd rejects the auth:
2020-12-29 15:40:00.487405+01:00 [warning] (tls|<0.544.0>)
Failed c2s SCRAM-SHA-256 authentication for [email protected]
from 192.168.1.17: Invalid username or password
For completness, could you also try this (which will cut longer string to size of shorter instead of padding):
```
diff --git a/src/scram.erl b/src/scram.erl
index c2d60d2..6ff1d50 100644
--- a/src/scram.erl
+++ b/src/scram.erl
@@ -53,7 +53,17 @@ client_signature(Algo, StoredKey, AuthMessage) ->
-spec client_key_xor(binary(), binary()) -> binary().
client_key_xor(ClientProof, ClientSignature) ->
- crypto:exor(ClientProof, ClientSignature).
+ SizeDiff = size(ClientProof) - size(ClientSignature),
+ {P, S} =
+ if
+ SizeDiff > 0 ->
+ {binary:part(ClientProof, 0, size(ClientSignature)), ClientSignature};
+ SizeDiff < 0 ->
+ {ClientProof, binary:part(ClientSignature, 0, size(ClientProof))};
+ true ->
+ {ClientProof, ClientSignature}
+ end,
+ crypto:exor(P, S).
-spec server_signature(algo(), binary(), binary()) -> binary().
```
prefiks
on 29 Dec 2020
Second patch result is same that the first, ejabberd rejects auth.
badlop
on 29 Dec 2020
Thank you for testing, something seems to broken in conversations code, maybe it uses sha1 all the time even when it selects sha256?
prefiks
on 29 Dec 2020
@inputmice ^^^
licaon-kter
on 29 Dec 2020
The only client I know supporting SHA-256 is Gajim 1.2.2. Is there any other one?
2020-12-29 19:17:51.389390+01:00 [info] (<0.620.0>)
Accepted connection [::1]:39998 -> [::1]:5222
2020-12-29 19:17:51.533675+01:00 [info] (tls|<0.620.0>)
Accepted c2s SCRAM-SHA-256 authentication for user1@localhost
by mnesia backend from ::1
2020-12-29 19:17:51.542260+01:00 [info] (tls|<0.620.0>)
Opened c2s session for user1@localhost/gajim.1V9CYVLO
@prefiks what value exactly is 160 instead of 256 bits long?
I didn鈥檛 write the SCRAM code and only have a very rudimentary understanding of it. But on first glance the relevant values (everything hmaced) seems to be 32 bytes long. So it would be good to know what value exactly is wrong.
Maybe @SamWhited who wrote the code knows more.
iNPUTmice
on 29 Dec 2020
It looks like the client proof and the client signature don't match (client proof is 20 bytes and client signature is 32 bytes in the original error output). This is causing a failure here:
I don't see how that would be possible from a quick glance at the conversations code, but I can't dig into it right this moment.
SamWhited
on 29 Dec 2020
@iNPUTmice
Problem is with p value from last response that looks like this (after base64 decoding):
c=biws,r=KdPlwiKuWOo3fmOdWDEYMtNz1-Auuk2sxZI81eNvO3-fVgP-jnpan99uDdrBITrRHW-XzIOjQhmtM3YQopYK5iV8668j3tNN4TO4aiW7lAAvL1dpMqpmXQ_YANUtRsh3YJKr9QwM8NTFIJgW/e4myfIu4o4g==,p=5XNFv62VIrZVjt4icVGgttfALfA=
After base64 decoding it as well we are getting 20 bytes value - but this should be result of running hmac(saltedpassword, "Client Key") which in scram-sha-256 should result in 256 bit value = 32 bytes.
I did look briefly at conversation code and think that this part https://github.com/iNPUTmice/Conversations/blob/f23016c967c87df28543b781b15780f1f877802e/src/main/java/eu/siacs/conversations/crypto/sasl/ScramMechanism.java#L32 may have something with it (this is from where that p values originates i think), i think CACHE is shared between ScramSha1 and ScramSha256, and i guess what it uses as HMAC value may not be correct there (but i didn't write java in long time so may be wrong).
@badlop PSI theoretically should be also be able to do that, but it depends on what qt libraries you have in your system, i also was able to test it with client writen in go.
prefiks
on 30 Dec 2020
Please search "XMPP client" here:
SCRAM-SHA-1 and SCRAM-SHA-256:
- Thunderbird 71 (XMPP client): https://thunderbird.net/
- Tigase Beagle IM (XMPP client): https://beagle.im/
- Tigase Siskin IM (XMPP client): https://siskin.im/
- Conversations (XMPP client): https://github.com/siacs/Conversations
- UWPX (XMPP client): https://github.com/UWPX/UWPX-Client
SCRAM-SHA-1, SCRAM-SHA-256, SCRAM-SHA-512, SCRAM-SHA3-512:
- KDE Kaidan (XMPP client): https://www.kaidan.im/
SCRAM-SHA-1, SCRAM-SHA-224, SCRAM-SHA-256, SCRAM-SHA-384, SCRAM-SHA-512:
- Psi/Psi+ (XMPP client) with QCA: https://psi-im.org/ + https://psi-plus.com/
- Vacuum IM (XMPP client): https://github.com/Vacuum-IM/vacuum-im
- eyeCU (XMPP client): https://github.com/eyecu-im/eyecu-qt
SCRAM-SHA-1(-PLUS) and SCRAM-SHA-256(-PLUS):
- Gajim 1.2.x (XMPP client): https://gajim.org/
SCRAM-SHA-1(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-512(-PLUS):
- CoyIM (XMPP client): https://github.com/coyim/coyim
- Tigase Stork IM / Tigase Android Messenger (XMPP client): https://github.com/tigase/stork
SCRAM-SHA-1(-PLUS), SCRAM-SHA-224(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-384(-PLUS), SCRAM-SHA-512(-PLUS):
- Miranda NG (XMPP client): https://github.com/miranda-ng/miranda-ng
SCRAM-SHA-1(-PLUS):
- Swift IM (XMPP client): https://swift.im/swift.html
SCRAM-SHA-1:
- Pidgin (XMPP client), Finch, and libpurple: https://pidgin.im/
- Chatty (XMPP client): https://source.puri.sm/Librem5/chatty
- Pandion (XMPP client): https://github.com/pandion/pandion
- Tkabber (XMPP client): http://tkabber.jabber.ru/
Neustradamus
on 30 Dec 2020
Seems that this commit in conversation should fix it: https://github.com/iNPUTmice/Conversations/commit/692ee6c9fbd03f38aa8ab969077b77cc77357854 i also did commit change in xmpp (https://github.com/processone/xmpp/commit/eacee148f91779c44b0836e02d25fd05392456b7) that should handle that with error instead of crash.
prefiks
on 30 Dec 2020
I am still seeing this if I install paid app from the Google Play :/
PeterMalkin
on 18 Apr 2021
@PeterMalkin so which server version? Which server config (upload to https://gist.github.com and post link)? Conversations 2.9.10 right?
licaon-kter
on 18 Apr 2021
This is happening with ejabberd server v 21.04
The version of the app I could not gather - wasnt obvious from the UI, and I had no adb access to the device I installed it on. But it is the latest paid version from the Google Play store.
Here's my server config. Pretty vanilla, I only modified the URL
https://gist.github.com/PeterMalkin/926c28cc73b33054228de4e782b261b3
PeterMalkin
on 19 Apr 2021
What do you see exactly? Version is in Settings, scroll down.
Conversations 2.9.11 should fix issues with exotic network connections.
licaon-kter
on 19 Apr 2021
Conversations 2.9.13+pcr
On the server side I see
2021-05-10 07:36:25.240 [info] <0.380.0>@ejabberd_listener:accept:273 (<0.1046.0>) Accepted connection [::ffff:10.0.0.93]:42632 -> [::ffff:192.168.128.7]:5222
2021-05-10 07:36:25.310 [warning] <0.1046.0>@ejabberd_c2s:process_auth_result:276 (tls|<0.1046.0>) Failed c2s SCRAM-SHA-512 authentication from ::ffff:10.0.0.93: Incompatible SCRAM methods
I am using Pixel4a
What is also interesting, I have a friend who can build Conversations from source and connect to my server just fine. He shared the .apk with me. I side loaded it onto the same Pixel4a, and have seen the same failure to auth just like from the paid version
PeterMalkin
on 10 May 2021
@PeterMalkin did the server admin update the scram methods lately?
licaon-kter
on 10 May 2021
I am the admin of the server. No, I have never updated anything. I have posted the config for your convenience above.
The ejabberd instance I am running is in a docker container, I can share my docker file if reproducing the setup would be useful for you.
But for the most part the installation is simply
RUN wget https://www.process-one.net/downloads/downloads-action.php?file=/21.04/ejabberd_21.04-0_amd64.deb -O ejabberd_21.04.deb
RUN export DEBIAN_FRONTEND=noninteractive && apt-get -y install ./ejabberd_21.04.deb
Also, I have tried Atalk android app, which works fine on the same phone with the same server
PeterMalkin
on 10 May 2021
Still facing this problem.
Have also tried https://play.google.com/store/apps/details?id=im.blabber.messenger with the same results
Filed a bug: https://github.com/processone/ejabberd/issues/3607
PeterMalkin
on 18 May 2021
@PeterMalkin blabber is just a fork of Conversations
Try with Stork or aTalk or Yaxim
licaon-kter
on 18 May 2021
aTalk definitely works.
PeterMalkin
on 19 May 2021
Yaxim works as well
PeterMalkin
on 19 May 2021
@PeterMalkin: Any news about it?
Neustradamus
on 4 Jul 2021
Related issues
rahul-l
路
3Comments
andrew-vant
路
4Comments
irvingwa
路
3Comments
jjdp
路
3Comments
shazvan275
路
3Comments