Rune Central

If you get the message "CONNECTION ACCEPTED" or otherwise seem to be able to connect to a server, but "nothing happens" ...

1) Type "STATUS" or "PING" ... see if that works, often it does.
2) Try temporarily disabiling your firewall and then try to connect to see if the firewall affects it.

CRITICAL QUESTIONS:

I never get this problem in ProQuake. ProQuake is the dominant "Quake server" running on about every box hosting a Quake server Windows/Linux. Is there a problem with ProQuake in server mode? Are there NUMEROUS Quake players that think that there Quake doesn't work anymore and don't play. Is there a bug with ProQuake in server mode that occurred sometime around 3.20 to 3.50?!?!?!?!

I like ProQuake the best. It has the most precise aim and my rocket goes where the crosshair is and such. However, I am wondering if a bug is not making a ton of people who own Quake think their Quake doesn't work and don't try to play out of frustration. I am going to follow up this investigation. If standard Quake and GLQuake have this problem, this could be lethal for any new players to play because those guys won't generally know there is a fix.

For now, assume the fix is ProQuake. Get it at http://www.planetquake.com/proquake.

[BTW, I don't support XQuake because it is not GPL complaint, but XQuake has the connect problem too. Just because it was based on ProQuake doesn't mean anything, remember ... XQuake was based on an older version of ProQuake like 2.x or something.]

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

I think it might have something to do with this:

Hmmmmmmmmmm .... maybe or maybe not. I think the problem is on the server side ... is that a server side issue??

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

Well I have had this issue you're talking about ever since I installed a firewall, ProQuake has been the only solution so far. Without ProQuake sometimes I would have to connect 3 or 4 times and do the ping or status until I got in.

OK ... IEEE. I get it! Perhaps the DNS lookup that everything does EXCEPT ProQuake is the problem. Maybe it never gets an answer anymore because it is referencing a DEAD SITE or DNS to do the lookup?

I'll ask Slot about this.

My purpose is that I at least want to understand what about non-ProQuake clients doesn't work.

I am now almost certain the problem isn't the ProQuake server software.

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

By the way, did I mention I get the CONNECTION ACCEPTED problem without my firewall up when using GLQuake, WinQuake, JoeQuake.

The DNS lookup explanation would be a good one, I might dig thru the ProQuake source and examine the commented out code. I bet the DNS lookup went dead.

But I am serious ... firewall down = same problem.

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

It's the firewall. I wrote about this at the IHOC Quakeboard forum, but that's a registered-users-only forum so I'll repost it here:

I tried various servers using WinQuake and they all gave me the connected...(nothing) thing. It's probably my firewall. The reason more people are seeing this problem now is just that more people are using firewalls now.

Quake uses a very firewall-unfriendly protocol -- the first server->client packet contains a server port number for further packets, followed immediately by packets from the server on that port. There's no way any firewall can deal with this except to be very loose about what incoming packets it allows, or by actually reading the contents of packets and recognizing various application protocols. I think some firewalls might do this for FTP; I even hacked the Linux 2.0 firewall code years ago to understand the Quake protocol, but unfortunately my mods were not applicable to Linux 2.2 or 2.4.

To illustrate, here's an example Quake client/server conversation:

client:43711 -> server:26000 : request connection
server:26000 -> client:43711 : accept : (use port 4812)
server:4812 -> client:43711 : some init stuff
server:4812 -> client:43711 : some init stuff
...
server:4812 -> client:43711 : world update
client:43711 -> server:4812 : player input
etc.

I chose 43711 and 4812 at random; these ports are chosen randomly by the client and server per session. Only the 26000 request/status port is constant.

The problem is that the client's firewall doesn't know about that magical "use port 4812" command in the first server->client packet. All it sees is 43711->26000, so it only allows return traffic on 26000->43711 and blocks the 4812->43711 packets. When the player does a "ping" the client sends the ping on 43711->4812 so now the firewall knows about that remote port and allows return traffic from it. So the conversation looks like this:

client:43711 -> server:26000 : request
server:26000 -> client:43711 : accept : use port 4812
server:4812 -> client:43711 : some init stuff (blocked)
server:4812 -> client:43711 : some init stuff (blocked)
server:4812 -> client:43711 : some init stuff (blocked)
server:4812 -> client:43711 : some init stuff (blocked)
client:43711 -> server:4812 : ping
server:4812 -> client:43711 : some init stuff (accepted)
server:4812 -> client:43711 : some init stuff (accepted)
...
server:4812 -> client:43711 : world update
client:43711 -> server:4812 : player input
etc.

