About timeout at connection time

[desolidirized]

While going through the forums I see plenty of people have quite the same problem as I'm encountering.
A short analysis shows that the client is disconnected after sucessful login (entry in the log file as connected, accesses granted, etc.)
Where it becomes funny is when analysing the detailed packet flow.
A sucessful connection looks like :
19:18:41.918555 IP 212.76.251.93.60732 > 172.16.1.12.8767: UDP, length: 180
19:18:41.919371 IP 172.16.1.12.8767 > 212.76.251.93.60732: UDP, length: 436
19:18:42.014915 IP 212.76.251.93.60732 > 172.16.1.12.8767: UDP, length: 120
19:18:42.015257 IP 172.16.1.12.8767 > 212.76.251.93.60732: UDP, length: 16

in more understandable terms
client -> server (username,password, nickname, os..)
server -> client (ack, parameters ...)
client -> server (ack , ... 120 bytes ...)
server -> client (ack, channels, ..)

A failed connection :
19:17:56.989365 IP 81.188.70.106.62021 > 172.16.1.12.8767: UDP, length: 180
19:17:56.989732 IP 172.16.1.12.8767 > 81.188.70.106.62021: UDP, length: 436
19:17:57.186763 IP 81.188.70.106.62021 > 172.16.1.12.8767: UDP, length: 120
19:17:57.346628 IP 81.188.70.106.62021 > 172.16.1.12.8767: UDP, length: 120
19:17:57.468099 IP 81.188.70.106.62021 > 172.16.1.12.8767: UDP, length: 120
19:17:57.589881 IP 81.188.70.106.62021 > 172.16.1.12.8767: UDP, length: 120
19:17:57.708648 IP 81.188.70.106.62021 > 172.16.1.12.8767: UDP, length: 120

The server doesn't send anything after the initial packet. (trace taken on the server itself) . Why? :confused:


about versions : client : 2.0.32.60 | Server : 2.0.20.1 / reported v2.0.r20.b1 in web interface...
hereafter the log of failed and successful connections and the server.ini contents (ade is the user with trouble connecting...)

---------------------------------------------------------------
-------------- log started at 09-05-05 19:53 -------------
---------------------------------------------------------------
09-05-05 19:53:57,ALL,Info,server, Server init initialized
09-05-05 19:53:57,ALL,Info,server, Server version: 2.0.20.1 Linux
09-05-05 19:53:57,ALL,Info,server, Starting VirtualServer id:1 with port:8767
09-05-05 19:53:59,ALL,Info,server, Server init finished
09-05-05 19:53:59,WARNING,Info,server, TeamSpeak Server daemon activated
09-05-05 19:54:02,ALL,Info,AccessLog, SID: 1 client connected [IP: 212.76.251.93, Nick: desolidirized, LoginName: alain, DBID: 3, Version: 2.0.32.60]
09-05-05 19:54:02,ALL,Info,SALog, SID: 1 serveradmin connected [IP: 212.76.251.93, Nick: desolidirized, LoginName: alain]
09-05-05 19:54:25,ALL,Info,AccessLog, SID: 1 client connected [IP: 81.188.70.106, Nick: Ade, Version: 2.0.32.60]
09-05-05 19:54:27,ALL,Info,AccessLog, SID: 1 client disconnected. [Nick: Ade]
09-05-05 19:55:04,ALL,Info,AccessLog, SID: 1 client disconnected, reason LoginName in use [IP: 81.188.70.106, Nick: Ade, LoginName: alain, Version: 2.0.32.60]
09-05-05 19:56:14,ALL,Info,AccessLog, SID: 1 client connected [IP: 81.188.70.106, Nick: Ade, LoginName: ade, DBID: 4, Version: 2.0.32.60]
09-05-05 19:56:16,ALL,Info,AccessLog, SID: 1 client disconnected. [Nick: Ade, LoginName: ade, DBID: 4]
09-05-05 19:56:16,ALL,Info,SALog, SID: 1 serveradmin disconnected [Nick: Ade, LoginName: ade]
09-05-05 19:57:10,ALL,Info,AccessLog, SID: 1 client disconnected. [Nick: desolidirized, LoginName: alain, DBID: 3]
09-05-05 19:57:10,ALL,Info,SALog, SID: 1 serveradmin disconnected [Nick: desolidirized, LoginName: alain]
09-05-05 19:57:11,ALL,Info,AccessLog, SID: 1 client connected [IP: 212.76.251.93, Nick: desolidirized, LoginName: alain, DBID: 3, Version: 2.0.32.60]
09-05-05 19:57:11,ALL,Info,SALog, SID: 1 serveradmin connected [IP: 212.76.251.93, Nick: desolidirized, LoginName: alain]
09-05-05 19:58:07,ALL,Info,AccessLog, SID: 1 client connected [IP: 81.188.70.106, Nick: Ade, Version: 2.0.32.60]
09-05-05 19:58:09,ALL,Info,AccessLog, SID: 1 client disconnected. [Nick: Ade]
09-05-05 19:58:20,ALL,Info,AccessLog, SID: 1 client connected [IP: 81.188.70.106, Nick: Ade, Version: 2.0.32.60]
09-05-05 19:58:22,ALL,Info,AccessLog, SID: 1 client disconnected. [Nick: Ade]
09-05-05 19:58:32,ALL,Info,AccessLog, SID: 1 client connected [IP: 81.188.70.106, Nick: Ade, Version: 2.0.32.60]
09-05-05 19:58:34,ALL,Info,AccessLog, SID: 1 client disconnected. [Nick: Ade]



