Bug in s2s when connection fails

Openfire Openfire Dev
1

If you send a subscription request (such as subscribe) to a member on another server:

<presence to="wolverine@jabbertest.com" type="subscribe" from="wolfman@jabbertest2.com/web"> <priority>0</priority> </presence>

If the other server is not available then OutgoingSessionPromise will send an error back to the sender.
(This is a very important step so the client knows that the subscription failed to send.)

The code that does this is in: OutgoingSessionPromise - returnErrorToSender

resence reply = new Presence();
reply.setID(packet.getID());
reply.setTo(from);
reply.setFrom(to);
reply.setError(PacketError.Condition.remote_server_not_found);
routingTable.routePacket(reply.getTo(), reply, true);

The code fragment above shows that the error is routed back again.

The problem is the line: reply.setTo(from);

The “from” no longer has the resource in it because it was stripped out earlier in PresenceSubscribeHandler process.

So an error gets generated in the routePacket function. A presence can’t be routed to a bare JID and an error is generated in the WARN log:

org.jivesoftware.openfire.PacketException: Cannot route packet of type IQ or Presence to bare JID: <presence to="wolfman@jabbertest2.com" from="wolverine@jabbertest.com" type="error"> <error code="404" type="cancel"> <remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> </error> </presence>

We really need that error sent back to the client.

Could this please be corrected in the next release.

Thanks

Daniel
openfire.xml (1346 Bytes)

2

I have filed this OF-23

3

Exactly where is the full JID stripped to a bare JID? I’m not finding a reference from PresenceSubscribeHandler to OutgoingSessionPromise.

4

Hi Guus - thanks for looking into this issue.

I am currently on holidays but have just had a quick look at the source - although I can’t test anything at the moment.

The line reads:

presenteToSend.setFrom(senderJID.toBareJID());

I think its on about line 160 of PresenceSubscribeHandler.

By simply commenting out this line I no longer got the error in my post above and the error bounced back to the sender correctly.

However I am not sure that commenting it out was a good idea? as I am not sure why the sender has to be stripped to the BareJID here in the first place.

Thanks

Daniel

5

Right, got it (it’s line 168 in the current trunk):

if (!jids.isEmpty()) {
  for (JID jid : jids) {
    Presence presenteToSend = presence.createCopy();
    // Stamp the presence with the user's bare JID as the 'from' address
    presenteToSend.setFrom(senderJID.toBareJID());
    routingTable.routePacket(jid, presenteToSend, false);
  }
}

I’ve been reviewing the XMPP specs and SVN annotation, but I’m not finding what the reason is that we “stamp the presence with the user’s bare JID as the ‘from’ address.”

I’ve poked Gato (he’s the author of that snippet), but no reply yet.

6

Has there been any progress on this?

I am back at work now so let me know if I can assist with anything.

Thanks.

7

I havent’ been able to figure out why the from-address is overridden with a bare JID. On first glance, Gato had no idea either. He was going to have a more thorough look later, but I think he didn’t get around to it. I’ll re-poke him later.

8

(Just on a side note - if you are organising to release a new build please incorporate this update:

It solved a bunch of issues we were having)

9

Thanks, I adjusted the OF-46 ticket to get it evaluated before release.

10

Gato to the rescue. It turns out that overriding the FROM address is required by RFC. More details in the JIRA issue.

11

I just read the issue and it is useful to know I have to send out the unsubscribe to clean up the original request if it fails.

Only issue is, I will never know it fails because the error will never get sent back to the client.

The error will never come back because the resource is missing…

Do you know how to resolve this issue so that the error routes back correctly?

Am I missing something?

Thanks

Daniel

12

Openfire should still make sure that such an error is routed back to you. It currently does not, which is a bug (that’s why I didn’t resolve OF-23). The specs hint that Openfire should use the packet ID to trace errors that are sent back by the federated domain.