Mailing list

Just in case someone on this list is from Berlin and bored tomorrow evening: http://www.meetup.com/de-DE/Berlin-XMPP-Meetup/events/231792450/ Holger

Hi. I can't cluster ejabberd 16.06. when uncomment ERLANG_NODE=ejabberd< at >host1 and start ejabberd, is not run ejabberd. clustering in ejabberd 16.06 is different?

* Gaurav Jain <monkeyfdude< at >gmail.com> [2016-06-29 18:08]: Stream management is hard to get right due to the protocol design. Just recently, I stumbled over one more corner case that you might run into on a busy server (that's fixed in 16.06¹). But apart from that, the code works as designed for me, and I've seen it being tested quite a lot, also under (very) bad network conditions. So if you still run into issues, I'd be highly interested in the details, especially if you still see them after updating to ejabberd 16.06. Holger ¹ https://github.com/processone/ejabberd/commit/7ddeac38b6bd0a16f46331cc

Hi, We can get "Replaced by new connection" errors/status from server in two ways. * As a stream error * As a status in presence stanza for a MUC room My question is: Will stream error will have to occur for MUC presence status be "Replaced ..."? In other words, MUC status can be "Replaced by new connection" only if there was a stream:conflict:error "Replaced by new connection"? So, if I handle stream:conflict:error on client correctly, then I will always be in clean state. Please clarify. Best Regards, PS: I have observed, with stream management, there are many issues when network gets into weird state. The stanza acknowledgement stops working. So, I was thinking of cleaning bad connections and start from scratch. _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

We are proud to introduce our new ejabberd release, ejabberd 16.06. As usual it includes many bug fixes, but also several improvements. The big improvement in this release is a new Access Control List (ACL) infrastructure. ACL rules are used in ejabberd config file to define fine-grained access to ejabberd features. In ejabberd 16.06, the ACL configuration has been much improved to make it both simpler to use and easier to read. Moreover, ACL and access rules are not mandatory anymore when configuring access restrictions for a feature or a module: You can just inline the user, for example, making small configuration much easier to setup properly. To make you even more comfortable, our new code is still supporting the old syntax and you can mix old and new syntax. It means that you can still use your existing configuration file and that you can migrate incrementally, as needed. ## The new ACL syntax New access rule will look like this: access_rules: my_access: - allow: admins - deny: blocked - allow: - user: "peter< at >server.com" - ip: "222.111.222.111/32" - allow: moderators This is an example definition for `my_access` rule. It is composed of four groups. They are evaluated from top to bottom order. the first with all listed acl rules evaluated as true is used as result. If none of them matches, evaluation fallback to default value `deny`. Above definition can be parsed as: if user belongs to ACL definition `admins`, return `allow`, if not, and user belongs to ACL definition `blocked`, return `deny`. otherwise for user "peter< at >server.com" when connected from ip: "222.111.222.111" return `allow`, and for users in ACL definition `moderators` return `allow` as well, in all other cases return `deny`. We can see in this example two new additions that were introduced in this rewrite: - you can now directly specify ACL definitions inside access rules (you no longer will be required to define ACL rules for each case) - you now have the ability to require a match on several ACL rules types at this same time (in the example: ip and user). You can use any rule that is allowed inside acl: sections (like user, server, resource, user_glob, etc.) and one additional rule that is allowed only inside access_rules: section, `acl: NameOfACL` that will look for definition of NameOfAcl inside `acl:` section and use it for matching. If you have only one ACL rule name to use you can use short form `- allow: acl_rule`, additionally `- allow: all` or `- deny: all` can be shorted still to `- allow` and '- deny`. Shapers can also be specified using new syntax, but they now go into `shaper_rules:` section and they look like that: shaper_rules: my_shaper: - 100: admin - 10: all Rules defined in `access:` section will use old syntax, and work as before, so you don't need to update your old config, to adapt it to that change. At last, one can define module specific access rules directly in modules configuration section, this is simpler to understand when reading configuration. Let's get a simple example of the changes. With previous ACL implementation, one could have this: acl: bad_servers: ip: - "XXX.XXX.XXX.XXX/32" admin: user: - "aleksey": "localhost" access: muc_admin: admin: allow muc_create: local: allow muc: all: allow s2s: bad_servers: deny all: allow c2s_shaper: admin: none all: normal modules: mod_muc: access: muc access_create: muc_create access_persistent: muc_create access_admin: muc_admin Which can be translated to this since ejabberd 16.06 with new ACL implementation: acl: admin: user: "aleksey< at >localhost" access_rules: s2s: - deny: - ip: "XXX.XXX.XXX.XXX/32" - allow c2s_shaper: - none: admin - normal modules: mod_muc: access: - allow access_create: - allow: local access_persistent: - allow: local access_admin: - allow: admin Shorter and clearer. Please also note that you can use the JID literally as a string. The previous awkward `username: domain` syntax can go away. ## Changes This is a selection of the most relevant changes: ### Config - New ACL infrastructure - Add shorter version of some common access rules definitions - Allow `< at >` inside acl rules `user`, `user_glob` or `user_regexp` to pass both user and server in single string - Add acl rule `access_rules_validator` and `shaper_rules_validator` for use in `mod_opt_type` and `opt_type` callback functions. - Allow using shapers defined by name like in s2s_shaper: fast - Allow mod_opt_type and opt_type to transform values passed to it, and support better error reporting - Do not call `transform_terms` multiple times in configuration processing when merging them - Don't halt program when `include_config_file` is missing/can't be read - Allow again multiple fqdn values in configuration ### Commands - Allow passing username and ip to `ejabberd_commands`, and use it in `mod_http_api` - Fix path to epmd in ejabberdctl - push_roster: must convert read strings to binaries - `set_presence`: Fix command API - Fix for `modules_update_specs` command - Add ejabberdctl commands to manage oauth tokens. ### Core - Bounce messages sent to server JID - Fix C2S session leak in rare cases - Fix handling of queued stanzas on session timeout - Give more time to stop and kill epmd - When stopping ejabberd, stop modules after broadcasting c2s shutdown - XEP-0198: Use different error message for bounces - XEP-0198: Add 'h' attribute to element - XEP-0198: Also count stanzas when socket is closed ### Databases - Fix pgsql compatibility on `delete_old_messages` command - Handle Redis connection in a separate module - Report in SQL when scram is enabled but the stored password isn't - Update SQL escaping - Use MEDIUMTEXT type for muc_room.opts in MySQL schema ### MAM - Send unique stanza id and archived tag also in the message carbons - Fix "assume_mam_usage: if_enabled" - Fix typo in `mod_mam:select()` - Updated support of XEP-0313 from version 0.4 to 0.5.1 - Mnesia: Avoid cleanup on bag when disc_only, switch in memory - Mnesia: Don't exceed table size limit - Mnesia: Use transactions when writing ### Client State Indication - Fix handling of chat states - Simplify check for carbon-copied chat states - Simplify handling of PEP stanzas - Pass chat states of other resources - Unwrap carbon copies when checking for chat states - Add `queue_pep` option - Queue chat state notifications - Move CSI queue handling code from `ejabberd_c2s` - When stopping, delete only the configured hooks ### Other modules - ext_mod: Set HTTP/1.0 so Github accepts the request - gen_mod: Compile early to remove undefined behaviour warning - mod_http_upload: Let client retry HTTP upload on file size mismatch - mod_last: Produce mod_last entry on account creation - mod_muc_room: Notify on affiliation changes - mod_register: Check password with jid:resourceprep when registering account - mod_roster: respect roster item changes introduced with `roster_process_item` hooks upon pushing - PubSub: Fix PubSub RSM on `get_items` - PubSub: Add support for PubSub publishing options - PEP: Fix sender in case of explicit pep subscriptions - ejabberd_xmlrpc: Report error when conversion of argument type fails ## Feedback As usual, the release is tagged in the Git source code repository on Github: https://github.com/processone/ejabberd.git The source package and binary installers are available at ProcessOne: https://www.process-one.net/ejabberd/downloads/ If you suspect that you've found a bug, please search or fill a bug report on Github: https://github.com/processone/ejabberd/issues

Hi List experts I am trying to access ejabberd web admin by visiting http://mydomain:5280/admin and i get a blank page. After checking the log file, i found that ejabberd crashes. The crash is immediate after visiting the web admin URL. This happens when i commented ## access: register in mod_register: block. The crash report ******************** 2016-06-25 08:35:24 =CRASH REPORT==== crasher: initial call: application_master:init/4 pid: <0.37.0> registered_name: [] exception exit: {{bad_return,{{ejabberd_app,start,[normal,[]]},{'EXIT',{function_clause,[{lists,map,[#Fun<gen_iq_handler.4.19837317>,register],[{file,"lists.erl"},{line,1237}]},{ejabberd_config,transform_module_options,2,[{file,"src/ejabberd_config.erl"},{line,1095}]},{ejabberd_config,'-replace_modules/1-fun-0-',1,[{file,"src/ejabberd_config.erl"},{line,993}]},{lists,map,2,[{file,"lists.erl"},{line,1238}]},{ejabberd_config,process_host_term,4,[{file,"src/ejabberd_config.erl"},{line,646}]},{lists,foldl,3,[{file,"lists.erl"},{line,1262}]},{ejabberd_config,read_file,2,[{file,"src/ejabberd_config.erl"},{line,162}]},{ejabberd_config,start,0,[{file,"src/ejabberd_config.erl"},{line,60}]}]}}}},[{application_master,init,4,[{file,"application_master.erl"},{line,134}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]} ancestors: [<0.36.0>] messages: [] links: [<0.36.0>,<0.38.0>,<0.7.0>] dictionary: [] trap_exit: true status: running heap_size: 1598 stack_size: 27 reductions: 189 neighbours: *********************************************************** But when i enable the access: register in mod_register: block , i get the following error and ejabberd does not start at all. 2016-06-25 08:35:24.452 [error] <0.37.0> CRASH REPORT Process <0.37.0> with 0 neighbours exited with reason: no function clause matching lists:map(#Fun<gen_iq_handler.4.19837317>, register) line 1237 in application_master:init/4 line 134 I have installed latest ejabberd(ejabberd-16.04) through installer in Ubuntu 14 and using mysql as database. I am also attaching the ejabberd config file ejabberd.yml as an attachment. Thanks Sagnaic _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

I using tcp loadbalancer between clients and chat servers and chat server detect loadbalancer IPs as attacker. client IPs are not sent to chat servers. On Sat, Jun 18, 2016 at 1:30 PM, <ejabberd-request< at >jabber.ru> wrote:

Sat, 18 Jun 2016 10:06:14 +0430 jacob jabber <ejabberd.jacob< at >gmail.com> wrote: When authentication fails what else info do you have except IP?

Hi. how to prevent brute-force attacks on ejabberd server when authentication failures are detected? I want to ban users not IPs. mod_fail2ban banned IPs. Is another way to prevent brute force attacks? _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

rm -rf / On Tue, Jun 14, 2016 at 6:53 PM, samad khadivar <skhadivar< at >gmail.com> wrote:

* samad khadivar <skhadivar< at >gmail.com> [2016-06-14 18:13]: This patch should fix it: https://github.com/processone/ejabberd/commit/26bce5de.patch Thanks for the report. Holger

hi. I have a ejabberd cluster includes 5 nodes and when get online users this returns *nil* priority for some users. users that have this value are not online unless user also has zero priority value . /opt/ejabberd-16.02/bin/ejabberdctl connected_users_info [<<"user1">>,64,<<"domain.com">>,47,<<6120c16d9abd2">>] c2s_compressed_tls 192.168.1.35 9243 nil ejabberd< at >192-168-11-13 72253 [<<"user1">>,64,<<"domain.com">>,47,<<"12be3db9a97f585">>] c2s_compressed_tls 192.168.1.34 56023 nil ejabberd< at >192-168-11-9 82538 [<<"user3">>,64,<<"domain.com">>,47,<<"f31fac426badc58">>] c2s_compressed_tls 192.168.1.36 11287 nil ejabberd< at >192-168-10-9 160897 [<<"user3">>,64,<<"domain.com">>,47,<<"a451ba79aa1e2b">>] c2s_compressed_tls 192.168.114.38 4637 nil ejabberd< at >192-168-14-17 179037 [<<"user5">>,64,<<"domain.com">>,47,<<"de7081c7d0b029">>] c2s_compressed_tls 192.168.114.35 49083 nil ejabberd< at >192-168-13-13 25779 [<<"user3">>,64,<<"domain.com">>,47,<<"833f23a58e4063">>] c2s_compressed_tls 192.168.114.38 18691 nil ejabberd< at >192-168-14-17 67830 [<<"user1">>,64,<<"domain.com">>,47,<<"8a9d66076fa5243">>] c2s_compressed_tls 192.168.114.38 26421 nil ejabberd< at >192-168-14-17 90711 [<<"user1">>,64,<<"domain.com">>,47,<<"155fee41b0847e0">>] c2s_compressed_tls 192.168.114.38 34717 nil ejabberd< at >192-168-114-17 152550 [<<"user3">>,64,<<"domain.com">>,47,<<"6120c16d7abd2">>] c2s_compressed_tls 192.168.114.35 9243 nil ejabberd< at >192-168-13-11 72431 [<<"user3">>,64,<<"domain.com">>,47,<<"12be3db9a97f585">>] c2s_compressed_tls 192.168.114.34 56023 nil ejabberd< at >192-168-13-14 82716 [<<"user1">>,64,<<"domain.com">>,47,<<"80f8b492e4ccb9f">>] c2s_compressed_tls 192.168.114.37 14420 0 ejabberd< at >192-168-14-13 262 [<<"user3">>,64,<<"domain.com">>,47,<<"_5473c37286ee607">>] c2s_compressed_tls 192.168.114.39 28717 0 ejabberd< at >192-168-14-65 295 [<<"user5">>,64,<<"domain.com">>,47,<<"adddec2f856c5d6">>] c2s_compressed_tls 192.168.114.35 14852 0 ejabberd< at >192-168-13-13 431 result of /opt/ejabberd-16.02/bin/ejabberdctl connected_users_number is no real. what is the meaning of nil value? why? _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

hi, in ejabberd 16.02 when I using *assume_mam_usage: if_enabled* for mam config it returns this error mod_mam: assume_mam_usage: if_enabled default: always cache_size: 100000 cache_life_time: 3600 2016-06-12 11:58:51.539 [error] <0.20724.1>< at >ejabberd_hooks:run_fold1:368 {{case_clause,{archive_prefs,{<<"user1">>,<<"domain.com ">>},always,[],[]}},[{mod_mam,message_is_archived,5,[{file,"src/mod_mam.erl"},{line,354}]},{ejabberd_hooks,safe_apply,3,[{file,"src/ejabberd_hooks.erl"},{line,382}]},{ejabberd_hooks,run_fold1,4,[{file,"src/ejabberd_hooks.erl"},{line,365}]},{ejabberd_c2s,'-handle_unacked_stanzas/1-fun-6-',8,[{file,"src/ejabberd_c2s.erl"},{line,2918}]},{lists,foreach,2,[{file,"lists.erl"},{line,1336}]},{ejabberd_c2s,terminate,3,[{file,"src/ejabberd_c2s.erl"},{line,1803}]},{p1_fsm,terminate,8,[{file,"src/p1_fsm.erl"},{line,740}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]} running hook: {message_is_archived,[{state,{socket_state,ezlib,{zlibsock,fast_tls,{tlssock,#Port<0.47476>,#Port<0.47495>},#Port<0.47539>},<0.20723.1>},ejabberd_socket,#Ref<0.0.4.219723>,false,<<"17644652947291914606">>,undefined,c2s,c2s_shaper,true,true,false,true,[verify_none,compression_none,{protocol_options,<<"no_sslv3">>},{certfile,<<"/opt/ejabberd-16.02/conf/server.pem">>}],true,{jid,<<"user">>,<<" domain.com">>,<<"Android_bc7104214a409f89">>,<<"user">>,<<"domain.com ">>,<<"Android_bc7104214a409f89">>},<<"user">>,<<"domain.com ">>,<<"Android_bc7104214a409f89">>,{{1465,715862,453492},<0.20724.1>},{23,{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user1">>,<<" domain.com">>,<<>>},nil,nil},nil},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil}},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user2">>,<<"domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},nil,nil},nil}}},{{<<"user3">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},nil,nil},nil},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user4">>,<<"domain.com ">>,<<>>},nil,nil},nil}},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil},{{<<"user5">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil}}}}},{41,{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user6">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},nil,nil},nil},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user7">>,<<"domain.com ">>,<<>>},nil,nil},nil}},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil},{{<<"user8">>,<<"domain.com ">>,<<>>},nil,nil}}},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user9">>,<<" domain.com">>,<<>>},nil,nil},nil},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil}},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user10">>,<<"domain.com ">>,<<>>},nil,nil},nil},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil}}}},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user11">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user12">>,<<"domain.com ">>,<<>>},nil,nil},nil}},{{<<"user">>,<<"domain.com ">>,<<>>},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<"domain.com ">>,<<>>},nil,nil},nil},{{<<"user13">>,<<"domain.com ">>,<<>>},nil,nil}}},{{<<"user">>,<<"domain.com">>,<<>>},{{<<"user">>,<<" domain.com">>,<<>>},{{<<"user...">>,...},...},...},...}}}},...},...]} _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

* Gaurav Jain <monkeyfdude< at >gmail.com> [2016-06-11 14:20]: According to your log snippets, you're running into the scenario I described, so the behavior is expected: If there's still anything unclear after reading <https://www.ejabberd.im/faq/tcp>, just ask. Holger

Thank you for the response. It helps. I investigated in detail and I have a reproducible as described below. * ejabberd_c2s block is configured with resume_timeout: 2 * Stream Management is enabled but stream resumption is disabled from client side. ** Two users - Sender and Receiver.* **Receiver* loses connection and does not close the stream/tcp connection properly. * *Sender* sends a message to *Receiver* but gets 503/Service-Unavailable * *Sender* retries sending failed message after 5 secs and sends successfully. ++++++++++++++++++++++++++++++++++++++ Clients sent following request to server: SEND: <enable xmlns="urn:xmpp:sm:3"/> Clients received following acks from server. RECV: <enabled xmlns="urn:xmpp:sm:3"/> RECV: <enabled xmlns="urn:xmpp:sm:3"/> ++++++++++++++++++++++++++++++++++++++ *Relevant Server logs:* -------------------------------------------------------------------------------- 1) *ejabberd* tries to send message to *Receiver* who lost connection: <<"<message from='*Sender*' to='*Receiver*' type='chat' id=''><body>I have to go back</body><thread></thread><active xmlns=' http://jabber.org/protocol/chatstates'/></message>">> -------------------------------------------------------------------------------- *Then some pubSub/multicast related packets* 016-06-11 20:03:53.698 [debug] <0.489.0>< at >shaper:update:120 State: {maxrate,100000,129.30556943548794,1465675433614549}, Size=26 M=0.1300841029950614, I=83.597 2016-06-11 20:03:53.698 [debug] <0.490.0>< at >ejabberd_c2s:send_text:1823 Send XML on stream = <<"<a xmlns='urn:xmpp:sm:3' h='26'/>">> *2016-06-11 20:03:58.587 [info] <0.606.0>< at >ejabberd_c2s:terminate:1773 ({socket_state,fast_tls,{tlssock,#Port<0.13962>,#Port<0.13963>},<0.605.0>}) Close session for Receiver* 2016-06-11 20:03:58.587 [debug] <0.606.0>< at >mod_pubsub:node_action:4186 node_action <<"pubsub.com">> <<"flat">> get_entity_affiliations [<<"pubsub. * Receiver*">>,{*Receiver*}] 2016-06-11 20:03:58.587 [debug] <0.606.0>< at >mod_pubsub:node_call:4167 node_call <<"flat">> get_entity_affiliations [<<"pubsub.com>>,{*Receiver*}] 2016-06-11 20:03:58.587 [debug] <0.606.0>< at >mod_pubsub:node_action:4186 node_action <<"pubsub.com">> <<"hometree">> get_entity_affiliations [<<" pubsub.com">>,{*Receiver*}] 2016-06-11 20:03:58.587 [debug] <0.606.0>< at >mod_pubsub:node_call:4167 node_call <<"hometree">> get_entity_affiliations [<<"pubsub.com">>,{ *Receiver*}] 2016-06-11 20:03:58.587 [debug] <0.606.0>< at >mod_pubsub:node_action:4186 node_action <<"pubsub.com">> <<"pep">> get_entity_affiliations [<<" pubsub.com">>,{*Receiver*}] 2016-06-11 20:03:58.588 [debug] <0.606.0>< at >mod_pubsub:node_call:4167 node_call <<"pep">> get_entity_affiliations [<<"pubsub.com">>,{*Receiver*}] -------------------------------------------------------------------------------- *Presence related packets* 2016-06-11 20:03:58.588 [debug] <0.606.0>< at >mod_carboncopy:disable:249 disabling for *Receiver* 2016-06-11 20:03:58.588 [debug] <0.606.0>< at >mod_shared_roster:unset_presence:1099 unset_presence for *Receiver* -> <<>> (0 resources) 2016-06-11 20:03:58.588 [debug] <0.606.0>< at >ejabberd_router_multicast:do_route:211 route_multicast from *Receiver* domain dev.com destinations [*Receiver*,*Sender*,User4,User3] packet {xmlel,<<"presence">>,[{<<"type">>,<<"unavailable">>}],[]} -------------------------------------------------------------------------------- *2016-06-11 20:03:58.588 [info] <0.606.0>< at >ejabberd_c2s:handle_unacked_stanzas:2849 1 stanzas were not acknowledged by **Receiver* 2016-06-11 20:03:58.588 [debug] <0.407.0>< at >ejabberd_router:do_route:351 route from {*Receiver*} to {*Receiver*} packet {xmlel,<<"presence">>,[{<<"type">>,<<"unavailable">>}],[]} -------------------------------------------------------------------------------- *Finally the error message 503/service-unavailable* 2016-06-11 20:03:58.589 [debug] <0.606.0>< at >ejabberd_router:do_route:351 route from {*Receiver*} to {*Sender*} packet {xmlel,<<"message">>,[{<<"type">>,<<"error">>},{"to">>, * Sender*},{<<"from">>,* Receiver*},{<<"id">>,<<"">>}],[{xmlel,<<"body">>,[],[{xmlcdata,<<"I have to go back">>}]},{xmlel,<<"thread">>,[],[{xmlcdata,<<"">>}]},{xmlel,<<"active">>,[{<<"xmlns">>,<<" http://jabber.org/protocol/chatstates ">>}],[]},{xmlel,<<"error">>,[{<<"code">>,<<"503">>},{<<"type">>,<<"cancel">>}],[{xmlel,<<"service-unavailable">>,[{<<"xmlns">>,<<"urn:ietf:params:xml:ns:xmpp-stanzas">>}],[]}]}]} On Sat, Jun 11, 2016 at 7:50 AM, Holger Weiß <holger< at >zedat.fu-berlin.de> wrote: _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

* Gaurav Jain <monkeyfdude< at >gmail.com> [2016-06-11 01:23]: Are you using stream management? Maybe the previous connection was lost and then user2 created a new session (instead of resuming the old one)? If so, this behavior is explained here: https://www.ejabberd.im/faq/tcp Holger

During testing various network connection use cases, I encounter a problem I do not fully understand. * Its a 1 x 1 message (not MUC message) * user1 sends a message to user2 * user2 is in the process of connecting to server (not fully connected yet) * user1 gets an error message back (503/service-unavailable) My understanding was: * if user2 is not connected, the message from user1 will become offline. * when user2 is connected, the offline message will be delivered * It does work like that 99% of time except 1-2 times. * Can you please tell under which circumstances 503 is returned for user2?* * ----------------------------------------------* *SEND: <message type="chat" to="user2< at >developer.com <user2< at >developer.com>" id="**someID**"><body>Testing Testing</body><thread>123</thread><active xmlns="http://jabber.org/protocol/chatstates <http://jabber.org/protocol/chatstates>"/></message>* *RECV: <message xmlns="jabber:client" from="user2< at >developer.com <user2< at >developer.com>" to="user1< at >developer.com <user1< at >developer.com>" type="error" id="someID"><body>**Testing Testing**</body><thread>123</thread><active xmlns="http://jabber.org/protocol/chatstates <http://jabber.org/protocol/chatstates>"/><error code="503" type="cancel"><service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></message>* * ----------------------------------------------* _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd

Hello, The problem is that you have process ID retained in your cluster that come from a node that has been stopped and restarted. I am not sure how you got there, as a properly configured system does not keep process id between restart. You may have a misconfiguration on your session table or MUC service. Anyway, a restart of your cluster should fix the issue. Best regards,

* Ricky Gutierrez <xserverlinux< at >gmail.com> [2016-05-07 20:33]: There's two XMPP extensions to implement multi-device synchronization currently in use: - XEP-0280 (Message Carbons) copies all incoming and outgoing messages to all clients that are currently online. - XEP-0313 (Message Archive Management) lets clients retrieve any messages they missed (because they were offline) from server-side archives. Recent ejabberd versions support both extensions if mod_carboncopy and mod_mam are enabled, Jitsi supports only XEP-0280 (Message Carbons). You can configure mod_mam to use Mnesia or SQL storage.¹ SQL storage is indeed recommended, and you could use that for mod_mam while sticking to Mnesia for everything else. But enabling mod_mam won't help unless the client supports it. Holger ¹ See <https://docs.ejabberd.im/admin/guide/configuration/#modmam>.

Hi, it is possible that this question was asked many times, but here's a question I have and I want to solve, now I have a ejabberd 15.x server with 400 users, the client default use is Jitsi in its latest version, the problem is that some users to my server ejabberd from their homes and on their personal computers and there do not load the message history of the office are connected, they ask me if we can find a solution, looking for a solution some mention using MySQL odbc, but not a solution for me, if mysql use with ejabberd xmpp integration lose my asterisk server, I work very well with the native bd ejabberd and asterisk, restart the server now if history is lost. any advice?