3.9.3: MUC Invites result in 404

Openfire Openfire Support
1

NOTE (from discussion, below): Spark 2.6.3 CAN create new dynamic rooms and successfully invite others, but other XMPP clients don’t seem to work.

Platform:

Installer: CentOS 6.5 i386, using the Linux i386 RPM

Versions:

Affected: 3.9.2, 3.9.3 (latest release)

Not Affected: 3.9.1

Issue:

** All** MUC invites to user-created (dynamic) rooms are failing with a 404

Related: It looks like OF-791 was not completely fixed.

To reproduce:

  1. Install the latest OpenFire (3.9.3, Linux x32 RPM)
  2. Create two users
  3. Create a room with one user
  4. Invite the other user to the room
  5. Accept invite
  6. Observe: user cannot join room - it fails with error 404

I am able to reproduce this on multiple servers with no special setup. I just used a brand new OpenFire server with default settings (except I enabled additional logging) and was able to reproduce this. For clients, I have used Adium 1.5.9, **OSX Messages, **and Net::Jabber::Bot in an attempt to eliminate the client as the source of the problem.

I would have filed a bug report directly, but my JIRA account (jamyn) is too new I guess so it cannot report bugs.

In the attached debug log, I used:

Room: chatroom@jabber.server

First User: source@jabber.server (the person doing the inviting)

Second User: someuser@jabber.server (the person invited)

Relevant snippet (the attached log is longer):

  <packet xmlns="[http://www.jivesoftware.org](http://www.jivesoftware.org)" status="unknown" timestamp="May 09, 2014 09:43:30:842 AM">

<presence xmlns="" to="someuser@jabber.server/MacBook" from="chatroom@conference.jabber.server/someuser" type="error">

      <c xmlns="[http://jabber.org/protocol/caps](http://jabber.org/protocol/caps)" node="[http://pidgin.im/](http://pidgin.im/)" hash="sha-1" ver="DdnydQG7RGhP9E3k9Sf+b+bF0zo="/>

      <x xmlns="[http://jabber.org/protocol/muc](http://jabber.org/protocol/muc)"/>

<error code="404" type="wait">

<recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>

</error>

</presence>

</packet>

  <packet xmlns="[http://www.jivesoftware.org](http://www.jivesoftware.org)" streamID="ddadd17" status="auth" timestamp="May 09, 2014 09:43:30:842 AM">

<presence xmlns="" to="someuser@jabber.server/MacBook" from="chatroom@conference.jabber.server/someuser" type="error">

      <c xmlns="[http://jabber.org/protocol/caps](http://jabber.org/protocol/caps)" node="[http://pidgin.im/](http://pidgin.im/)" hash="sha-1" ver="DdnydQG7RGhP9E3k9Sf+b+bF0zo="/>

      <x xmlns="[http://jabber.org/protocol/muc](http://jabber.org/protocol/muc)"/>

<error code="404" type="wait">

<recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>

</error>

</presence>

</packet>

**Attached: **debug log.

2

It might be another bug introduced with maybe the fix for OF-103!?

OF-791 was about an item-not-found error.

This here is recipient-unavailable. Hopefully Tom has an idea.

3

Strange, but i’m unable to reproduce any of the issues with Spark. I mean MUC works and invites work for me.

4

Jamyn wrote:

I would have filed a bug report directly, but my JIRA account (jamyn) is too new I guess so it cannot report bugs.

This is right. New users can only report bugs on the forums and then (if confirmed) it is file in the tracker by a few users with permissions.

CSH, if this is new, maybe we should file a new ticket for this?

5

I’ve confirmed the following:

Client Versions: Spark 2.6.3, Adium 1.5.9 (Both OSX versions):

Spark invites Adium - SUCCESS

Adium invites Spark - FAIL

Keep in mind, this is not a new bug in Adium or Net::Jabber::Bot or OSX Messenger - all clients worked on 3.9.1.

In the attached log, I perform two tests:

  1. user spark invites user adium to spark_created_room (success)
  2. user adium invites user spark to adium_created_room (failure)
    invites.xml (293814 Bytes)
6

Do you need additional testing done? Are my “steps to reproduce” clear? Are you unable to reproduce the issue? In other words - ***is there anything I need to do to get this officially reported as a bug? ***

We use dynamic chat rooms pretty often, so this is having a real impact on us. This has been broken since OpenFire 3.9.2 - April 30th - so it’s been broken for almost two weeks. I was really hoping it’d make it into the 3.9.4 batch of fixes so it wouldn’t remain broken for another month.

**
**

7

Here you go: [OF-802] - Ignite Realtime Jira

I think, your reports and descriptions here are good enough!

I still had this in mind, even without Jira issue. I can dig into it, when I find some time.

it’s been broken for almost two weeks

There are bugs, which are unfixed since years…

But I agree with you: Not being able to create instant rooms, and invite users is probably a critical bug.

8

