Teamspeak

[Joemama]

Hey, anyone know if there is any way to tell SEQ 5 not to look at the Teamspeak packets traveling to the system as well?

When I have EQ and Teamspeak going, and I look over at SEQ, it's running dog slow, because in the terminal windows I see it trying to decode every Teamspeak packet going to and from my system. With about 30 people in teamspeak, that's a lot of packets=P


Is there a way I can tell SEQ not to pay attention to port 8767 and such?

[Cryonic]

Session Tracking

[Joemama]

Hey, I piddled around with it for a while, and found out I have to do things in a certain order, but that seems to work, thanks =)

[Pascal7]

Just curious...
What order did you have to do them in?

My guild uses a similar program, but I'm tempted to run it either on my LINUX box or my other PC, but not on my EQ machine just to avoid the above problems.

[LordCrush]

Originally posted by Pascal7
Just curious...
What order did you have to do them in?

My guild uses a similar program, but I'm tempted to run it either on my LINUX box or my other PC, but not on my EQ machine just to avoid the above problems.

<---- Curious too :D :D :D :D :D

[workhorse]

I use TeamSpeak also with the same problems. Im curious as to what you are doing different Joemama

[workhorse]

Any word on what you did?

[fester]

I could not use session tracking, so I changed the pcap filter to add "and not port x" where x is the teamspeak port number. Crude fix, but I was lazy that night.

[Cryonic]

What do you mean you couldn't use Session Tracking?

[fester]

Maybe I am confused Cryonic.

I 2 box, I run 2 showeq at once, I have 2 pc's with eq, and I zone them at the same time. I have 4 other EQ sessions potentially running from other people visible from the showeq linux system.

Can I run session tracking? To be honest, I have never tried. I was under the impression there would be issues if you had more than one eq session visible, especially if they zoned at the same time.

[Cryonic]

Session Tracking is to help SEQ lock onto a single instance of a client when specifically two boxing (running 2 accounts on 1 system). Without Session Tracking you can two box from multiple systems without any issues, just not from the same system.

So, in your example of having up to 4 sessions visible, without session tracking you would run those from 4 different computers and SEQ would never get confused or lock onto any other client than the one it first saw or was specifically told to watch (by IP address, MAC address or just using Monitor Next Client seen and then zoning).

When running two clients from the same system, SEQ can't normally differentiate from them and so will decode both data streams...

This is what Session Tracking is for. With it turned on, it locks onto the first client it sees and (in my experience) sticks to just it with the exception of using a porter on the second session and casting a port spell, then SEQ seems to sometimes lock onto the other session...

[workhorse]

So, if I were to load up SEQ, click session tracking, log into EQ, and THEN log into Teamspeak I should be ok?

Im at work now.

[workhorse]

I think I figured this out for those still wondering.

I did these steps in this order and SEQ ignored the Teamspeak packets:

1. Load SEQ and click "Monitor Next EQ Client Seen" and "Session Tracking"
2. Load EverQuest
3. Alt+Tab out and Load Teamspeak

I was using a fixed IP for SEQ and it would scan everything. When I switched to "Next EQ Client Seen" it ignored all the Teamspeak packets.

I hope this helps!

[fester]

Session Tracking does work. I have a new problem, it sometimes "locks" on "Busy Zoning" when I zone multiple characters (from different IP addresses) and I must zone again to clear this issue.

[Backspace]

I could not use session tracking, so I changed the pcap filter to add "and not port x" where x is the teamspeak port number. Crude fix, but I was lazy that night.
I like your solution, but don't know how it's done. Is this a simple thing to post or can you reference a how-to?

[UnGod]

The pcap filters are created in 'packetcapture.cpp'.
Search for 'udp[' (there are 9 instances that have to be updated)

The lines will all look something like the following:

sprintf (filter_buf, "udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x800");

Modify them and add 'and port !<port>' to the end like so:

sprintf (filter_buf, "udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x800 and port !27015");

(Note: The example above is for Half-Life traffic)

[workhorse]

Im having a hard time figuring out what the actual port is. Here is the error string a receive while using Teamspeak. I have edited the packetcapture.cpp file for port 1403 first, then i changed it to 8767 when I was still receiving the error:


Warning: INVALID PACKET: Bad CRC32 [xxx.xxx.x.x:1403 -> xx.xx.xxx.xx:8767] seq 0100 len 20 crc32 (5857460d != 8b93b9de)
Warning: INVALID PACKET: Bad CRC32 [xx.xx.xxx.xx:8767 -> xxx.xxx.x.x:1403] seq 0200 len 24 crc32 (1c020000 != ac5a4070)

:8767 is our Teamspeak server port
:1403 is the SEQ box port

Note: Ive X'ed out the IP's to protect the innocent!

It seems I should be using 1403 when I edit, but It didnt work. Thoughts?

[workhorse]

After further investigation I figured out my problem. I used the correct port, but I didn't realize I had to "make install" after the edit.

So, I ran make install and everything is peachy again!

Thanks for your help friends.

[pita]

Just a shot in the dark, but here are a couple of possible methods for dealing with teamspeak, and other software such as p2p filesharing apps

