Bad iq format error

[oybek]

Getting:

parse_iq_id_failed, getting bad iq, without _ symbol, what could be source of such iqs?

<iq xmlns='jabber:client' id='c6f59123b9721df6' to='my.domain.com' type='result'/>

Source file where error happening: ejabberd_local.erl:447

[arcusfelis]

Hi, we use ejabberd_local:route_iq when server wants to ask client something. I.e. it wants to send IQ get or set to the client.
It is used in mod_caps, for example. Or could be used in mod_ping or similar modules (but I think mod_ping uses optimized version, because mod_ping requests are send by the same server node as a client on - so no need to route response from between nodes).

So, idea is simple - we route IQ to some client in cluster, it could be on another node. But once we receive iq type=result, what should we do with it? we use IQ ids which contain the node number, where to send the reply for the actual processing by the server.

Your case - client sends an IQ result for IQ we never asked for (unless you have some module which sends IQ get/setto the client and puts from="my.domain.com" in it)

We should fix parsing though, and just ignore such unexpected/unwanted IQs.

[arcusfelis]

I think we should reply with something like that:

    <iq type="error" id="UNEXPECTED_ID" from="server.example.com" to="client@example.com/resource">
      <error type="cancel">
        <service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
      </error>
    </iq>

[arcusfelis]

Added a PR. Now there should be an error sent back #4503

[arcusfelis]

Alteration of the PR. We've checked RFC again.
We don't need to reply on this IQ result.

So, changes would be: log with another log level, INFO instead of ERROR.
And we added a comment, that expected behaviour is to ignore it on the server side.

For you: on the client, double check where you send this IQ from.

RFC says:

An entity that receives a stanza of type "result" or "error" MUST
NOT respond to the stanza by sending a further IQ response of
type "result" or "error"; however, the requesting entity MAY send
another request (e.g., an IQ of type "set" to provide obligatory
information discovered through a get/result pair).