OF w/ M-Link MUC troubleshooting

Openfire Openfire Support
1

Hello, first-time poster here, here is the scenario:

Openfire XMPP server with ISODE M-Link Edge server used for connecting to the rest of the world and for labeling.

Client I’m using is Transverse. I have also tried Spark and Pidgin. The reason Transverse is useful is because it shows me the error where the other two clients don’t show any errors, they just don’t work.

One of my partner’s setup is a pure M-Link environment. When I try to chat to a user in their environment, no issues.

But if I try to join one of their rooms, Transverse throws a “406” error and does not show anything in the chat window. The message is sent but the chat window is blank.

My question is what are some ways to troubleshoot a “406” error?

Thank you all

2

Hi! If I understand things correctly, you’re using a client connected to Openfire, and attempt to join a multi-user chat room on a conference service that is hosted by M-Link.

Numeric error codes are a thing of the distant past in XMPP. They have been mapped to ‘conditions’. Commonly, the 406 code is replaced by the not-acceptable condition. Upon joining a chat room, there are a couple of well-known scenarios that could lead to that error condition:

  • A message is sent by a user that has not joined the room
  • A private message is sent by a user that has not joined the room
  • A user tries to join the room using another nickname than that is reserved for them
  • the user attempts to change their room nickname but nicknames are “locked down”
  • when a new room is created where thee specified room configuration options violate one or more service policies (if you’re joining the room using an incorrect room address, this typically is interpreted as a ‘create room’ request)

This list is not exhaustive.

I cannot be certain, but if that same client can be used successfully to join a chat room on M-Link when it is directly connected to M-Link (used by a user on that server), then I suspect that the problem here is one of addressing: you may simply be using the wrong address for the chat room that you’re trying to join. Those issues can be deceptive.

What is probably most helpful now is a traffic dump of the XMPP data that is being exchanged during the room-join attempt. You can do that with Spark (but also with other clients). Spark, in the screen where you login, offers a settings menu. In there, you can enable a debugger, that will record all XMPP data.

I hope this helps!

1 Like
3

EDIT: so, it looks like i can’t enter XML lines directly in the body of my message. So, I will try to exclude the signs “greater than” and “less than”

END EDIT:

Thank you so much for the tip about the Debugger in Spark, it’s definitely useful.

i’m working on getting the full log but meanwhile i thought i’d send these few items here. maybe someone can shed some light:

So, the error happens when I send the message and it’s repeated back by my partner’s chat room:

<message id=’xxxxx-47’ type=’error’ to=’My_name1@My_domain/Spark’ from=’room_name@Their_domain/My_name2’>
  <error type=’modify’ code=’406’>
    <not-acceptable xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
  </error>
</message>

Then, there is another error when my “presence” is set but I’m not sure if it’s in any way connected to my issue in general

<presence id=’xxxxx-50’ type=’error’ to=’My_name1@My_domain/Spark’ from=’room_name@Their_domain’>
  <x xmlns=’http://jabber.org/protocol/muc’/>
  <error type=’modify’ code=’400’>
    <jid-malformed xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
  </error>
</presence>
4

You can use < and > characters, if you place them within backtick characters (or groups of three of them, for code blocks. I have tried to restore them in your post (but I’m not quite sure if I did it correctly).

There still isn’t a lot of information to go on, but if you get errors back on ‘presence’ stanzas, then this could indicate the reason for getting errors on ‘message’ stanzas that are sent later.

A ‘presence’ stanza is used for a couple of things, one of them is to join a chat room. If you get an error back on the ‘presence’ stanza that is supposed to make you join the chat room, then it stands to reason that your client did not succeed in joining that chat room. From there, it is unsurprising that sending messages to that chat room would result in errors being sent back. As I wrote in my earlier comment, one reason for the not-acceptable error condition in a message is for the message to be sent by a user that hasn’t joined the room. This is completely in line with the hypothesis above.

I would focus on debugging the ‘presence’ stanzas that you send to the room, and any response that this generates.

The desire to obfuscate addressing in the XMPP data that you post is understandable, but in my experience, it (very) often leads to accidental removal of important details. I suggest that you show us the raw XMPP stanzas without modification. That will give us a better chance of analyzing the issue.