The information below pertains to SOCOM I. SOCOM II uses a new voice system which, I believe, acts very similar to the system from SOCOM I. Although I haven't spent the time analyzing the voice protocol for SOCOM II in the same detail as SOCOM I, I have been able to get it working with NAT. It *appears* that the only difference in SOCOM II is that the port range is now 3000-3999 UDP (no longer 6000-6999 UDP). So if you're reading this for information on SOCOM II, use 3000-3999 UDP in place of 6000-6999 UDP when it is mentioned in this article. I will probably write another article for SOCOM II when I get around to actually looking at the protocol. The SOCOM II solution should be considered a hack until then.
SOCOM is by far the best combat simulation I've ever played. One of the most attractive features of the game is the fact that it supports online play. In my attempts to play online, I've discovered many things about SOCOM and the PS2 Network Adapter (NA). Because the NA is so new, most of the discoveries I've made are bound to be fairly unknown. Sony support certainly does not want to help out; all I could ever get was the recorded message "Due to the high demand for Sony products, we are unable to take your call at this time."
Most people are able to connect their PS2 directly to their cable or ADSL modems, but for some this is not possible. I've listed the two most common situations here:
1.) You use Network Address Translation (NAT) with a single external IP (either as a preference, or because your ISP does not allow more than 1 IP), and you want your PS2 to coexist on your network with other machines.
2.) You use an ISP that does not officially support the PS2 NA -- Shaw (my old ISP) for example, will not issue a DHCP lease to a PS2 NA. They claim that they are upgrading their system to support the PS2 NA, but I've seen no proof of this.
An obvious solution to situation 2 (at least for Shaw) is to implement a network as described in 1 (to provide a local IP for the PS2, and avoid the need for a DHCP lease from your ISP). Assuming this will work for other ISPs (please tell me otherwise!), I will continue on and describe a solution for situation 1.
If you're in the position where you've got multiple machines sharing one IP (via NAT), you're either doing this through hardware (using a router), or through software (using a firewall machine with pf, ipf, iptables, etc). I will refer to the interface which is assigned the external IP as the "external interface" (the router interface, or the external interface within your software firewall machine). If you're doing NAT through hardware, then most people will simply put the PS2 into a DMZ. What this does is, essentially expose the entire PS2 to the network, i.e. any incoming connection attempt will be directed to the PS2. This may work for most, but if you're like me, you want your other services to continue to work properly (ssh, http, irc, ftp etc). So placing your PS2 in a DMZ, will not work.
What one needs to do is determine what ports the PS2 accepts incoming connections on, then forward them. This differs for every game of course, but most games should NOT require any ports to be forwarded to your PS2. The reason for this is because of the nature of TCP keep state. I have no clue what hardware routers do, but I would assume that TCP keep state is on by default (and I will assume for the rest of this article). Essentially TCP keep state allows an inbound packet (to your external interface) to be redirected to the local machine that initiated the TCP connection (a gross oversimplification, but this is the most important aspect with respect to SOCOM). So say the local machine was your PS2, and it initiated a connection to SCEA (SOCOM server). Then any packets (from that connection) coming in from SCEA to your external interface would be redirected to your PS2. TCP keep state stays in place until the connection is closed. So essentially while the connection is open, you have a forwarding rule that sends all packets (from that connection) to your PS2. When the connection is closed, the forwarding rule disappears. This is the case for ports 10070-10080 TCP for SOCOM (and all other games); you do NOT need to forward these ports, I repeat you do NOT need to forward 10070-10080 TCP.
If you understand that part, then we can move on to the more complicated bit, the voice (headset) communication. I have read in various places that you need to simply forward 6000-6999 UDP to your PS2. This is not true at all, and in fact the only reason this appears to work for people is because their PS2 is already in a DMZ anyway. I struggled for many days trying to figure out exactly how voice works, and was fooled for quite a while. What actually happens is that the host PS2 (the player who can force the game to start) is responsible for maintaining a list of player IPs, as well as a specific port for each of those IPs. After a round has started, each PS2 in the game decides on a random port in the 6000-6999 UDP range. At this point, no other PS2 knows what this random port is. Once the port has been decided on, the PS2 binds to that port, and a "hello" packet is sent to the host PS2 so that the IP and the source port of the packet (the random port the PS2 decided on) can be recorded. Once the PS2 has done this, the information is provided to each of the other PS2s in the game (by the host PS2). When someone wants to complain how they were shooting at a guy for 30 seconds but he didn't go down (they hit O and start talking), their PS2 sends the packets to every other PS2 it knows about at the port provided by the host PS2. Hence, incoming voice packets are sent directly from other PS2s to the source port of that initial "hello" packet on the destination PS2.
Do you ever wonder why voice is disabled in one game and it works fine in others? The reason for this is because the host of the game is not allowing these "hello" packets to reach their PS2, either by accident or as an intentional act. So if voice isn't working in a game, usually the solution is to get rid of the host (or ask him to fix the problem).
Now if you understand anything about NAT, you'll know that the reason it works is because the source port of outgoing packets is modified to fit within a special range (usually a high range, i.e. 55000-65535). So if your "hello" packet from your PS2 has source port 6531 UDP, then the packet would actually NOT appear as coming from 6531 UDP when it arrived at the host PS2, but rather the NAT translated port (this is also random!), say 59383 UDP. So then the other PS2s in the game would start sending packets to 59383 UDP, which of course would not get back to your PS2. If you think that redirecting packets coming in to 59383 UDP to your PS2 at port 6531 will work, remember that both the PS2 port and the NAT translated ports are randomly decided on. So there's no way one can map them in that fashion. The correct solution here (and yes, I tried many before I came to this solution), is to perform a 1-to-1 source port mapping for NAT within the 6000-6999 UDP range. What I mean when I say 1-to-1 mapping is that any packet from your PS2 heading outbound will not be randomly assigned a source port on the external interface, but it will instead use the source port of the packet that was sent from your PS2 to the external interface. So if your PS2 sends a packet from 6531 UDP, then the packet will travel through your external interface and be sent from 6531 UDP as well (not a randomly assigned port like 59383 UDP). If this can be accomplished, then all one needs to do is forward the entire 6000-6999 UDP range back to the PS2.
This can be implemented using pf and the "static-port" option (this option is only available in OpenBSD 3.3 and beyond). Although I am describing a solution using OpenBSD, something similiar should be possible with Linux (iptables), and the other *BSDs (using ipf/nat). I would suspect that this sort of complexity is not possible with a cheap hardware router, but this is only a guess as I've never used one.
Here are the lines I use for SOCOM I, where ne0 is my external interface and 10.0.0.3 is my PS2:
nat on ne0 proto udp from 10.0.0.3/32 port 5999 >< 7000 to any -> ne0 static-port
rdr on ne0 proto udp from any to any port 6000:6999 -> 10.0.0.3 port 6000:*
pass out on ne0 proto { tcp, udp, icmp } from any to any keep state
pass in on ne0 proto udp from any to any port 5999 >< 7000
So in summary, the reason some may not wish to put their PS2 into a DMZ is to still allow for other services on their external interface. This requires that we know exactly how the PS2 communicates, and with which ports it accepts incoming connections. 10070-10080 TCP is used for communication with the SOCOM server. This range does NOT need to be forwarded to your PS2 as TCP keep state rules allow for proper 2-way communication. 6000-6999 UDP does need to be forwarded, but also, the source port of the PS2's outbound packets within this range must be preserved!! I have provided the OpenBSD pf rules to do so, but it may also be possible with Linux iptables, *BSD ipf/nat (and others). If you are able to do this with other software, or if you are able to do this with a router, I'd like to hear how you did it.
