Purpose:
Allow Need For Speed Most Wanted LAN games to be played outside of a LAN, enabling true cross LAN and cross site multiplayer games. This has been tested to work over multiple VPNs connecting cable modems and adsl modems. Tests have shown NFSU3 requires only the server machine to be running nfsu3relay. Tests without a VPN have been sucessful with many forwarded ports, see below. If you have machines connected via a LAN but on different subnets, that will also work - this amounths to the same situation as a VPN.
The Windows port has also been tested to work. Has been found to work even when running on the same machine as the NFSU3 game itself (ignore the recvfrom=-1 error message, it is still working). This means that the relay only requires either a VPN connecting the sites, or many ports forwarded.
Look in the ToDo section for more Windows references.
Download:
NFSMW uses the same protocols as NFSU2, so you can use nfsu2relay, or download it directly from here:
nfsu2relay.c - the Linux/Windows source
nfsu2relay.zip - the Windows executable
Compile with:
gcc -O2 nfsu2relay.c -o nfsu2relay
Usage:
nfsu2relay <NFSMW machine IP> <NFSMW machine IP> [NFSMW machine IP...]where both IP addresses are machines running NFSMW, and nfsu2relay is running on the server machines subnet (or the same machine as the game server).
More Complex usage:
In the scenario:NFSMW machine <--VPN--> Internet <--VPN--> NFSMW machine
ie. A VPN connects the two NFSU3 machines over the internet. This needs nfsu2relay to be running on the server side of the NFSMW game. The relay should be given the IP addresses of the NFSMW machines, and IP traffic must be directly routeable between both machines - as nfsu2relay only helps you connect to a game, once running the clients/server talk directly without subnet limitations.
The above two scenarios have been tested to work. We can confirm that nfsu2relay must be running on the server, and need not be running on the game clients.
nfsu2relay without a VPN
This hasn't been looked at, nfsu2relay might give so clues.Theory of operation:
The job of nfsu2relay is to relay broadcast packets sent out by NFSMW when looking for a game. Once the clients know the server IP address, there is no need for nfsu2relay as the clients/server talk directly to each other using the IP addresses obtained during the broadcast (or nfsu3relay's relayed broadcast).
As broadcast packets only spread as far as the subnet from which they originated, NFSMW can't normally find NFSMW servers on a nearby subnet. nfsu2relay looks for these broadcasts and sends a copy of what it receives to the IP addresses given as arguments (except for the IP the broadcast packet came from). Nfsu3relay fakes the source IP addrees, so the relayed broadcast packet (which is no longer a broadcast as it is sent directly to single machines) looks like it came from the original machine, making the packet relay process transparent.
For example, if 192.168.15.51 is the NFSMW client, 192.168.0.7 is the NFSMW server,
both machines are connected by a Linux machine on IPs 192.168.15.1 and 192.168.0.100.
When told to look for LAN games, NFSMW looks for servers by sending out a udp
broadcast on port 9999:
192.168.15.51:9999 -> 255.255.255.255:9999 udp length 384 (subnet 192.168.15.0/24)
nfsu2relay receives the broadcast, and sends it to the other given IP faking
the original sender IP address:
192.168.15.51:9999 -> 192.168.0.7:9999 udp 384 length (subnet 192.168.0.0/24)
NFSMW server will receive this spoofed packet and accept this as if it was a
broadcast on the same subnet by the client.
While this is happening, NFSMW server sends out broadcasts of its own, presumably
advertising itself. In this case it would look like this:
192.168.0.7:9999 -> 255.255.255.255:9999 udp 384 udp length (subnet 192.168.0.0/24)
nfsu2relay receives the broadcast, and sends it to the other given IP faking
the original sender IP address:
192.168.0.7:9999 -> 192.168.15.51:9999 udp 384 udp length (subnet 192.168.15.0/24)
In either case, the receiving parties receive the correct sender address, and so can respond directly without using broadcasts. Looking at the packets generated, they also do not use port 9999.
When the clients and server are not on nearby subnets, the same idea still works but in this case multiple nfsu2relays are needed to relay the broadcasts.
To do:
Would be useful if nfsu2relay relayed real broadcasts to given subnets rather than specific IPs. Needs broadcast flag, would also need changes to check for source of packet. A quick test didnt work, so if needed this will need looking into some more. This is a low priority and would need control options.
Compile for Windows myself. DJP sent me the Windows executable, so if the source changes, the executable becomes out of date.
Related to previous, find the reason for the recvfrom=1 errors when running under Windows on the same machine as the game itself.
As a more general solution, look for the Gamers Internet Tunnel. Don't know if this supports the NFS series, but it could do.
Credits:
in_cksum(), pseudohdr and udpsend() came from a German language 'hacker' howto, one of the few examples of RAW packet generation that actually generated well formed packets.
The Windows port (modified source and exe) came from DJP, dejepe at hotmail.com.
Other code and the main idea came from Richard Gregory, greg at csc.liv.ac.uk
History:
12/12/2005
Tested nfsu2relay to work with NFS Most Wanted. Wrote this page.