OF 3.7 vs 3.10: now getting "Failed to route packet to JID" on Jabber.NET clients

I have upgraded our OpenFire from 3.7 to 3.10. Most of our clients work just fine. But we have a Jabber.NET client that can receive okay from other client types (like Spark), but can not send messages. When the client based on Jabber.NET sends a message through the 3.10 OF server, I see the following in the debug logs:

2015.08.14 16:19:31 org.apache.mina.filter.codec.ProtocolCodecFilter - Processing a MESSAGE_RECEIVED for session 11 
2015.08.14 16:19:31 org.jivesoftware.openfire.spi.RoutingTableImpl - Failed to route packet to JID: atlwave12297122971@ packet: <message id="JN_16" to="atlwave12297122971@" from="atlwave12297422974@"><body>Message</body></message> 
2015.08.14 16:19:32 org.jivesoftware.util.log.util.CommonsLogFactory - Closing statement 1232583 (belonging to connection 3) automatically 
2015.08.14 16:19:32 org.jivesoftware.util.log.util.CommonsLogFactory - Closing statement eb3a80 (belonging to connection 3) automatically 
2015.08.14 16:19:33 org.apache.mina.filter.executor.OrderedThreadPoolExecutor - Adding event MESSAGE_RECEIVED to session 9

Any thoughts on why this happens? If I flip back to using 3.7 - it works fine.

Thanks, Scott

Your xmpp.domain is set to the ip address and not some domain name? I am unsure if that is supported these days

Daryl - thanks for taking the time to look at this and response.

I don’t think the lack of a domain name is the issue. I use the Spark client and it sends using ip address all day long. we don;t have FQDN’s for these systems.

I looked at the message archive and discovered something else, the messages that are not getting routed have a “toJIDResource” of “IM”.

So - the client in question seems to send messages with a to address of: "atlwave12297122971@". On OpenFire 3.7, that gets translated into a message where the “toJIDResource” is still “null” and the “toJID” field is "atlwave12297122971@".

Switching over to OpenFire 3.10, I see that records added by the rogue client now have a “toJID” field that is missing the “/IM” (it’s just "atlwave12297122971@") but now the “toJIDResource” field has an “IM” in it instead of null.

I honestly don’t know what all those fields are. But my guess is when the client puts the “/IM” onto the end, with OF 3.7 it would pass through. But with OF 3.10 - it invokes some other lookup that causes issues.

Any thoughts on this from anybody?

Just a follow-up. So for some reason this original client app using Jabber.NET was appending the “/IM” to the end of the address.

That worked in OF 3.7 - even if the resource was wrong. But in OF 3.10, it does not route.

Hope that helps someone.