Qrack/DirectQ/EzQuake Issue

[Frenzy]

Recently, (the last couple weeks), users cannot connect to yayowave.quakeone.com and newdm.quakeone.com (which are both hosted by the same provider) using Qrack/DirectQ/EzQuake.

Oddly enough, yayotexas.quakeone.com is also through the same provider as the above two servers, and these clients can connect just fine.

Ongoing issue which we have talked about on the servers a lot, but have come up with no real answer. For some reason, the NEWEST version of Qrack connects, but the older ones won't. But for some people, neither.

Are we to ask the provider to reinstall the servers?

[Magnus]

I noticed this too using DirectQ 666a.

I just ended up getting my MVP's elsewhere.

[Mindf!3ldzX]

Maybe schedule some tests ,and have someone on hand to observe their end while various people with various clients from various places attempt to connect.

Maybe they can see whats occuring and remedy

[bta.monster]

At first I thought this was only an issue with my server since it's using Darkplaces... I ran a few tests awhile back to see what was happening. I ran the same Darkplaces version and same version of NewDM that's on the fatpipe server here on my local computer, and opened up port 26000 on my router.

Foq was able to connect to the server on my local computer with Joequake just fine, but couldn't connect to the one in fatpipe which was running the same stuff. Just stuck at connection accepted with client to server keepalive or something of that nature. Something must be weird with their setup over at Fatpipe. Probably only the chicago servers too... NewDM is in Chicago and yayowave is in Chicago too.

Called fatpipe up a few weeks ago and told them what was happening, they said they'd check it out for me and send me an e-mail back. Never got the e-mail back, but the IP of the server changed somehow. Probably they just put it on a different machine, but the problem still isn't solved.

Would love to get this issue fixed... been bugging me for awhile now. At least I know that it isn't a Darkplaces problem since yayowave is having similar problems :\

[MH]

I've just tested newdm with both Qrack and DirectQ and can confirm this problem. Assuming that the client-side NAT fix here is both valid and comprehensive, there may be value in checking NAT or firewall rules on the host. For my money (and from professional experience) there's likely such a rule difference between the servers that do work and the servers that don't.

[R00k]

I posted this over on Inside3d, this is what i used as another method for fixing the NAT and instantly connecting to yayowave and speaknow servers...

bottom of void CL_EstablishConnection (char *host)

replace

MSG_WriteByte (&cls.message, clc_nop);

with

CL_KeepaliveMessage();

as CL_KeepaliveMessages also sends the nop, but does so i guess in a timely manner...

void CL_KeepaliveMessage (void)
{
	float			time;
	static	float	lastmsg;
	int				ret;
	sizebuf_t		old;
	byte			olddata[8192];
	
	if (sv.active)
		return;		// no need if server is local

	if (cls.demoplayback)
		return;

// read messages from server, should just be nops
	old = net_message;
	memcpy (olddata, net_message.data, net_message.cursize);
	
	do
	{
		ret = CL_GetMessage ();
		switch (ret)
		{
		default:
			Host_Error ("CL_KeepaliveMessage: CL_GetMessage failed");			
		case 0:
			break;	// nothing waiting
		case 1:
			Host_Error ("CL_KeepaliveMessage: received a message");
			break;
		case 2:
			if (MSG_ReadByte() != svc_nop)
				Host_Error ("CL_KeepaliveMessage: datagram wasn't a nop");
			break;
		}
	} while (ret);

	net_message = old;
	memcpy (net_message.data, olddata, net_message.cursize);

// check time
	time = Sys_DoubleTime ();
	if (time - lastmsg < 5)
		return;

	lastmsg = time;

// write out a nop
	Con_Printf ("--> client to server keepalive\n");

	MSG_WriteByte (&cls.message, clc_nop);
	NET_SendUnreliableMessage (cls.netcon, &cls.message);//R00k changed to NET_SendUnreliableMessage from NET_SendMessage
	SZ_Clear (&cls.message);
}

[Baker]

The firewall. You are not the only person to experience issues on Fatpipes Texas servers. Ironically, the Chicago servers don't have the issues. They weren't able to resolve the issue in the past.

/This information is correct as far as I can recall. They insisted the Texas server had the firewall the same, yet the problems persisted there but not on the Chicago server. Nor obviously the New York one, where kathos had ny.killzone hosted.

[MH]

I tried the CL_Keepalive thing in DirectQ by the way (yeah, I did notice your post ) but it didn't work.

[bta.monster]

Yeah it definitely has to be something Fatpipe's end. These are Chicago servers the problems are happening on, the one in Texas people can get to fine. Thanks for the info MH... I'll see if I can fall Fatpipe later and bug them again to get this fixed, maybe if Frenzy and I both complain enough they'll finally fix it

[R00k]

I tried the CL_Keepalive thing in DirectQ by the way (yeah, I did notice your post ) but it didn't work.

Weird, i know someone who added that CL_KeepAlive to (his personal version of) QuakeSpasm, and it worked... I'm not even confessing I know why it works, just a plug for a hole where the rain gets in...