Luigi Auriemma

How can the natneg file be added to additional POCs to test it? Where abouts would it go? Maybe a program can be created to do the adding for us, or something that works with existing POCs.

I've always been interested about this protocol works.

Thanks

the first feedback for this fresh project :)

ok, consider the gsinfo tool available here:

http://mirror.aluigi.org/papers/gsinfo.zip

(it's a tool for querying game servers using the old \status\ and the gamespy 2 protocol)

Now, if you want to query a terminator 3 server you will fail since almost all the public servers of this game are behind NAT or router.
So I used the following command and it failed:



so I added at line 120 of gsinfo.c the following line:



recompiled and the following is the successful result:



naturally I suggest to skip the packets from the game server which start with the bytes fd fc since they are related to natneg, although my function already handles them (in fact I had no problems during my example) in some occasions could happen that they reach your socket

hmm I don't think I'm putting this into the right place (line 120?) in gsinfo, it's not working. What code do I put it under, I can't tell from the example above?

Even better, where would I put it into a POC, for example terminator3?

Thanks

the additional lines must be added under the creation of the socket ("if(sd < 0) std_err();") so they looks like:



and this is the same for any other tool, poc and so on since all my network code uses the same "format" with sd as socket.

Oh, naturally verify if the server exists on the master server before testing gsnatneg otherwise it's normal that you receive an error.
I use gslist for the list

Hmm... I tried the above, but it came back with

F:\>F:\MinGW\bin\gcc -o gsinfoneg.exe gsinfo.c -lws2_32
C:\DOCUME~1\Admin\LOCALS~1\Temp/cchuJmiw.o:gsinfo.c:(.text+0x747): undefined reference to `gsnatneg'
collect2: ld returned 1 exit status

I did

peer.sin_addr.s_addr = resolv(argv[1]);
peer.sin_port = htons(atoi(argv[2]));
peer.sin_family = AF_INET;
rlen = sizeof(peer);

sd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
if(sd < 0) std_err();
if(gsnatneg(sd, "terminator3", NULL, peer.sin_addr.s_addr, ntohs(peer.sin_port)) < 0) {
printf("- natneg failed\n");
exit(1);
}

buff = malloc(BUFFSZ + 1);
if(!buff) std_err();

if(!type) {
infonum = sizeof(info) / sizeof(u_char *);

Any ideas?

add gsnatneg.c to the command:

F:\MinGW\bin\gcc -o gsinfoneg.exe gsinfo.c -lws2_32 gsnatneg.c

you need also to rename the 2 timeout() calls (search (timeout( in the code) in gsnatneg.c to gsnatneg_timeout... an error I did and which I fix now.

Ok, done that, but now...

F:\>F:\MinGW\bin\gcc -o gsinfoneg.exe t3wmbof.c -lws2_32 gsnatneg.c
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0x327): undefined reference to `recv@16'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0x474): undefined reference to `recv@16'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xa8d): undefined reference to `setsockopt@20'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xb08): undefined reference to `setsockopt@20'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xb3c): undefined reference to `getsockname@12'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xd07): undefined reference to `connect@12'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xdba): undefined reference to `send@16'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xdec): undefined reference to `send@16'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xe56): undefined reference to `connect@12'
C:\DOCUME~1\Admin\LOCALS~1\Temp/ccPpk0i7.o:gsnatneg.c:(.text+0xfce): undefined reference to `recv@16'
collect2: ld returned 1 exit status

???!

yeah sorry place gsnatneg.c before -lws2_32

anyway about gsnatneg within some hours I will release the new version.

I have just released GS natneg client 0.1.1

I have made various changes and naturally some bug fixes.
In my tests it worked all the times with a success of 100% using various types of tests like for example 2 natneg requests for the same server or 2 for two servers of the same game and also 2 different servers of 2 different games.

It seems your natneg cannot adjust to port changes like the official one can.

For example:

Sometimes a server will be created with a specific ip and port (ie 87.14.31.121:32411) but for some reason the hosts router (only on certain routers or configurations) automatically changes the port number (it ascends) after a while. So some minutes later the ip and port of the server will be 87.14.31.121:32418, and then maybe a few minutes after that 87.14.31.121:32505 etc etc. On the server list, gamespy still uses the port that the server initially used when it created a game, and so it is out of date.

Your natneg version doesn't seem to be able to adjust to the new port number and presumably still attempts to connect to the original one which stops it from working. The same sort of thing can happen with ip addresses as well. The official gamespy one can adapt to this ip/port change.

Also, your natneg version seems to take a lot longer than the official one to negotiate? The gamespy one does it almost instantly most of the time.

Thanks

for the first problem seems something unrelated to my gsnatneg implementation, right?

for the second one... uhmmm sincerely I don't know why takes more time.
In my tests the thing worked almost immediately while (for example) in gslist takes a bit of more time and in fact I have made this type of query optional with the -G option

I think your version must be missing the part where it redirects to the changed port? (like the gamespy one does). Otherwise I sometimes get failed natnegs because of this :(

just finished to recheck gsnatneg.c

the main problem was just that one of the port you have said (I needed to save the xport value) while the other corrections I have made have been substituiting a 0 with a 1 in the reply you send to the game server because with a specific game it continued to send me a lot of natneg packets and waiting one second for resending a new packet (in case the first one is not arrived)

So now should be all ok, naturally let me know if works.
Thanx a lot.

ok, the nat negotiation is much faster now :) but it still doesn't work when the ports have been changed.

I imagine that in the master server natneg reply packets are the details of the ip/port that the server is now using. Maybe your natneg just needs to use that ip/port instead of the initial one it is querying?

the port is changed but I forgot to tell you that now is required a new parameter for this reason: struct sockaddr_in *

In short you call the function passing the IP and the port you know and if it successed fills the sockaddr_in structure with the IP and the port you must use in the tool in which you have called it.

Something like:

I'm a bit confused. Is this new parameter already in natneg 0.1.2? I have complied natneg into a POC but I'm not sure how to do this extra thing?

yes the parameter is already available in natneg 0.1.2, in fact if you don't modify your existent code adding &peer it will not work.
So just add &peer after the port when you call gsnatneg() and it's all done