Teamspeak Client Ports

[ttleser]

What UDP/TCP port does the client version use?

Currently I'm using 2 computers behind a Linksys BEFSR41 router and both are running windows XP pro. Since it's XP Pro it's already got directx 8.1 installed (default to O.S.) and both can connect to the server, no problem. The problem comes in after a period of time one of the PCs doesn't recieve/send thru teamspeak anymore. It still shows it's got a connection to the server, it's just not broadcasting or receiving transmissions. If I disconnect/reconnect the transmissions will come back. But after a peroid of time again it will not transmit/recieve. Teamspeak even vocally tells me when I disconnect/reconnect so I know my sound isn't gone..

The other PC worked great. No problems when both are hooked up to the same server.

I was thinking that if I could setup teamspeak client on one of the PCs to send/recieve thru port xxxx, and setup the router to forward requests to that port of that Internal IP of that computer, that might solve my problem. What's your thoughts?

Both PCs will work fine, if used separately by themselves to the same server.

[DjAttitude]

TCP 8765
UDP 8766

hope that helps

[ttleser]

Well actually it does answer my question.

But are the ports changeable?? I'd like to set one PC to one set of ports and the other PC to a different set.

And aren't those ports you listed for the server?

[T. Boonstra]

Those are the ports the server listens for, the client uses random source port (sorry forgot the range)

However the problem you speek of sounds like an "timeout" problem caused by your router.. Check the Server forums and see if some of those suggestions help..

[ttleser]

Not to cause an argument. But....

The OTHER pc has not had this problem. Even the problem pc doesn't have the problem, except when both are connected. It could be a timeout problem, but I haven't configured teamspeak to use any other port than the default.

[Quote] Those are the ports the server listens for, the client uses random source port (sorry forgot the range) [Quote]

The client truly uses random ports? How would I know what ports to go into the router and "extend" the time for?

Anyone with exact information about what ports are used would be great.



Ok, now for the plug!

My group of guys that play Black Knight regularly love the program. It's great. Can't wait for ver 2.0

[T. Boonstra]

The other pc doesn't have a problem with it?.. odd.. well guess i don't know then

Could it be the windows XP firewall is causing problems (if its enabled)

[ttleser]

It's not enabled. Any other thoughts??

Are the ports hard coded into the program or in a file or registry entry.

Thanks ahead.

[T. Boonstra]

Like i said, the client uses random ports to connect/transmit

As for the server, no you can specify which port to use in the ini file..

[ttleser]

Well by your comments:

[Quote]: Those are the ports the server listens for, the client uses random source port (sorry forgot the range) [Quote]

I took it that you were unsure and couldn't remember.

Any chance that ver 2.0 youwill be able to specify the ports. That would be really helpful to someone using 2 pcs behind a router/firewall.

Thanks

[SLI Fallen]

Ttleser. I am experiencing the EXACT same problem as you, and with the same router.

I too, would like some kind of workaround, et. My firmware is up to date.

[Theo]

Hey I got same problems with Disconnections with Same Linksys router... The only way to get it to work is to turn DMZ on for the IP of the PC that is running TS. The reason DMZ works is because TS Client randomly changes PORTS so PORT Forwarding will not work because the ports are constanlty changing...

FIX. Turn DMZ on for the specified IP prior to using TS then turn DMZ off after done using TS.

CAUTION: You dont want to leave DMZ constantly on.. this leaves the PC that is DMZ completely open to the outside world..

Hopefully TS v2.0 uses a fixed range of ports.. as oppossed to random ports.

NOTE: DMZ = Demilitiarized Zone.

Theo.........

[ttleser]

That would work for one PC, but what about the other? I could DMZ the non-working PC but would that cause the working to fail???

Don't forget that I've got 2 pcs behind the firewall/router and want both to talk to the same server in the internet w/out problems.


Thanks for the suggestion though

[Theo]

Well I would try to leave the PC that is working alone... And Just enable DMZ on the PC thats is giving ya problems.. If it works great.. But there should be no reason why one works and the other doesn't unless you specified different settings for each IP?......

If it doesn't work then you will have to wait for v2.0 which is supposed to fix this issue..

BTW why you using 2 different PC's on same server? Multiple users in that location? Surrond Sound LOL?


Later,
Theo

[ttleser]

No actually, I have 2 PCs in different locations in the house. Mine and my wifes. When my friends get together to play a campaign you've got setup in Mechwarrior4, both my wife and I connect to a served teamspeak out in the internet. Her computer's got a all-in-wonder vid card, so I've got it hooked up to a VCR. I'll play the game using my mech and she'll join in camera mode. With both of us using teamspeak (along with my buds), the VCR can tape video as well as the "commands" given to everyone by the commander.

Unfortunetly, we've come across this problem (only recently was I able get the other PC to join the MW4 game along with mine) and my wife will have to disconnect and reconnect to cure the problem (till it happens again).

[ScratchMonkey]

The random source port thing is a normal part of UDP protocol. Locking the source port to a specific value is usually provided only to deal with router bugs (which is what you seem to be experiencing).

Ideally you should find new firmware for your router that allows you to extend the UDP timeouts, presumably to twice the longest session you can imagine having.

Have you tried the patched client? I believe it "pings" with UDP to hold the connection open and keep the router from timing it out, but some routers can be agressively buggy about dropping a UDP connection even when traffic is flowing, based on time from when the first packet was seen instead of time from the last packet.