Home » Forums » Kraken Support » Transports (AIM, ICQ, MSN, etc)

ICQ gateway problems with Trillian contacts

Submitted by sven.borkert on Sat, 01/16/2010 - 04:16

Hi,

some time ago I noticed that people with Trillian Astra sending me messages containing german Umlaute like öüä break my whole connection with the server. I have taken a closer look at this and could implement a fix that works for me.

I took a look at the hexvalues of incoming messages from Trillian Astra and other clients, and I notices that Trillian Astra sends a 0x00 byte as line termination after a line containing certain characters:

 


2010.01.15 16:51:49 net.sf.kraken.protocols.oscar.BasicFlapConnection -> OSCAR snac packet received: SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=22, requests: 20, paused=false, snacPacket=SnacPacket type 0x4/0x7: 169 bytes (id=2275699057), snacCommand=RecvImIcbm: message from UserInfo for 562787740: flags=0x51 (MASK_FREE | MASK_UNCONFIRMED | 0x40), ICQ status=, memberSince=Fri Jan 15 14:24:01 CET 2010, sessLenAim=4min, onSince=Fri Jan 15 16:47:44 CET 2010, extraInfos=[ExtraInfoBlock: type=0x1 (TYPE_ICONHASH), extraData=<ExtraInfoData: flags=0x1 (FLAG_HASH_PRESENT), data=1e a5 df 66 cc 57 b8 49 7b 3e 68 f5 0f 71 30 75>], extraTlvs=[TLV: type=0x8, length=2, ascii value="
", ushort value=2566: 0a 06, TLV: type=0x29, length=4, uint value=1263562219: 4b 50 6d eb]: IM: aaaaaööööööaaaaaaaa - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=24, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x4/0x7: 169 bytes (id=2275699057), flapPacket=FlapPacket (channel=2, seq=63277)
2010.01.15 16:51:49 net.sf.kraken.BaseTransport -> icq: Sending packet: <message type="chat" from="562787740@icq.jabber80.ath.cx" to="borkert@jabber80.ath.cx"><body>aaaaaööööööaaaaaaaa&#0;</body><x xmlns="jabber:x:event"><composing/></x><active xmlns="http://jabber.org/protocol/chatstates"/></message>

 

You can see the the message content "aaaaaööööööaaaaaaaa" in the log output from handleSnacPacket in BasicFlapConnection, but you don't see the 0-byte here. I added some debug code here to take a look at the hex values:

            Log.debug("MESSAGE1: "+stringToHex(message.getMessage()));
            String msg = StringUtils.convertFromHtml(message.getMessage());

 

2010.01.16 09:44:24 net.sf.kraken.protocols.oscar.BasicFlapConnection -> MESSAGE1: f6 f6 f6 0

 

This was where I sent a message "ööö", you see the f6, but there is an additional 0-byte.

As you can see in the log output I posted first, the 0-byte gets encoded into the jabber message that goes out to the client:

<message type="chat" from="562787740@icq.jabber80.ath.cx" to="borkert@jabber80.ath.cx"><body>aaaaaööööööaaaaaaaa&#0;</body><x xmlns="jabber:x:event"><composing/></x><active xmlns="http://jabber.org/protocol/chatstates"/></message>

 

I can see this message arriving at my client, then the client disconnects. Piding reports an XML parsing errror, other clients just go offline. I reproduced this with Pidgin, Adium, Gajim, and its always the same. It looks to me like the client just goes offline after receiving a message with such content, I don't see any serverside errors:


2010.01.15 16:51:49 net.sf.kraken.protocols.oscar.BasicFlapConnection -> OSCAR snac packet received: SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=22, requests: 20, paused=false, snacPacket=SnacPacket type 0x4/0x7: 169 bytes (id=2275699057), snacCommand=RecvImIcbm: message from UserInfo for 562787740: flags=0x51 (MASK_FREE | MASK_UNCONFIRMED | 0x40), ICQ status=, memberSince=Fri Jan 15 14:24:01 CET 2010, sessLenAim=4min, onSince=Fri Jan 15 16:47:44 CET 2010, extraInfos=[ExtraInfoBlock: type=0x1 (TYPE_ICONHASH), extraData=<ExtraInfoData: flags=0x1 (FLAG_HASH_PRESENT), data=1e a5 df 66 cc 57 b8 49 7b 3e 68 f5 0f 71 30 75>], extraTlvs=[TLV: type=0x8, length=2, ascii value="
", ushort value=2566: 0a 06, TLV: type=0x29, length=4, uint value=1263562219: 4b 50 6d eb]: IM: aaaaaööööööaaaaaaaa - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=24, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x4/0x7: 169 bytes (id=2275699057), flapPacket=FlapPacket (channel=2, seq=63277)
2010.01.15 16:51:49 net.sf.kraken.BaseTransport -> icq: Sending packet: <message type="chat" from="562787740@icq.jabber80.ath.cx" to="borkert@jabber80.ath.cx"><body>aaaaaööööööaaaaaaaa&#0;</body><x xmlns="jabber:x:event"><composing/></x><active xmlns="http://jabber.org/protocol/chatstates"/></message>
2010.01.15 16:51:49 011228 (01/03/00) - Connection #12 tested: OK
2010.01.15 16:51:49 011229 (01/03/00) - Connection #12 tested: OK
2010.01.15 16:51:49 net.sf.kraken.BaseTransport -> Received presence packet: <presence type="unavailable" from="borkert@jabber80.ath.cx/9fae2f88" to="icq.jabber80.ath.cx"/>
2010.01.15 16:51:49 011229 (01/03/00) - Connection #13 tested: OK
2010.01.15 16:51:49 011230 (01/03/00) - Connection #13 tested: OK
2010.01.15 16:51:49 011230 (01/03/00) - Connection #10 tested: OK
2010.01.15 16:51:49 011231 (01/03/00) - Connection #10 tested: OK
2010.01.15 16:51:49 net.sf.kraken.BaseTransport -> A final resource has gone offline: borkert@jabber80.ath.cx/9fae2f88
2010.01.15 16:51:49 net.sf.kraken.protocols.oscar.BOSConnection -> OSCAR bos service state change from CONNECTED to NOT_CONNECTED Reason: ON_PURPOSE
2010.01.15 16:51:49 net.sf.kraken.protocols.oscar.ServiceConnection -> OSCAR service state change from CONNECTED to NOT_CONNECTED
2010.01.15 16:51:49 net.sf.kraken.protocols.oscar.OSCARSession -> OSCAR service died: ClientFlapConn: flapProcessor=null
2010.01.15 16:51:49 net.sf.kraken.session.TransportSession -> Disconnecting session borkert@jabber80.ath.cx from icq.jabber80.ath.cx

 

To prevent this error, I now do filter 0-bytes from the message body in the handleSnacPacket method. I don't think this is the best place to fix this problem. I don't know the real reason why the client disconnects, but if such encoded bytes are not allowed in XMPP messages, then I should now be able to put them inside, or they should be replaced/removed somewhere in the XMPP protocol code. But for now this little fix prevents repeated disconnects when talking to Trillian users.

Edit: I did some more tests. I can force most clients to reconnect by sending a XMPP message containing a &#0; in the body. I did checks with other XMPP servers and noticed that some servers discard such messages. I don't think it's a good idea to discard messages without any notice, the 0-byte should be removed, and I think this should be done somewhere in the Openfire code. I'll post this question in the Openfire forum.

 

 

‹ Setting status to busy in GTalk Newbie Question: Is there a stable version available? ›
#1Submitted by sven.borkert on Wed, 01/20/2010 - 11:25.

Re: ICQ gateway problems with Trillian contacts

Fixed in Version 1.1.3:

http://jira.blathersource.org/browse/KR-139