Quake Ports

[Tremor]

Does anyone know the exact port range that quake uses? Obviously it makes the initial connection on 26000 by default, but the client and server then set up a much different port to talk on. I've noticed this in the 4000 and 5000 range.

Also, how much bandwidth is a quake client actually transferring in terms if kbps to the server?

I ask because I'm going to do some QOS experiments with the DSCP value in the TOS header of each and every outgoing quake packet.

Thanks in advance,
Tremor

[Mindf!3ldzX]

Spike,Baker,and others discussed stuff like that here Inside3d Forums • View topic - Describing NQConnect

...system socket bound on an automatic port (probably in the 4k-8k range if its windows) and replies to B:RNDNATB via gateway C...

[Tremor]

hmm. I read over that but it doesn't really say what the port range is. The majority of the talk over there is related to natting.

I saw where Spike states, "TCP generally depends upon ICMP messages in order to detect the MTU properly. Routers that do not forward ICMP(can be a security 'feature') can thus result in TCP connections failing to transfer data(hanging) to servers with a lower MTU beyond the router."

One thing I would add is that most security professionals who block ICMP usually leave ICMP type 3 open (ICMP unreachable for path mtu discovery). This allows routers to perform MTU discovery (with the df (don't fragment) bit set. The DF bit prevents fragmentation of the packet, so that if the packet is too large for the MTU, an error message is sent, the sending router then lowers the packet size, and repeats the process until it no longer receives the "destination unreachable" error.

Another method (when ICMP is blocked) is to use what's known as MSS (maximum segment size) clamping. Setting the MSS on a router will tell all other routers connected to it to 'never send me a message larger than X'. This circumvents the problem with blocking all ICMP. It's more of a hack than anything, but it works like a charm on networks with a maximum MTU < 1500 (ethernet).

Beyond that, I know a lot of router guys who think its in their best interest to block ICMP so that their internet facing routers are 'undiscoverable'. This is false, and unfortunately, they block ALL icmp (instead of leaving type 3 open) A good hacker can find live hosts regardless of whether icmp is blocked or not. Hell, a simple nmap scan can detect live hosts without the use of ICMP. It has been my experience that blocking ICMP causes more problems than the illusion of more security. Blocking icmp has its place, but I generally frown upon it for reasons that Spike already stated.

OH yeah, and additionally, they're speaking on servers who are nat'd behind routers/firewalls and connection problems that arise because of it. So, if you're setting up an actual quake server and it is being natted, and you have control of said router, simply place that server on the DMZ and save yourself a lot of nightmares.

Not sure why I spilled all that - I'm a ****** for good shop talk I guess. Anyway, if someone has a port range and max client to server kbps, I'm all ears!

[Mindf!3ldzX]

Have a look at this discussion http://quakeone.com/forums/quake-hel...orwarding.html

they mentioned specifying port ranges, It seems that the netcode portion is really lacking any documents,even google struggles to turn up any information.


Another link https://www.google.com/webhp?rlz=1C1...8&ix=seb&ion=1

[Tremor]

Thanks Mindzx, I'll check it out. I had problems with google too =/

[Mindf!3ldzX]

0-65535. lol

[Spike]

the ports you say you noticed to be in the 4000-5000 range are default port numbers - Quake does not choose those port numbers, the system does. Windows uses the range you have observed when the application does not specify a port, but it is system specific.

(see the bind() calls. if the port number is 0, the system will pick one instead).

So minds is basically correct when he says the entire port range. Except it won't be 0, and its not likely to be < 1024.
Consult your operating system's documentation...
The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
Read the introduction.

[Tremor]

Spike, that's exactly what I wanted to know - that Quake does not actually have a port range, it just uses the system to grab one. And yeah, will never be < 1024.

Also, I find this to be pretty lamesauce. Looks like Win7 default dynamic is 49152 - 16384.


My experiment involves the following:

Background: ISP's that offer voip service will give priority to either A. packets that are destined for a particular VoIP server or B. packets that have a particular port range (generally UDP 16000-30000) or C. Packets that have a particular DSCP value in the TOS header (usually set by the hard/soft phone itself, or set on the switch/router).

My experiment will involve a QOS policy, set on a cisco 871 which will match Quake packets based on an ACL. Once matched, the packets will have their DSCP value set to 46 (or EF), then moved into a priority queue on the outbound interface.

Something like the following will suffice:

class-map match-all quake
match access-group 110

policy-map uplink
class quake
priority 50
set dscp ef

interface fa4
service-policy output uplink

access-list 110 permit udp any any range 49152 16384

Now, the above will certainly prioritize any udp traffic in the range specified by the extended ACL 110 on my own network. The priority command will ensure that the port range gets at least 50kbps of bandwidth, and will have priority queuing on the outbound interface; So if other data (http/whatever) is coming in, quake traffic will always be shipped out first. This would be a good thing to do on any network (especially if you have roommates or wives who like to lag you out with other internet traffic while you're gaming). It would be wise to classify other types of traffic and set their respective priorities as well...You can do this on any router that supports QOS or any type of rate-limiting.

The second thing that I'm hoping this will accomplish is to *trick* my ISP into thinking that these packets are high priority (with the DSCP field), and hopefully my ISP will expedite them over other types of traffic in the same way that my own network will be doing it and hopefully reduce a few ms of latency and fewer dropped packets in the process.

With that said, competent ISP's routers will see this DSCP field in the packet and usually strip that value out, and replace it with a value of 0 (which basically means, "best attempt at delivery but no guarantees") and all my hopes and dreams will be foiled. Having dealt with a lot of internet traffic in the past, I have seen some ISPs (big and small) have misconfigured routers that do not catch this little trick. If that's the case with my ISP, I should see a slight improvement with the newly prioritized data.

In all seriousness, this little experiment will probably fail. On the off-chance that my ISP honors DSCP values coming from its customers, I'll report back with the results. If you have a router that is capable of doing QOS, you might try doing this for yourself - it's worth a shot.