Thank you - I really appreciate any time you put into this issue. If I can do anything to help (more testing, more details, whatever) I’ll be happy to do so.

9

I just shortly tested it with 2 Smack-based clients (not Spark) and could not reproduce this issue. I’ve also checked the XMPP traffic. No error at all.

I also checked with another client (Swift) and I could create instant rooms and join them with 2 users. (But didn’t send an invitation on A to B).

Then I had a look at your invites.xml and saw only another MUC related error:

  <query xmlns="[http://jabber.org/protocol/disco#info](http://jabber.org/protocol/disco#info)" node="[http://jabber.org/protocol/muc#traffic](http://jabber.org/protocol/muc#traffic)"/>

but I think it’s unrelated to joining rooms.

This is not the same as the recipient-unavailable in the presence stanza.

So, what’s the real error?

10

Hi CSH,

I’ll do testing again today. Could you tell me which client you used for your testing please? I’d like to reproduce your success - so far, I’ve only been able to get the Spark client to successfully create rooms. I’ve failed with Net::Jabber::Bot and Adium, and I think users have also tried Pidgin.

11

Hi,

I did some local tests with Adium and noticed this:

In Adium I create a new room and invite another user. Adium immediately sends an invitation to the user and also asks me, if I want to configure the room or if I want to accept the default configuration.

While I haven’t decided on the room configuration, the room is locked, but the invitee already tries to enter it.

This results in a RoomLockedException in Openfire and then error, that you described above (which should be actually according to http://xmpp.org/extensions/xep-0045.html#enter-locked)

If the invitee is offline (and joins later), while I have some time to finish configuration, everything works fine.

So, might it be an Adium bug (sending invitations before the room is configured)?

12

Not just Adium though. I have tested with Exodus and Pidgin. Both will send invites (if you do so) even if the room is not configured yet. Spark is automatically configuring new room upon creation, so it has no problems sending automatic invites.

13

Here is the issue I’m seeing though:

  • Every single client listed in this thread successfully created MUC with OpenFire 3.9.1.
  • I am using the same clients and same versions, but it fails on OpenFire** 3.9.2**+

In other words, **the only thing that has changed is OpenFire. **Take the exact same clients, without changing anything, and they all work fine with OpenFire 3.9.1. We have been using OpenFire since 3.7.x and this is the first time we have ever had a problem creating and joining MUC with any client, any version, on any OS.

So I’m not sure if this is really a bug in the clients, as they were all able to function with previous versions. Rather, it seems like a new bug in OpenFire. If you install OpenFire 3.9.1, you can see every client works without issue.

I also looked at XEP-045 section 10.1.2, example 153:



If the room does not yet exist, the service SHOULD create the room (subject to local policies regarding room creation), assign the bare JID of the requesting user as the owner, add the owner to the room, and acknowledge successful creation of the room by sending a presence stanza of the following form:







So, it looks like the clients are not doing anything unusual - my understanding is, they should not be required to submit additional room configuration data in order to join a room. Remember, this all worked in 3.9.1 and earlier, with the same clients (multiple vendors, etc) with the same configuration that breaks in 3.9.2+ so I really don’t think this is a bug with the client.

14

What is your Room Creation Permissions and Default Room Settings in the group chat service settings (Admin Console)?

15

I am running a 100% stock OpenFire install (to facilitate troubleshooting).
The only configuration change I make after install is to enable debug logging under:

Admin Console:

Server Settings

Message Audit Policy

Enable Message Auditing

Packets to Audit: (all)

The default settings for Group Chat appear to be:

Admin Console:

Group Chat

Group Chat Settings

Room Creation Permissions: Anyone can create a chat room

Default Room Settings (selected):

List Room in Directory

Can anyone discover real JIDs of occupants

Allow Users to register with the room

Log Room Conversations

I think that is default, though I admit I have done testing on the current VM so I may be wrong, but I have definitely tested with the defaults on both the working and non-working versions. I do not currently have “allow occupants to invite others” checked as it’s not the default, and it wasn’t enabled previously. I have, however, tested with it enabled as well. Even if it is off, though, the person requesting the room is owner by default, and should be able to invite anyone.

16

my understanding is, they should not be required to submit additional room configuration data in order to join a room. Remember, this all worked in 3.9.1 and earlier, with the same clients (multiple vendors, etc) with the same configuration that breaks in 3.9.2+ so I really don’t think this is a bug with the client.

As far as I understand the specification, clients ARE required to configure a room, even for default (“instant”) rooms.

After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an “instant room”) or configure the room to use something other than the default room configuration (i.e., create a “reserved room”). The protocol flows for completing those two use cases are shown in the following sections.

If the initial room owner wants to accept the default room configuration (i.e., create an “instant room”), the room owner MUST decline an initial configuration form by sending an IQ set to the room@service itself containing a element qualified by the ‘http://jabber.org/protocol/muc#owner’ namespace

The service MUST then unlock the room and allow other entities to join it.

I am not sure if it’s a bug now, or if you exploited a bug in <= 3.9.1, but for me Openfire behaves correctly.