Scan the source/destination of the packet, to see if its coming from an EQ server.

Create a text file with known ports that should be ignored always

I haven't programmed in several years. I had a look at the packetcapture.cpp file, and it made my head hurt. Also made me try to remember where my old C programming books were.

Anyone think this is feasible?

pita

[workhorse]

More problems. For some reason Teamspeak uses a different port every time its re-opened. So you'd have to edit the .cpp file and make install every time.

No thanks! Any ideas on how to make Teamspeak use a static IP?

[UnGod]

What ports change?
Does both the server and client address change?
I have never used teamspeak myself, so do not know exactally how it works.
I would assume that it's got a server, running on a static port for communication?
Or is it like IM clients that just connect directly to another person?

If it has a central server (for your group even), you can just filter the port that it is on :)

As for actually doing checks to make sure the source/destination address are from EQ servers, I have thought of this myself (it was my original plan when I set out to block Half-Life packets). I realized though that the servers do change from time to time, and if I had ever wanted to play on a different server I would have to modifiy the lines etc (or if a server changed IPs).

A viable solution may be perhaps add this functionality as a list in showeq.xml. Also probably the wisest solution.

And it would of course, have to be an option.

For example, I used a modified version of udpecho for a while (I use a switch here, not a hub), to echo all EQ traffic back across the same NIC but targeted for my linux machine's mac address (so the switch would route it) though the EQ server was effectivly '192.168.128.1'.

I will look into adding a port filter/ip filter list perhaps in the near future. (don't quote me)

(And yes, this post is much longer than it should be, I'm damned tired)

[Cryonic]

why not edit the filter to only look for traffic going to/from the network range that houses all the EQ systems rather than worry about every single stupid UDP application that could be on the network...

for certain things I have used tcpdump to capture traffic with "net 199.108"

[workhorse]

why not edit the filter to only look for traffic going to/from the network range that houses all the EQ systems rather than worry about every single stupid UDP application that could be on the network...

As an intermediate Linux user, this is something I'd need some guidance on. But I would be willing to work on it and report back.

UnGod, Im sorry I wasn't more specific :o The port that changes is the client side port. I am a user, I don't run the server. If I was to edit the packetcapture.cpp with the server's port number, would that create the same result?

I was under the impression that you had to edit the port number being used by Teamspeak on the EQ Computer.

[workhorse]

This brings up another issue as well. Since one of the patches about a month ago I am having those "memory leak" issues. SEQ will run great for about an hour or 2, but then it will slow down and eventually stop.

I am obviously using Teamspeak during these sessions, and I wonder if the spam in the terminal window (the unreadable packets from Teamspeak) is causing this loss of performance. Any thoughts?

[pita]

I'm pretty sure if we just watched udp packets coming from the /18 address range that EQ server farms are currently in, we would be pretty safe. Also, it makes sense to read it from a config file, rather than hard coding it.

As for the teamspeak servers. When you set them up, you pick the port that you want others to connect to. So if you are connecting to various different public teamspeak servers, you will have to use whichever port they have defined, the default is 8767.

I know that if I am running teamspeak, playing EQ, and possibly running a p2p application, or even an IM application, the spam about crc errors going by in the console windows is impressive, and is probably causing a bit of unecessary overhead for the showeq application. There will be times that I notice a fair bit of lag in showeq, if I have a significant amount of network traffic happening... ie. enought that I notice some lag on the ping meter. That will disappear if I close down some of the other things that I have going on. Then again, my showeq box is an old PII 266, with 80 megs of ram, might just be too much processing for its old bones to handle.

[workhorse]

An update for hose interested.

I edited the packetcapture.cpp with the Teamspeak server's port (8767). I only connect to one private server, and the problem has stopped completely.

I'd like to thank everyone for their input and help in this matter!

[fester]

This brings up another issue as well. Since one of the patches about a month ago I am having those "memory leak" issues. SEQ will run great for about an hour or 2, but then it will slow down and eventually stop.

I am obviously using Teamspeak during these sessions, and I wonder if the spam in the terminal window (the unreadable packets from Teamspeak) is causing this loss of performance. Any thoughts?

Yes, it will use memory until the os kills it or it locks up paging so bad you kill it.

I tried using "Session Tracking" and encountered other problems with zoning. Sometimes SEQ doesn't finish "zoning" and stays in "zoning, busy" mode. Zoning again fixes.

I still don't have a solid fix. I am too lazy to put the hand edits back into source, so I just upgraded the system to 2 gig ram. At least now I don't need to worry about the teamspeak packets for weeks.

What is the negative of just dropping all CRC failed packets?

Three methods of fixing:

1) Session tracking which didn't work well for me.
2) Hand edit to exclude teamspeak packets which worked well, but I have not reapplied since I wiped and reinstalled from cvs/patches.
3) Drop all CRC failed packets in such a way they (or whatever is) don't use ram to store them until you run out of ram.

[lildr00d]

It was stated here to just allow packets EQ uses to pass either by ip address or UPD.. Does anyone have a list of these UPD ports used by EQ.