tigase + spark client = invalid username or password

Ok, I found my old email I was exchanging with a user having the same exact problem, let me copy and paste the content of my last email with my investigation results:

I have spent a few hours trying to track it down.
It looks like smack can not connect to the server on localhost and
it is kind of timing problem in smack in my opinion.
Wether the issue is especially apparent on dual-core or dual-cpu
machines or just very fast machines? I am not sure.

Tigase sends response very quickly even before smack starts
to read the stream so even though the correct response is sent
smack doesn't notice this.

If you try to connect to the server on different host network
latency hides the problem hence you can connect to any server
on the internet including Tigase on tigase.org for example.

Interesting things is that Jive guys are aware of the problem
and tried to solve it. If you look in:
sources/org/jivesoftware/smack/PacketReader.java file, line 153
and below you can see comments about this.
As you can see their solution still doesn't work for some cases and
looking in smack code this is more design issue rather then small
bug in single class. They implemented synchronous communication
during loging time which is not good approach in my opinion.

Hm, I have tried to use libraries from the current Sparc client, still can not replicate the problem.

I will try again later on and will post result if I find anything interesting.

don't know where I've seen it is one year old... it is only 2 months old.

I am using the latest version but this version is more than one year old. maybe the bug is not solved in the client.

Hm, I can not replicate the problem now with the Smack library downloaded from their website. Maybe it is already fixed?

Can you check what Smack version do you use in your client now? Is it happening on the last version of the client? I can download the client and test with it directly.

if you can find it easily, it would be great but don't bother with this if it takes too long. I will take some of my own time for this.

Unfortunately increasing timeout can't help because the response arrives before client starts listening. I wonder why disabling sasl helps. And from your next post it looks like it happens also in different situations than I saw it before.

Anyway it is all timing problem and and in different environments the timings might be different thus results are different.

I could show you even the exact place in the library code causing this problem. Unfortunately I have removed all the files when I finished debugging it last time. I could dig it again if you are really interested in it.

yes it looks like what you are describing but I have the problem only using a distant server.
running the server locally on my dual core laptop, it works well.

note :
I just disabled sasl commenting <item value="urn%3Aietf%3Aparams%3Axml%3Ans%3Axmpp-sasl"/> and it works.

also, spark has a timeout parameter. I increased it to 30 seconds and still same problem but the delay between the bind and the reply is 30 seconds in sparks logs.
looks like the problem is in spark.

Ah, in such case I know what is going on. At least I think I know.

This is the case I was investigating some time ago already in the XMPP library used by Sparc.
The library sends request to the server and then starts listening for response. The funny thing is that Tigase responds quite quickly, the response is sent before the client starts listening for response.

As a result response arrives and then client starts listening for it. It is waiting until timeout expires and then signals error. What is even worse the error message is very confusing because it doesn't say what really happened.

It happens usually on localhost if you have dual-core machine or on LAN if you have very fast network and the machine with Tigase installed also a fast box.

There should be a discussion on this forum on the exact same topic already. I am not sure if the problem is already solved in the most recent library/sparc version.

that's strange cause I installed tigase locally and I can connect to the server using spark...
also another strange thing is that when I try to connect to the remote server, the debug from spark have a 10 seconds delay between the display of

<iq id="AYqMg-0" type="set"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><resource>x</resource></bind></iq>

and the display of
<iq type="result" id="AYqMg-0"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>test@xxx.xxx.xxx.xxx/x</jid></bind></iq>

while tigase logs say it replied quickly. (spark says invalid username/password just after displaying the bind result)

I will try to investigate more getting some network traffic dump to check what is the problem but maybe it is not a tigase or spark problem.

thanks for your help.

From the log file and the XML output you send me earlier everything looks perfectly correct on both server and client side.

I have no idea why you are getting "invalid username or password" message. This is especially weird as the authentication process completes successfully.

I wonder when you are getting the error message? You said that there is still connection established and there is some activity on the connection every 30 seconds. Is this connection still active after you received the error message?

Could you find out after which XML packet from the server the error message is displayed?

if you need the complete logs, tell me I will send them.
thanks for your help

this is the logs from the server :

2007-11-08 13:36:56 ClientConnectionManager.processPacket() FINER: Processing packet: iq, type: result
2007-11-08 13:36:56 ClientConnectionManager.processPacket() FINEST: Processing packet: <iq type="result" id="W92hr-0"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>test@xxx.xxx.xxx.xxx/x</jid></bind></iq>
2007-11-08 13:36:56 ConnectionManager.writePacketToSocket() FINER: Processing packet: iq, type: result
2007-11-08 13:36:56 ConnectionManager.writePacketToSocket() FINEST: Writing packet to: c2s@xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx_5222_yyy.yyy.yyy.yyy_39522
2007-11-08 13:36:56 XMPPIOService.processWaitingPackets() FINER: Processing packet: iq, type: result
2007-11-08 13:36:56 XMPPIOService.processWaitingPackets() FINEST: Sending packet: <iq type="result" id="W92hr-0"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>test@xxx.xxx.xxx.xxx/x</jid></bind></iq>
2007-11-08 13:36:56 TLSIO.write() FINER: TLS - Writing data, remaining: 120
2007-11-08 13:36:56 TLSWrapper.wrap() FINEST: wrap()
tlsEngineRsult.getStatus() = OK
tlsEngineRsult.getHandshakeStatus() = NOT_HANDSHAKING
2007-11-08 13:36:56 SocketIO.write() FINER: Wrote to channel 141 bytes.

-------

and then every 30 seconds, I have this :

2007-11-08 13:37:41 SocketReadThread$ResultsListener.run() FINEST: COMPLETED: xxx.xxx.xxx.xxx_5222_yyy.yyy.yyy.yyy_39522
2007-11-08 13:37:41 SocketReadThread.addAllWaiting() FINEST: ADDED: xxx.xxx.xxx.xxx_5222_yyy.yyy.yyy.yyy_39522
2007-11-08 13:38:11 SocketReadThread.run() FINEST: AWAKEN: xxx.xxx.xxx.xxx_5222_yyy.yyy.yyy.yyy_39522
2007-11-08 13:38:11 SocketIO.read() FINER: Read from channel 22 bytes.
2007-11-08 13:38:11 TLSIO.read() FINER: Read bytes: 22
2007-11-08 13:38:11 TLSIO.decodeData() FINER: Decoding data: 22
2007-11-08 13:38:11 TLSWrapper.unwrap() FINEST: unwrap()
tlsEngineRsult.getStatus() = OK
tlsEngineRsult.getHandshakeStatus() = NOT_HANDSHAKING
2007-11-08 13:38:11 XMPPIOService.processSocketData() FINEST: READ:

on the client, the port is still opened :
# netstat -anp|grep 39522
tcp6 0 0 ::ffff:192.168.0.:39522 ::ffff:217.19.51.9:5222 ESTABLISHED24685/java

I will get you logs. I am also trying to install the openfire server developped by the same people to see what are the differences.
thanks.

Hi,

This is very strange what you say because from the XML data content you put above there is no place where "invalid username or password" message is sent or might be generated.

Whole authentication process completed correctly until session bind.
So everything looks good. When do you receive the error message? Maybe during roster retrieving?

If you do your tests on localhost only (both Tigase server and Sparc client run on the same machine) then there is a known problem with Sparc. Tigase response is sometimes sent too quickly when the client is not ready to receive it yet.

Have you tried different client? Please try to do the same with Psi or any other client to see if you get the same problem.

In any case to help you to diagnose the problem I might need to see your configuration file and tigase log files with debuging switched on.
You can send me all those files compressed to my private email: kobit <ON> tigase.org.