Have you tried to join the room, after the owner has finished configuration? Do your invitees immediately auto-join a room, when they receive an invitation, so that they are faster than the owner finishing the configuration?

Are we still talking about the error from your first post? Because in your other post (invites.xml) there’s no error at all.

17

I have attached Adium debug logs to this post.

I am not sure if it’s a bug now, or if you exploited a bug in <= 3.9.1, but for me Openfire behaves correctly.

I am 100% sure this is not a bug in the client. I have tried many different clients. I am 99.9% sure this is not a misconfiguration on my part. It’s the same config that works on 3.91.

  • I have used the same clients without issue up until 3.92.
  • I have upgraded OpenFire multiple times without MUC issues until 3.92.
  • I have verified the clients all work fine with other products and servers.
  • I have verified the clients all work fine with OpenFire 3.91.
  • I have verified the clients all break with OpenFire 3.92 (except Spark)

I am able to reproduce this issue 100% across multiple machines using clean, default installs of OpenFire. Every one of those clients works with other servers, and with OpenFire 3.91 and earlier. This is absolutely a change in behavior with OpenFire 3.92 and later.

How frustrating.

I have enabled debugging in Adium to show the client/server interaction. I have used Adium 1.59 for every interaction to show it’s not a problem with the client, it works fine with 3.91.

Here is Adium creating a dynamic room on OpenFire 3.91 (SUCCESS)

18:13:32: (Libpurple: jabber) Sending (ssl) (adium@of391.openfire.server/Jamyns-MacBook-Pro):

<?xml version="1.0"?>

18:13:32: (Libpurple: jabber) Recv (ssl)(398):

<?xml version="1.0"?>

18:13:32: (Libpurple: jabber) **Sending **(ssl) (adium@of391.openfire.server/Jamyns-MacBook-Pro):

<?xml version="1.0"?>

18:13:32: (Libpurple: jabber) Recv (ssl)(205):

<?xml version="1.0"?>
This room is locked from entry until configuration is confirmed.

18:13:32: (Libpurple: jabber) Recv (ssl)(335):

<?xml version="1.0"?>

18:13:36: (Libpurple: jabber) **Sending **(ssl) (adium@of391.openfire.server/Jamyns-MacBook-Pro):

<?xml version="1.0"?>

18:13:36: (Libpurple: jabber) Recv (ssl)(167):

<?xml version="1.0"?>
This room is now unlocked.

At this point the room is created and available for use on OpenFire 3.91.

Here is Adium creating a dynamic room on OpenFire 3.93 (FAILURE)

**
**

18:14:22: (Libpurple: jabber) Sending (ssl) (adium@of393.openfire.server/MacBook-Adium):

**
**

<?xml version="1.0"?>

18:14:25: (Libpurple: jabber) Sending (ssl) (adium@of393.openfire.server/MacBook-Adium):

<?xml version="1.0"?>

18:14:25: (Libpurple: jabber) Recv (ssl)(80):

<?xml version="1.0"?>

The server never continues the conversation or creates the room.

Here is Adium creating a dynamic room on ejabberd 2.13.1 (SUCCESS)

19:21:25: (Libpurple: jabber) Sending (adium@ejd.openfire.server/Jamyns-MacBook-Pro):

<?xml version="1.0"?>

19:21:25: (Libpurple: jabber) Recv (414):

<?xml version="1.0"?>

19:21:25: (Libpurple: jabber) Sending (adium@ejd.openfire.server/Jamyns-MacBook-Pro):

<?xml version="1.0"?>

19:21:25: (Libpurple: jabber) Recv (797):

<?xml version="1.0"?> 
<feature var="[http://jabber.org/protocol/muc](http://jabber.org/protocol/muc)"/>

    <value>[http://jabber.org/protocol/muc#roominfo](http://jabber.org/protocol/muc#roominfo)</value>

1

19:21:31: (Libpurple: jabber) Sending (adium@ejd.openfire.server/Jamyns-MacBook-Pro):

<?xml version="1.0"?>

19:21:31: (Libpurple: jabber) Recv (185):

<?xml version="1.0"?>

… the room is created and usable.
openfire_391_success.zip (854 Bytes)
openfire_393_failure.zip (550 Bytes)
ejabberd_213_success.zip (906 Bytes)

18

Latest message had to be moderated (all messages with URLS are going through moderation). I have approved it. Bumping this post, because CSH won’t get a notification about an approved message.

I’m not a developer. But i see that in 3.9.3 case Adium doesn’t receive first response from the server (with status 201) and then sends a ping on itself. Wonder why it sends a ping. Also i see a sumbit packet for configuration. So Adium is submitting confiruration automatically, or do you have to press some button after creating a room?

19

When creating a room with Adium, it shows the room as locked and then asks if you want to accept defaults or customize. So you do have to click something to complete the process.

20

Just for the info, some other 3.9.2 tickets related to MUC/roles: