I’m self-hosting a TeamSpeak 6 server and I’m trying to understand something I noticed while I thought I was troubleshooting a connection delay.
From what I understand from the TeamSpeak 6 self-hosting documentation, the server uses UDP port 9987 for the main voice connection.
However, when I connect to my server using its hostname,after lots of trying to figure out why there was about a 5 second delay and after some packet capature, I noticed that the TeamSpeak 6 client first attempts to connect to TCP port 41144, and only afterward connects to UDP 9987.
I’m trying to understand why this happens rather than necessarily fix it.
My questions
- What is TCP port 41144 used for in TeamSpeak 6?
- Why does the TS6 client attempt to contact port 41144 when connecting by hostname?
- What information or service is the client looking for there?
- Why does it try 41144 before connecting to the actual server on UDP 9987?
- Is 41144 part of the TeamSpeak 6 server itself, or is it related to some other discovery/resolution mechanism?
- If the self-hosted TS6 server’s main connection is UDP 9987, what is the purpose of having the client try 41144 first?
- Is this expected behavior for the TeamSpeak 6 client?
I’m fairly new to networking and self-hosting, so I’m probably missing some background here. I’m mainly trying to understand what this mechanism is for and why it exists, rather than assuming it’s a problem.
Thanks!
Check this out.
41144 is the TSDNS port. It is used as part of the domain name lookup system TeamSpeak uses. It is essentially their own very specific DNS server just for TeamSpeak servers. I assume this was originally developed for hosting providers. But honestly I never really understood the use case. Anyways, this should not add a lot of latency to the connection initialization.
The only thing I can think of is that the request is silently dropped on the way somewhere instead of actively refused, the client my wait for a timeout.
If I’m not using TSDNS and my server is using normal DNS to UDP 9987, is there a recommended way to tell the TS6 client that TSDNS isn’t being used, so it doesn’t spend several seconds attempting TCP 41144 first?
One detail that might be relevant for the devs if they also look at this: the laptop I was using was freshly/recently reimaged with CachyOS, and I had just installed TS6 today. So this was a completely fresh TS6 client installation.
That’s part of why I found the behavior interesting. I was trying to reproduce what a completely new external user (a few friends I’d like to have try out TS6 after the next Foundation update) would experience, rather than testing an existing TS6 setup.
Given that, I’m curious whether the TSDNS lookup on port 41144 is expected for a fresh TS6 client connecting to a normal hostname, and whether there is a recommended way for a self-hosted server that isn’t using TSDNS to avoid that lookup or to integrate it so there is a more instant connection like when using the direct IPv4 or 6 address.
TSDNS is always tried as part the the domain lookup process in TeamSpeak. This much is expected.
In your case I assume your router has a mode that some sort of setting like “silently drop incoming traffic”. But the wording or even the specific settings highly depend on your router model. In practice you want to make sure that all packets to port 41144 are rejected and not blocked - even more specifically, you want to send RST packets in response to client SYN packets.
You can test this with
nc -vz <ip> 41144
You want to see
nc: connect to <ip> port 41144 (tcp) failed: Connection refused
That did the trick. Following your suggestion, I checked the firewall handling of 41144 and found that it was hitting the default silent-drop behavior. I added an explicit reject rule instead, and the 5 second delay went away. The client now receives the RST almost immediately and proceeds to 9987.
For anyone else seeing the same delay, check how your firewall/router handles 41144. It doesn’t need to be opened, but explicitly rejecting it rather than silently dropping it avoids the timeout.