Hi All - Running Openfire 4.2.2 - Chat clients are Spark and Pidgin
We’re subject to regulatory compliance rules and have to capture all messages sent and received by employees. IM Auditing is turned on and logging successfully.
As of recent, we’re seeing malformed message packets where it seems two packets get smashed together/conjoined. I will provide some examples below - edited for any proprietary info.
We have parsers that run against these logs to upload into our compliance system so the messages are searchable for the compliance team - these parsers are failing due to the packets not conforming to normal xml standards.
Has anyone seen this before? Is this just the way the server is receiving the packets from the clients? Or could this point to an issue serverside (CPU, Memory) at the time of the malformed packet?
Any info would be appreciated -
Thank You!
Jaime Murray
Examples:
<packet xmlns="http://www.jivesoftware.org" streamID="<packet5legi5v3qb" status="auth" streamID="5legi5v3qb" status="auth" timestamp="Sep 20, 2019 09:12:58:343 PM"><message xmlns="" to=" user#1@openfire.yourdomain.com"timestamp="Sep 20, 2019 09:11:19:821 PM"> from="user#2@openfire.yourname.com/User#2" type="chat"><body>"This is what the messsage would have said"</body></message></packet><message xmlns="" to="user#4@openfire.yourdomain.com" from="user#2@openfire.yourdomain.com/User#2" type="chat"><body>"This is what the message would have said"</body></message></packet>
<packet<packet xmlns="http://www.jivesoftware.org" streamID="27jxgmbtwp" status="auth" timestamp="Sep 27, 2019 05:51:20:771 PM"><message xmlns="" to="user#5@openfire.yourdomain.com" from="user#6@openfire.yourdomain.com/user#6" type="chat"><body>"This is what the message would have said"</body></message></packet> streamID="2zqwn05m8e" status="auth" timestamp="Sep 27, 2019 05:53:00:957 PM"><message xmlns="" to="User#7@openfire.yourdomain.com" from="user#6@openfire.yourdomain.com/user#6" type="chat"><body>"This is what the message would have said"</body></message></packet>
It would be most helpful if you can reproduce this issue with a current release of Openfire, 4.4.2.
Does that mean this is a known issue with 4.2.2?