I suspect ProQuake has an automatic client:43711->server:4812 (probably a "nop" command) to overcome this problem. So the conversation looks like this:

client:43711 -> server:26000 : request
server:26000 -> client:43711 : accept : use port 4812
client:43711 -> server:4812 : nop
server:4812 -> client:43711 : some init stuff (accepted)
server:4812 -> client:43711 : some init stuff (accepted)
...
server:4812 -> client:43711 : world update
client:43711 -> server:4812 : player input
etc.

Basically ProQuake does the initial "ping" for you automatically. This isn't a problem with the ProQuake server, it's an inherent problem with the Quake 1 network protocol which the ProQuake client managed to overcome with a little kludge.

As I said the Quake 1 network protocol is firewall unfriendly, but that's not all that's wrong with it. Notice the sequence of packets during initialization: 1 packet from client->server, then a bunch of packets from server->client. By spoofing the source address on a connect request, you can trick a server into sending several kilobytes of data to somebody else's IP address. This is known as a "smurf attack". Back when there were hundreds of Quake servers, attackers could "smurf" all of them simultaneously to DDoS someone. That's what those "unconnected" floods were, when all the servers would fill up with "unconnected" players all at once. If Id had just required a single client->server acknowledgement right after the server's acceptance, both the "smurf" vulnerability and the "connected...(nothing)" problem would never have existed.[/url]

I've developed an experimental server patch that modifies the networking code to use a single server-side port for all communication with all clients. This should fix the "connect...(nothing)" problem and as an added bonus require only a single open UDP port in the server's firewall.

This patch could use some heavy stress testing, so please connect to any of the servers at Quake.Xoc.Net and give it a try. If it works well in testing I'll cook up a patch for ProQuake and send it to the ProQuake maintainer. The patch is actually quite small, about 10 lines of C code.

This patch is 100% server side and should work with any Quake client. I've tested it with WinQuake and ProQuake so far; please test with whatever clients you have available (DOS, Mac, Xquake, id's GLQuake, etc).

Whoa, somehow I missed that "I'M NOT USING A FIREWALL" post. Are you using a NAT router? Connection sharing? Smart cable/DSL "modem"? I'm still pretty certain this is a client-side routing issue.

The problem is that the reverse DNS can add to the connect time to make it over 10 seconds on some systems/ISPs. The reason it only happens on ProQuake servers is a command called pq_connecttimeout, which times out the connection if the client isn't finished with the signon (default value is 10). It's kept at a low value to help against flooding, or failed connections. (Normally, they would hang around for 5 minutes.

See also net_messagetimeout.

EDIT:The command is net_connecttimeout not pq_connecttimeout.

_________________
Slot Zero

Hehe, yeah Yugo ... I thought it was the firewall too and then I shut it off and still got the problem. This turned everything I thought about this problem upside down.

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

Yeah, but Slot ... I got the problem at Yugo's server too in testing last night and he quake.ihoc.net isn't running sqpro or wqpro.

Firewall off, I just tried GLQUAKE.EXE to connect to Yugo's quake.ihoc.net and it doesn't go. That would seem to rule out firewalls and ProQuake server in a single test.

Slot, it is possible that the DNS lookup that GLQUAKE.EXE is referencing is DEAD. I mean, the DNS lookup has to reference an IP doesn't.

(Yugo ... just FYI ... I don't have anything fancy for a network, just a simple LAN + Cable modem. I have a Win98 machine that isn't on the lan and I might testing it there to see if the LAN could somehow be the problem).

Like I said earlier, this doesn't stop me from playing Quake, I want to understand what the problem is. I did previous think it was the firewall, but if I shutdown Sygate and it isn't running in "Processes" when I do CTRL-ALT-DEL then doesn't that rule that out?

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

Win 98 + GLQUAKE.EXE + No LAN + ZoneAlarm Off + Connect quake.ihoc.net or quake.shmack.net works fine.

Perhaps it is Win XP or perhaps it is the LAN or perhaps when Sygate is shut down it isn't really shut down.

This kinda kills my DNS lookup is dead theory

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

If it is the firewall, it's odd that if Sygate is shutdown I still get the problem on my Win XP machines.

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

This may or may not be related but I will throw it out there. I recently installed XPPro in my mom's computer. She is using a 4 port router/switch. Everything worked fine internet and LAN wise except she could not print to the printer on this computer from another computer on the LAN. The printer was not even seen by any other computer. I then checked the net settings in XP only to find that Windows is automaticaly running a firewall of it's own. I disabled this on the computer with the printer attached without results. But when I disabled this on both computers (one running XP the other XPPro) the printer was instantly recognized and then all was well (except for the fact that both computers are running Windows:P ) Maybe Windows is still running it's built in firewall?

One other note:
My brother is running GLProQuake on this computer without any problems. Though I cannot remember if he installed and ran Quake on this computer before or after I turned off the built in firewall.

MagnesiuM

Good point.

Also note I said "I think it might" when I was offering a possible solution, cause I noticed the same thing Baker did about ProQuake and I read this page http://www.planetquake.com/proquake/features.html and that part I quoted was the only part that stood out to me..

XP seems to have some other weird issues with Quake. Like my situation: I'm dialup and I have a small lan of just 2 computers, but when I have the lan enabled Quake tries to use the lan connection. I could use -ip but my IP changes ALL the time, while the lan does not.

But I haven't tried it since I installed the service pack for XP (I recommend doing this, so does Microsoft), but I will soon as I replace the other machine's power supply and I'll report back if SP1 helps.

UPDATE: Yugo2Heck has a promising potential fix in place at QUAKE.XOC.NET ....

Please try the following:

Using anything except the ProQuake clients (GLQUAKE.EXE, WINQUAKE.EXE) ... do this ...

1) Startup and try to CONNECT QUAKE.XOC.NET (should work without Connection Accepted and then nothing problem)
2) Try CONNECT QUAKE.SHMACK.NET (should get the prob)
3) Try CONNECT NYGMA.QUAKE1.NET (should get the prob)
4) Try CONNECT QUAKE.IHOC.NET (should get the prob)

