NAT Fix -- Solves the "connection accepted" issue

[mh]

Well I'd be first to admit that there's something of a Cargo Cult element to what I did, yes.

[r00k]

Hate to dig up an old thread,

using the single

Code: Select all

   MSG_WriteByte (&cls.message, clc_nop);


Which seems to get lost sometimes

I've replaced it with

Code: Select all

CL_KeepaliveMessage();


which contains the same clc_nop but with better handling.

Some servers seemed to take almost 30 seconds to get to connection accepted previously, with that above change, it connects in less than 5... In some cases, the server lost the reply and just hung at accepted.

[Baker]

Here is the other part of the ProQuake client-side NAT fix in regards to connecting to a ProQuake server:

Add to qsocket_t in net.h

Code: Select all

   byte            proquake_connection;

In net_dgrm.c in _Datagram_Connect add the yellow ...

MSG_WriteLong(&net_message, 0);
MSG_WriteByte(&net_message, CCREQ_CONNECT);
MSG_WriteString(&net_message, "QUAKE");
MSG_WriteByte(&net_message, NET_PROTOCOL_VERSION);

// Tell the server we are ProQuake 3.70
// A normal Quake server only looks at the first 12 bytes of the message
// above, so only a ProQuake server reads these extra bytes.
MSG_WriteByte(&net_message, 1); // JPG - added this
MSG_WriteByte(&net_message, 37); // JPG 3.00 - added this
MSG_WriteByte(&net_message, 0); // JPG 3.00 - added this (flags)
MSG_WriteLong(&net_message, 0); // JPG 3.00 - password protected servers

Still in In net_dgrm.c in _Datagram_Connect add the yellow ...

int len = ret;

ret = MSG_ReadByte();
if (ret == CCREP_REJECT)
{
reason = MSG_ReadString();
Con_Printf("%s\n", reason);
q_strlcpy(m_return_reason, reason, sizeof(m_return_reason));
goto ErrorReturn;
}

if (ret == CCREP_ACCEPT)
{
Q_memcpy(&sock->addr, &sendaddr, sizeof(struct qsockaddr));
dfunc.SetSocketPort (&sock->addr, MSG_ReadLong());

Con_Printf ("Client port is %s\n", dfunc.AddrToString(&sock->addr));
// Client has received CCREP_ACCEPT meaning client may connect
// Now find out if this is a ProQuake server ...
sock->proquake_connection = (len > 9 && MSG_ReadByte () == 1) ? 1 : 0;

Finally in cl_input.c we need to make sure we write short angles when connected to a ProQuake server (0-65535 = 2 bytes = 16 bits) instead of byte angles (0-255 = 1 byte = 8 bits).

Except if we are playing a demo, we aren't "really" connected to a server. ProQuake server reads client angles from a ProQuake client as shorts for more precise aim.

cl_input.c in CL_SendMove, this is example is a FitzQuake example ...

for (i=0 ; i<3 ; i++)
//johnfitz -- 16-bit angles for PROTOCOL_FITZQUAKE

if (!cls.demoplayback && NET_QSocketIsProQuakeServer(cls.netcon))
MSG_WriteAngle16 (&buf, cl.viewangles[i]);
else

if (cl.protocol == PROTOCOL_NETQUAKE)
MSG_WriteAngle (&buf, cl.viewangles[i]);
else
MSG_WriteAngle16 (&buf, cl.viewangles[i]);
//johnfitz

And in put this in net_main.c

Code: Select all

qboolean NET_QSocketIsProQuakeServer (qsocket_t *s)
{
   return s->proquake_connection;
}

This is tested and works and is the minimum client-side implementation.

[r00k]

ya that sock->proquake onnection
i have 1defined as MOD_PROQUAKE

[Baker]

ya that sock->proquake onnection
i have 1defined as MOD_PROQUAKE

I was trying to test Mark V on a server and the "easier NAT fix" didn't cut it. Wish all this were known in the past.