Server blocking messages?

Is there *ANY* chance that ejabberd 2.0.0 rc1 would block iq's that have a "query xmlns='jabber:iq:rpc'" in them? (there is also all the appropriate xmlrpc call stuff in there too..)

I keep getting a 503 (service-unavailable) from a rpc message send from one bot to another, and the bot code the message is addressed to doesn't throw a 503 anywhere.... I'm stumped.

-thx, hope it's not snowing where you are.

-kristofer

If you are getting harassing

If you are getting harassing stanzas from some jabber user, you can setup a privacy list to block that user.

No, I am trying to move RPC

No, I am trying to move RPC messages thru ejabberd 2.0 (rc1), using the jabber:iq:rpc namespace. I want to create a bot that can talk to a user and then commnicate with other bots of its kind by using the jabber RPC (jep-0009) ideas. The problem is, in both ruby and python, ejabberd 2.0 server doesn't seem to pass RPC messages, I get a 503 from the Server, not form the bot the RPC is addressed to.

thx,

Specify the full JID, including the resource

kyounger wrote:

ejabberd 2.0 server doesn't seem to pass RPC messages, I get a 503 from the Server, not form the bot the RPC is addressed to.

I have ejabberd 2.0.0-rc1, with vhost 'localhost'. I create two accounts: 'user1' and 'user2'. I start Tkabber two times, and in each client I login to a different account. The resources are 'Tka' for both users.

First, user1 sends this packet:

<iq to='user2@localhost/Tka' type='get'>
  <query xmlns='jabber:iq:version'/>
</iq>

user2 receives the query and answers correctly. The result is that user1 receives a nice answer:

<iq from='user2@localhost/Tka'
    type='result'
    to='user1@localhost/Tka'>
  <query xmlns='jabber:iq:version'>
    <name>Tkabber</name>
    <version>0.10.0-svn-20080115 (Tcl/Tk 8.4.18)</version>
    <os>Debian GNU/Linux lenny/sid 2.6.24-1-686</os>
  </query>
</iq>

Now I'll send the IQ query to the bare JID, without specifying the resource of the destination:

<iq to='user2@localhost' type='get'>
  <query xmlns='jabber:iq:version'/>
</iq>

In this case, user2 doesn't receive the query because ejabberd doesn't deliver it. Instead, ejabberd immediately complains, and user1 receives this answer:

<iq from='user2@localhost'
    type='error'
    to='user1@localhost/Tka'>
  <query xmlns='jabber:iq:version'/>
  <error type='cancel' code='503'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If you look closely the examples in XEP-0009, all of them specify full JIDs in the 'to' stanza attribute: all the JIDs include the resource.

I don't know if the server should block or not iq queries when the destination JID is just a bare JID.

It looks like the correct

It looks like the correct behaviour to me from the XMPP specifications itself. I think IQ only make sense when targetting an actual resource: Otherwise, you can end up sending packets to a client that do not support your RPC.

--
Mickaël Rémond
Process-one

Yes. the Resource is required

Yes, adding the resource (one of the few combinatorial choices I did not test before posting) makes my test apps work just fine. Thanks to mremond & badlop!

Syndicate content