And then report back the results (With your Operating System ... So Mag, I doubt this affects you but you never know). I am hoping that you don't get the problem with #1 and then get the problem with #2, #3, #4.

I can't explain what Yugo has done, it is out of my league, but it WORKS on 2 of my machines (the 3rd never gets the problem...ever, it's old and runs Win98). Yugo's test fix worked with my firewall up OR down.

Reference thread:

QUAKEBOARD thread on this topic

_________________
quake.shmack.net:26000 = RQ, 26001 = Rocket Arena, 26002 = Vote-Anything
quake.ihoc.net, Rockets/jet/7 runes
quake.singed.net, RQ on E1M7
http://www.GameStatus.Net stats, http://www.GameAholic.Net Q1 servers

Baker asked for confirmation of this, and I tried a bunch of servers using a non-proquake client and only QUAKE.XOC.NET worked for me (without having to type status or ping).

I sure hope they fix this, I've been dieing to use my graphical clients again.

I seem to be able to confirm this as well. When I was finished testing I went to SINGED and I typed status after it said "Connection Accepted" then McAffee firewall popped up and told me my Quake client was trying to use a new port, I allowed it and connected fine (But I did have to type status first.)

This has nothing whatsoever to do with DNS. The DNS fix that ProQuake made doesn't cause any problems and is a very good idea (it was also one of the first fixes I made when I got the Quake source back in 1999).

My long description of the problem with example sessions pretty much nailed it, except for the "firewall" thing which is kind of a red herring. It's actually the NAT router, which anyone with "cable + LAN" must be using (unless they have multiple public IP addresses, which is expensive and rare these days). Replace "blocked by firewall" with "ignored by NAT" and the description is more accurate.

The fix is pretty simple if you know socket programming at all.

NetQuake works like this: Server creates a UDP socket, binds to port 26000, reads messages on that socket from the world. When it gets a CCREQ_CONNECT message it creates a new socket, binds it to a random local port, leaves it unconnected (can receive from any remote address!) and sends back a CCREP_ACCEPT reply to the client from the original socket (port 26000) with the new socket's port number. For the remainder of the session with that client, all communication goes over the new socket (on the random local port). The new socket is unconnected, which means it can receive messages from anyone, not just the client... so the server manually checks every message to make sure it isn't a "forgery".

My fix: Main socket as above on port 26000. When server gets CCREQ_CONNECT it creates a new socket, binds it to local port 26000 (I set the SO_REUSEADDR socket option to make this work), then connects it back to the client address/port. On the original socket it sends back CCREP_ACCEPT with the new socket's port number, which happens to be the same as the old socket's port number (26000). All further communication with the client is through the new socket. Since this socket is connected it can only receive messages from the proper client.

The reason this fixes our "can't connect" problem is that the initial server->client messages after the CCREP_ACCEPT are now on the same server-side port number as the client's initial outgoing CCREQ_CONNECT. Thus the client's firewall/router knows about the remote port (client sent to it) and correctly forwards traffic from it back to the client.

We still need more testing. I figure the Idsoftware guys are pretty smart and used that weird method (unconnected socket bound to a random port) for a reason. Or maybe they just didn't know as much about socket programming as I do.