I don’t know, the bot is working now…
I am having the same problem here with gtalk gateway. I need to stop and restart the service but after a few hours it is back. any ideas on a resolution?
The bug still appears sometimes. It’s really a problem for a bot who must be connected h24!
How can I catch the packet ? The only thing I know is that it’s only related to the date when the message is sent.
Plus, as you can see, the error is raised by Smack itself, I don’t know what can I do !! And if the date is malformed, the packet is sent by psi to openfire and openfire send it to my bot. So the problem concern openfire if the problem is an invalid date format.
Oh !!! I’ve found something !!! I know how to crash my bot !
If I send :
<message id=“IbXQi-45” type=“groupchat” to="main@conference.myserver.fr">
<body>(test)</body>
<x xmlns=“jabber:x:delay” stamp=“200868T09:16:20” from="mylogin@myserver.fr"/>
</message>
My bot quit. And there nothing I can do if the packet is handled by Smack… Please, you have to do something. Maybe Openfire shouldn’t send malformed packets ?
After a reconnection on the room, I can see that my packet has been rewriten like this : (and the bot accepts it there…)
<message id=“IbXQi-45” type=“groupchat” to="mylogin@myserver.fr/MyClient" from="main@conference.myserver.fr/Max">
<body>(test)</body>
<x xmlns=“jabber:x:delay” stamp=“200868T09:16:20” from="mylogin@myserver.fr"/>
<x xmlns=“jabber:x:delay” stamp=“20080608T07:18:48” from="mylogin@myserver.fr/MyClient"/>
</message>
I don’t think it is an open-fire specific issue, since I get the same problem with gchat. And I don’t think it is related to MUC either, since my bot is not doing anything with MUC. It is something wrong with Smack. I think it only happens during the first few days of the month, when the packets are dated with mdyyyy instead of mmddyyyy.
Michael
This bug also concerns Spark because Spark use Smack.
It’s really easy to kick off someone who use Spark !!! Just send this :
<message to="victim@hisserver.fr/spark" type=“chat” id=“1345”>
<body>plop</body>
<x xmlns=“jabber:x:delay” stamp=“200868T09:16:20” from="mylogin@monserver.fr"/>
<thread>9gOp44</thread>
</message>
And bye bye victim.
I hope this security issue will be fixed soon !!!
Another similar old bug report SMACK-207
Daniel (in Live Chat) is saying he was fixing that in Openfire trunk. He says it must be an Openfire bug, not smack. Btw, you are testing only with Openfire server? Anyway, please test that with next version of Openfire and then report back.
My bot is running on gchat. Google aren’t using OpenFire, are they?
Michael
Yes, Openfire shouldn’t relay invalid packets, nevertheless Smack shouldn’t hang up when it receives a bad paquet ! The packet should be ignored.
I’ll try as soon as possible with the next release.
According to what Daniel says it’s not Smack that hangs up, but Openfire is closing Smack’s connection upon getting that packet.
Well, i dont really want to install some other xmpp server to test that Can somebody test that with say ejabberd + Spark?
No ! It’s not the one who send an invalid packet who is kicked off ! It’s the ones who can’t parse it correctly and it’s not openfire which kick’em off, reread my first post.
The problem is simple :
An invalid packet is sent to a client. If the client can handle it (like gajim/psi etc), there is no problem. But if the client uses Smack to deal with xmpp, smack crash/bug and the client is disconnected.
So there is two things :
-
Openfire relay packets without checking them correctly. I can understand this choice anyway.
-
Smack receives a packet, can’t parse it and disconnect the client. => Smack should ignore it.
Daniel can explain that better. Probably it’s a bug both in Openfire and Smack.
I have just created a ticket for it SMACK-243, so it won’t be missed.
wroot wrote:
Anyway, please test that with next version of Openfire and then report back.
I have tested this with 3.5.2 version of Openfire and it wasnt fixed, so Daniels fixes were about something else.
Hello ,
is Anybody working this critical bug or any plans for fixing , we facing lots of issues due to this bug already faced downtimes.Looks smack is not able handle certain kinds of well-formed, but otherwise defective XML packets http://www.igniterealtime.org/issues/browse/SMACK-232 to which this bug is related http://www.igniterealtime.org/issues/browse/SMACK-243 . it also look this maybe exeption maybe caused by java date parsing bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5087246
I request some one for Jive /Sr member of community to have a look at this and release a emergency patch
if there no plans to fix soon then please let us know , we will migrate to other libraries like echomine and/or in meantime try to fix it ourselfs which might take some time
As assignee of SMACK-243 has just changed, i suppose there should be some work done on this soon.
Hi!
I have the same (i think) problem, byt when i send file from beetwen JBother and my program.
What is strange, that JBrother also is using smack ( I heard).
java.text.ParseException: Unparseable date: "2008-12-17T09:51:09Z"
at java.text.DateFormat.parse(Unknown Source)
at org.jivesoftware.smackx.provider.StreamInitiationProvider.parseIQ(StreamInitiat ionProvider.java:96)
at org.jivesoftware.smack.PacketReader.parseIQ(PacketReader.java:597)
at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:275)
at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:44)
at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:76)
I know that this bug was noticed (SMACK-243) but I just want to mention that my date format is a little bit different than that in bug
I’m getting the original problem
Unparseable date: “200911T2:48:11”
ever since the new year for one of our users but just for one… I dont get why is google sending proper data for all others, including me that are in new year already. Can it be actually client problem on the other side sending nonsense? After I added override check it was just one that got into that place…
Anyway, I hacked source of DelayInformationProvider directly because we already had 2 hrs downtime due to this. Not sure whats the proper way to solve the problem… cause if the format goes like this how would you know
2009111 as jan/11 or nov/1st? I guess I need to find the real docs about what google can send… any clues/links/info?
One way or the other, the fact that packet error is killing the client is just atocious… I guess I’ll have to change it myself again…
Proper ticket link http://www.igniterealtime.org/issues/browse/SMACK-243
Strange, but this critical issue is not getting an attention.