powered by Jive Software

[Bug] Invalid presence show - every minute

About once every minute, I get the following in my Warn log using OF 3.9.*

I never got these messages with 3.8.2 so I gather it’s a bug for the current version.

2014.02.08 14:20:58 org.jivesoftware.openfire.net.SocketReader - Invalid presence show
java.lang.IllegalArgumentException: No enum constant org.xmpp.packet.Presence.Show.here
at java.lang.Enum.valueOf(Unknown Source)
at org.xmpp.packet.Presence$Show.valueOf(Presence.java:390)
at org.xmpp.packet.Presence.getShow(Presence.java:148)
at org.jivesoftware.openfire.net.SocketReader.process(SocketReader.java:192)
at org.jivesoftware.openfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:168)
at org.jivesoftware.openfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 76)
at org.jivesoftware.openfire.net.SocketReader.run(SocketReader.java:137)
at java.lang.Thread.run(Unknown Source)

Warnings like these typically mean that Openfire is processing an XMPP presence stanza that contains an invalid element. The content of that element in your case appears to be “here” which is invalid:

RFC3921, Page 7, Section describes the show element in a presence stanza:

The OPTIONAL element contains non-human-readable XML character data that specifies the particular availability status of an entity or specific resource. A presence stanza MUST NOT contain more than one element. The element MUST NOT possess any attributes. If provided, the XML character data value MUST be one of the following (additional availability types could be defined through a properly-namespaced child element of the presence stanza):

  • away – The entity or resource is temporarily away.
  • chat – The entity or resource is actively interested in chatting.
  • dnd – The entity or resource is busy (dnd = “Do Not Disturb”).
  • xa – The entity or resource is away for an extended period (xa = “eXtended Away”).
    If no element is provided, the entity is assumed to be online and available.

What is interesting is that you relate this to the 3.9.x release of Openfire. Typically, this is not a server issue, but an issue with one of the clients connected to the server.

Thanks for the explanation - I guess the fact that I have not seen this issue before has been unfortunate timing. It seems one particular android client since they seem to be the only ones showing up with a blank presence in the session list.

That sounds like a likely source, yes. Can you identify the client? Its developers might appreciate a heads-up.

I can’t really get a fix on which connection it is. The warn log doesn’t indicate an account at all (just what I posted, nothing more) and the debug log doesn’t show anything that matches the warn log. Going by timestamp also didn’t help… :confused:

Is there any specific thing I could look for in the debug log to find the user in question?

Short of sniffing packets, nothing that I can think of.

Drat. Well, that’s a brick wall then - can’t actually get meaningful data from sniffing packets over TLS.

A small code patch with try/catch may help. Or use a good java profiler.

I managed to figure out where the errors are coming from after some thorough digging. It’s caused by a client on another server sending an invalid presence packet to a JID on my OF server.

The offending client is a bot of some sort, judging by the resource “/bot”

An example of a bad packet:

I’m not sure what’s wrong with this packet, but I think it may be a missing id= if i compare it to other presence packets I intercepted for analysis?

The presence packets causing the errors do not contain a at all, so the error is odd to say the least, but looking at the time stamps they can be the only ones responsible as far as I can tell.