[Main Config]
ExternalIPDectection=0
HTTPServer Port=14534
HTTPServer Enabled=1
DateTimeFormat=dd-mm-yyyy hh:nn:ss
TCPQueryPort=51234
AllowedClientNameChars=
DisAllowedClientNameChars=()[]{}
BoundToIp1=

[debug]
MessageTypes=LMTALL
MessageDepths=LMDALL

[WebPost]
AdminEmail=desolidirized********.com
ISPLinkURL=http://desolidirized.deviantart.com
ISPName=Private
ISPCountryNumber=4415
Enabled=0
PostURL=
ListPublic=0
UserAgent=teamspeak

[log]
access_r=1
access_u=1
channel_registerred=1
channel_unregisterred=1
sa=1
chat=1
kick_server=1
kick_channel=1

[Spam]
max_commands=10
in_seconds=2


hope it helps...

[guldi]

Seems like the actual client version 32.60 is a bit more timeout sensitive than the older version was.
Have you tested what's posted in the timeout FAQ thread (debug mode) ?

If that doesn't help you could try the client before 32.60

[desolidirized]

I did try the 'enable debug' on the client tweak, no success.
Well I really don't understand why the server doesn't send its second packet.
If I use a wrong username/password it correctly sends the NACK.
I would understand the (client) problem if that second packet was loss in transit, but sniffing took place on the server itself.
Indeed the client goes timeout becase of that never sent packet, but I think the issue really lies in that precise packet not being sent out for whatever reason. I could put some additional debugging on if you want or some trace on system functions if you'd think it useful. What method do you use for crafting packets? Standard sockets or direct access and manual packet crafting?
I don't see any counter saying the IP stack might have stopped that packet to go out but I may need to turn on additional debugging flags on the kernel to allow that.
Let me know if you want me to gather more debug/analysis/tests
I'll anyway try and install an older version of teamspeak client and let you know the whereabouts.

[desolidirized]

Just checked a bit further... Ethereal reports an UDP header checksum error at the output of the server interface for the 1st packet being sent to the client.. However, that packet reaches the client all right, with a corrected checksum (because of NAT).. I can't figure out if it has anything to do with the problem... I'll check a working connection to verify whether that checksum error occurs in that case as well or not. Stay tuned...

[desolidirized]

All right. been doing some more detailed analysis. the first packet sent to the client indeed has both IP and UDP checksum erroneous. That is specific to Linux. indeed, when doing the attempt on a windows machine, users still can't connect (and the second server packet is never sent) but the checksums are reported correct. By placing the server directly on the public IP address, removing NAT devices, everything is fine. There seems to be some packet mangling involved there. It's not easy to figure out, though. I have detailed ethereal traces but although the packet format seems rather well structured, reverse-engineering it will take some time, so I'd be glad to get a bit of help :rolleyes: