Since the beta of EA/DICE's Battlefield Bad Company 2, forums have had a myriad of posts with game problems, with this symptom included in the posts. Since retail release of the game, and the subsequent release of Medal of Honor by the same publisher/developer teams, the same has been seen for the latter game.
Specifically, the event log entry in the windows system log is:
Event 36888, Schannel
The following fatal alert was generated: 10. The internal error state is 10.
When I first saw the error myself, I recognized it from my network programming days as an informational error, indicating some kind of barf-o-rama on the server side of a secure connection handshake. Unlike most of the other Schannel event IDs, this particular one seems to remain undocumented. Nonetheless, the Info opcode and 10 / 10 Alert Description and Error State hint strongly at it being server side.
Since it seemed to have no material effect on the playability of the game(s), my interest in investigating it stopped there. A recent poster, however, indicated that disabling their AV (Trend) caused the apparently related game issues to be remedied. While it appears that the game itself runs correcly despite encountering the Schannel error, it may be that some A/V that muck with everything on the wire might take drastic action in the face of it. Strange if some do, but plausible.
In any case, barring some other application / utility causing problems (e.g., said A/V), the error itself can be safely ignored. If it really bothers you, you can change the logging level via a registry change by modifying (or adding if needed) the key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
DWORD value EventLogging with a value of 0 will eliminate such event log messages. Note that current versions of windows seem to be more voluble for these errors - on older (e.g. XP), the error may occur without a log entry being generated.
I became interested again in this event / error recently while tracing the traffic activity of the game debugging a separate issue. Both games are built on the same engine / network infrastructure, so it is not surprising they share the same frailties.
From an outsider's view (since I have no access to the game source code, nor the EA master or game servers, my view must be the result of probing and testing theories, using debuggers and traffic sniffers), the network infrastructure for these games is a bit of a wreck. In the same way one might surmise their neighbor is a slob from observations of the trash bags thrown on their front lawn, the mishmash of connections and traffic these games generate is appalling. The possibilities of problems due to one piece failing or being unavailable are surely a source of grief for many attempting to play these games online.
If this system was designed this way from scratch, someone should be publicly whipped with a length Ethernet cable. If it is the result of 'evolution' of features and functionality by adding servers to the 'master' pool, the time has come perhaps for EA to rethink the infrastructure and rebuild it from scratch.
In any case, the Schannel error in these games appears to be generated by an improperly configured EA server that provides them with hardware information à la Steam's hardware survey.
Another way to eliminate the error (and stop spying by EA, if that's your stance), is to add the following to the file \windows\system32\drivers\etc\hosts:
127.0.0.1 bf1943hwtelemetry.ea.com
This prevents the game(s) from even starting the handshake process, short-circuiting the error path.
In summary: The error is harmless, it is not the cause of crashes / etc. in the game itself per se though it appears it might throw programs such as A/V into a tizzy (when I feel like it, I may investigate this further.) You can just ignore it, or if it bothers you having it in your event log, take one or both of the steps outlined above.
Showing posts with label Troubleshooting. Show all posts
Showing posts with label Troubleshooting. Show all posts
Wednesday, October 27, 2010
Saturday, May 8, 2010
It's a Small World.
Ugh! I hated that ride at Disneyland when I was a kid! My brothers and sister loved it, so I was forced to sit through it multiple times every visit. I'd rather pass a red hot branding iron through my cranium than hear that cloying tune again.
A few years back, I thought I was on an episode of the Twilight Zone when a friend asked me to troubleshoot their PC. The machine would randomly start playing that very song through the built-in speaker. It took a while to figure that one out!
Believe it or not, it was a feature of the BIOS used as a thermal warning. Certainly one of the more obscure troubleshooting issues I've ever worked (see Computer Randomly Plays Classical Music for a Microsoft Knowledge Base article that resulted from this behavior, and my blog entry One of the more interesting game problem cases I've worked on for another set of really strange symptoms).
Happily, that the Internet makes this a small world delights me. In the short time this blog has been live, we've had visitors from 53 countries spread around the world! Lots of great e-mails have been sent (please, put your thoughts in the comments: let everyone see where we agree, disagree, or where you've found help with game or other technical problems!)
As Dean Martin, the King of Cool used to say: Keep those cards and letters coming in!
A few years back, I thought I was on an episode of the Twilight Zone when a friend asked me to troubleshoot their PC. The machine would randomly start playing that very song through the built-in speaker. It took a while to figure that one out!
Believe it or not, it was a feature of the BIOS used as a thermal warning. Certainly one of the more obscure troubleshooting issues I've ever worked (see Computer Randomly Plays Classical Music for a Microsoft Knowledge Base article that resulted from this behavior, and my blog entry One of the more interesting game problem cases I've worked on for another set of really strange symptoms).
Happily, that the Internet makes this a small world delights me. In the short time this blog has been live, we've had visitors from 53 countries spread around the world! Lots of great e-mails have been sent (please, put your thoughts in the comments: let everyone see where we agree, disagree, or where you've found help with game or other technical problems!)
As Dean Martin, the King of Cool used to say: Keep those cards and letters coming in!
Wednesday, May 5, 2010
Zzzap-a-Dee-Doo-Dah!
Helping a gaming buddy with an upgrade recently, I encountered behavior that reminded me that all the options should be kept open when troubleshooting problems, particularly with hardware. He has a good solid mid-range gaming machine, perhaps slightly handicapped by an aging Nvidia 8800GTS 320MB GPU. He upgraded to one of the new ATI 5850 from ASUS (the most potent card in the price range he wanted that would fit into his case).
The card was installed, and after driver installs and some quick game testing, it appeared that a very worthwhile upgrade had been made.
The next day, when he booted the machine, he noted the fans seemed to be running 'louder' at boot time than the prior evening. In addition, the boot time took an unusually long time, upwards of 45 seconds to get to the Windows start sequence after BIOS post, rather than the normal few seconds. Puzzling.
The first thought was an under performing power supply, but everything checked out fine. Curiously, if the machine was warm started, the fans ran quietly on the GPU but the boot sequence was still agonizingly long. Cold starts resulted in the GPU fans running at top speed, and even longer boot times.
A quick perusal of forums showed multitudes suffering the same issue. Many using the same motherboard as my friend, but no fixes. I decided to violate my normal rules with regards to BIOS updates (if it ain't broke, don't fix it!), and checked the ASUS site for any updates. Sure enough, there was a recent one, and one of the release note items specifically mentioned a fix for slow boot times with certain 5000 series ATI video cards.
Bingo! We cobbled up a quick and dirty DOS boot CD with the latest BIOS and flashing program, and proceeded to flash the BIOS.
The result? The fans of the GPU now ran quietly at boot, and boot times improved for certain, but they were still quite a bit longer than before. I opened up the machine, checking for any seating problems, etc. on the card. All was well. Then I noticed that one of the six pin PCI-E auxiliary connectors (the card uses two) was not using a modular cable to his quite capable power supply, but was using a two-into-one four pin peripheral to six pin PCI-E adapter that came with the card. Both of the four pin ends were connected to one cable of the modular power supply, the only connections to that particular cable.
Now looking at this, I thought it should be okay, though I figured at maximum load (if the card actually draws as much as is allowed), there would be about a quarter volt of voltage drop from the wiring involved. I had thw owner dig up the original power supply box to find if any additional original cables were left, and found exactly what was needed: a correct six pin PCI-E modular cable.
After plugging this in, the machine behaved as expected. No more loud fans on boot (BIOS related), and no more slow boots (BIOS and power delivery issues).
The moral of the story? Never assume anything when troubleshooting, and always leave your options open.
The card was installed, and after driver installs and some quick game testing, it appeared that a very worthwhile upgrade had been made.
The next day, when he booted the machine, he noted the fans seemed to be running 'louder' at boot time than the prior evening. In addition, the boot time took an unusually long time, upwards of 45 seconds to get to the Windows start sequence after BIOS post, rather than the normal few seconds. Puzzling.
The first thought was an under performing power supply, but everything checked out fine. Curiously, if the machine was warm started, the fans ran quietly on the GPU but the boot sequence was still agonizingly long. Cold starts resulted in the GPU fans running at top speed, and even longer boot times.
A quick perusal of forums showed multitudes suffering the same issue. Many using the same motherboard as my friend, but no fixes. I decided to violate my normal rules with regards to BIOS updates (if it ain't broke, don't fix it!), and checked the ASUS site for any updates. Sure enough, there was a recent one, and one of the release note items specifically mentioned a fix for slow boot times with certain 5000 series ATI video cards.
Bingo! We cobbled up a quick and dirty DOS boot CD with the latest BIOS and flashing program, and proceeded to flash the BIOS.
The result? The fans of the GPU now ran quietly at boot, and boot times improved for certain, but they were still quite a bit longer than before. I opened up the machine, checking for any seating problems, etc. on the card. All was well. Then I noticed that one of the six pin PCI-E auxiliary connectors (the card uses two) was not using a modular cable to his quite capable power supply, but was using a two-into-one four pin peripheral to six pin PCI-E adapter that came with the card. Both of the four pin ends were connected to one cable of the modular power supply, the only connections to that particular cable.
Now looking at this, I thought it should be okay, though I figured at maximum load (if the card actually draws as much as is allowed), there would be about a quarter volt of voltage drop from the wiring involved. I had thw owner dig up the original power supply box to find if any additional original cables were left, and found exactly what was needed: a correct six pin PCI-E modular cable.
After plugging this in, the machine behaved as expected. No more loud fans on boot (BIOS related), and no more slow boots (BIOS and power delivery issues).
The moral of the story? Never assume anything when troubleshooting, and always leave your options open.
Wednesday, April 28, 2010
I ♥ Windows 7 Event Logging!
I was recently debugging a couple of applications, and was trapping some events as part of the process. I forget how useful the Event Viewer is in general, and particularly with the greatly enhanced functionality in Windows 7/Vista.
Two of the really cool features are the ability to build sophisticated custom filters and views, allowing you to focus on exactly what you're looking for, and the ability to create events on events.
For example, the following XPath query for a filter/view allows me to trap a specific event for a specifc PID, excluding all other 'noise' in the event log:
<QueryList>
<Query Id="0"
Path="Microsoft-Windows-Winsock-AFD/Operational">
<Select Path="Microsoft-Windows-Winsock-AFD/Operational">
*[System[Execution[@ProcessID="3141"]]]
and *[System[EventID="1000"]]
</Select>
</Query>
</QueryList>
Equally cool, I can assign tasks to any event/view/filtered view such that the system will notify me with a dialog, E-Mail me, or start any arbitrary program.
Hugely useful, allowing efficient, quick & dirty debugging without even needing to fire up a real debugger, and as an incredibly useful ancillary to formal debugging.
Two of the really cool features are the ability to build sophisticated custom filters and views, allowing you to focus on exactly what you're looking for, and the ability to create events on events.
For example, the following XPath query for a filter/view allows me to trap a specific event for a specifc PID, excluding all other 'noise' in the event log:
<QueryList>
<Query Id="0"
Path="Microsoft-Windows-Winsock-AFD/Operational">
<Select Path="Microsoft-Windows-Winsock-AFD/Operational">
*[System[Execution[@ProcessID="3141"]]]
and *[System[EventID="1000"]]
</Select>
</Query>
</QueryList>
Equally cool, I can assign tasks to any event/view/filtered view such that the system will notify me with a dialog, E-Mail me, or start any arbitrary program.
Hugely useful, allowing efficient, quick & dirty debugging without even needing to fire up a real debugger, and as an incredibly useful ancillary to formal debugging.
Monday, April 26, 2010
Pings? We Don't Need No Stinking Pings!
The popular new online FPS Battlefield Bad Company 2 has had its share of teething pains. Among those most bothersome to players is the inability to see 'pings' for servers in the online server browser. The developers, EA/DICE, have stated the solution to this issue is to run the game with elevated privileges, either by running in a full administrator account, or by using RunAs or compatibility mode changes to accomplish this.
Poppycock! The fix is to get rid of the poor coding choices that get this kind of result from my debugging traces of over a month ago:
socket: 0: Process 0xfffffa8005375060 (0x768 ), Endpoint 0xfffffa8005c49420, Family 2, Type SOCK_RAW, Protocol 1, Seq 1006, Status 0x0
(FAM: AF_Inet/IPv4) (SOCK: Raw) (PROTO: Stream)
The game is opening (or attempting to open) a Windows socket of type (3) sock_raw. The use of raw sockets has become increasingly restricted with each new version of Windows, and for good reason.
This is the reason the BFBC2 game executable must be run as an administrator, or have its privileges elevated, for the player to see pings properly in the server browser.
Readers having this issue, either run the game from a 'real' administrative account, or right-click on the game executable and mark it for compatibility mode "Run this program as an administrator". Do note, there can be other issues such as firewall, ISP, or PC configuration that may still prevent pings showing properly.
There is no reasonable reason I can think of that an application like this game needs to use raw sockets, forcing the user to compromise the security and functionality of their system to make the application work the way it should. There are several proper solutions to accomplish the goal of getting the needed data that do not require unneeded privilege use or elevation by the user.
That this information was handed to the devs, and nothing has been done to remedy it, despite a patch in the intervening time being released, is puzzling to say the least. A lunch hour's worth of coding changes should fix this amateur mistake that should never have been made. (How hard is it to get to the server without raw sockets? See "I Scream, You Scream, We All Scream for DICE Scream!" for an answer).
Fix this, DICE!
Poppycock! The fix is to get rid of the poor coding choices that get this kind of result from my debugging traces of over a month ago:
socket: 0: Process 0xfffffa8005375060 (0x768 ), Endpoint 0xfffffa8005c49420, Family 2, Type SOCK_RAW, Protocol 1, Seq 1006, Status 0x0
(FAM: AF_Inet/IPv4) (SOCK: Raw) (PROTO: Stream)
The game is opening (or attempting to open) a Windows socket of type (3) sock_raw. The use of raw sockets has become increasingly restricted with each new version of Windows, and for good reason.
This is the reason the BFBC2 game executable must be run as an administrator, or have its privileges elevated, for the player to see pings properly in the server browser.
Readers having this issue, either run the game from a 'real' administrative account, or right-click on the game executable and mark it for compatibility mode "Run this program as an administrator". Do note, there can be other issues such as firewall, ISP, or PC configuration that may still prevent pings showing properly.
There is no reasonable reason I can think of that an application like this game needs to use raw sockets, forcing the user to compromise the security and functionality of their system to make the application work the way it should. There are several proper solutions to accomplish the goal of getting the needed data that do not require unneeded privilege use or elevation by the user.
That this information was handed to the devs, and nothing has been done to remedy it, despite a patch in the intervening time being released, is puzzling to say the least. A lunch hour's worth of coding changes should fix this amateur mistake that should never have been made. (How hard is it to get to the server without raw sockets? See "I Scream, You Scream, We All Scream for DICE Scream!" for an answer).
Fix this, DICE!
Sunday, April 18, 2010
One of the more interesting game problem cases I've worked on.
A poster in a game forum was pleading for help. A pretty high-end system, all the best components, top-end Windows 7, fresh and clean, along with a clean game install.
All was well until a couple of weeks ago, then load times for the maps went to hell, taking five to eight minutes, with the screen alternating between white and black. Once loaded, selection of menu items or login resulted in another minute or so of stalling.
The poster was using one of the highest-end and newest GPUs that had a known minor issue with load times for the game (but usually only resulting in 30 second or so loads for others, with no stalls once loaded) that had been remedied in a recent GPU driver release.
The poster, and an apparently savvy friend, were pulling their hair out, having tried every option reasonable: reinstall game, windows, no anti-virus, different drivers, disable sound, etc. but still no joy.
This was one of the weird ones. Like the PC of an old friend that would randomly play "It's a small world" out of the internal speaker (that took me a bit to figure out...)
I've been doing this a long time, as many of you probably have, giving us an advantage: We've probably seen it before, and had to figure it out.
The problem: USB bus conflict/flooding. I first saw this a few years back on a fellow gamer's machine, after trying all the obvious things to resolve their strange performance issues, I pulled out my USB bus analyzer, and bingo!
For this poster, simply unplugging all USB devices, then plugging them back in completely solved the issue. The same (actually more thorough) can be done by uninstalling the sub-branches of the USB device branch and rebooting the machine, allowing it to reinstall and enumerate the devices.
This very same problem manifested itself for a couple of players I worked with where their game ran in slow motion, as if time were slowed down. Not laggy game play, in fact no jerkiness of any sort, just six million dollar man slow motion effects for everything in the game!
A cool effect of this was they could FRAPS record game play, and when played back, it was normal speed. Spooky! When I had them do this, I'm sure they must have thought I was pulling some kind of practical joke on them.
The same fix (resetting USB by unplugging their USB devices) remedied the problem.
These strange and obscure ones must make life interesting for tech support.
All was well until a couple of weeks ago, then load times for the maps went to hell, taking five to eight minutes, with the screen alternating between white and black. Once loaded, selection of menu items or login resulted in another minute or so of stalling.
The poster was using one of the highest-end and newest GPUs that had a known minor issue with load times for the game (but usually only resulting in 30 second or so loads for others, with no stalls once loaded) that had been remedied in a recent GPU driver release.
The poster, and an apparently savvy friend, were pulling their hair out, having tried every option reasonable: reinstall game, windows, no anti-virus, different drivers, disable sound, etc. but still no joy.
This was one of the weird ones. Like the PC of an old friend that would randomly play "It's a small world" out of the internal speaker (that took me a bit to figure out...)
I've been doing this a long time, as many of you probably have, giving us an advantage: We've probably seen it before, and had to figure it out.
The problem: USB bus conflict/flooding. I first saw this a few years back on a fellow gamer's machine, after trying all the obvious things to resolve their strange performance issues, I pulled out my USB bus analyzer, and bingo!
For this poster, simply unplugging all USB devices, then plugging them back in completely solved the issue. The same (actually more thorough) can be done by uninstalling the sub-branches of the USB device branch and rebooting the machine, allowing it to reinstall and enumerate the devices.
This very same problem manifested itself for a couple of players I worked with where their game ran in slow motion, as if time were slowed down. Not laggy game play, in fact no jerkiness of any sort, just six million dollar man slow motion effects for everything in the game!
A cool effect of this was they could FRAPS record game play, and when played back, it was normal speed. Spooky! When I had them do this, I'm sure they must have thought I was pulling some kind of practical joke on them.
The same fix (resetting USB by unplugging their USB devices) remedied the problem.
These strange and obscure ones must make life interesting for tech support.
Tuesday, April 6, 2010
How could it possibly be my router causing connection issues?
Thursday, March 18, 2010
Port Forwarding: Slaying the Mythical Dragon of Online PC Gaming.
Every day, in PC game enthusiast forums around the world, posters having connectivity problems (or not) with their PC game are advised 'You need to forward your ports!', usually by posters claiming to be 'experienced gamers' or 'network experts'.
Most blindly follow this advice, not even understanding what it means to 'forward a port', much less the ramifications of doing so. My intent is to set the record straight for the reader, so that they may better understand the how, what, when, why, and where of port forwarding. I have greatly simplified and generalized the terminology and examples, which may offend experts, but is appropriate for the intended audience.
To be clear, forwarding of ports is seldom if ever required to allow the client of the online PC game to function properly. Unnecessarily forwarding ports is not only undesirable, it may expose the gamer to security risks, and can interfere with proper functioning of their environment, including games.
The typical PC gamer has a pretty simple environment: Their PC, a router, a modem (perhaps a unit that combines the two functions of router and modem), and...and that's it. The router serves the function of shepherding traffic from the gamer's local area network (LAN) to the wide area network (WAN), where the online game servers 'live'. The modem provides the electronic means for the gamer to access the WAN infrastructure. In some cases, these two functions (router and modem) are combined into a single unit, variously called a router or modem, depending on who you're asking. Often, gamers have a router in their environment without knowing it - they've been told 'that's your modem'.
Why these pieces of hardware are used comes down to the subject of addresses. Each PC in a network must be assigned a unique address. The gamer is probably familiar with these. They're the number sets like '192.168.1.123' you might see for you PC on your LAN, or the '74.125.19.106' you might see if you ping http://www.google.com/. You've probably heard them called the 'IP address'. The important thing is that each PC must have a unique address. Much like your mail goes to a unique address, if different households could have the same address, you can imagine the mess that would ensue.
Now early in the days of the 'net', the groups defining various standards and protocols decided it would be wise to have addresses that were 'public', that is, known to the world as the address to send to, and 'private', that is, addresses that the 'outside' (WAN) world can't even see. This was done for many reasons including reducing the need for public addresses to be used, and to allow enterprises to split up a 'public' address into one or more internal 'private' addresses.
The router's primary function is to manage, control, and manipulate the barrier between the 'private' LAN and the 'public' WAN.
In a typical environment, the modem provides the connection to the WAN, giving the user on the 'inside' of the modem connection some public IP address on the WAN assigned by their ISP. The router takes the traffic from the PCs on the LAN and passes it on through the modem to the destination server on the WAN. We'll call this the 'request' to the server. The server does whatever it needs to process the request, and responds to the WAN address of the gamer. We'll call this the 'reply' from the server.
The router will keep track of requests sent out to the WAN, and in general only allow traffic from the WAN to a PC on the LAN if it determines that traffic is an appropriate reply from a server to a request from a PC on the LAN. Now the router/modem usually have one, and only one public WAN address assigned to them. What are we to do if we have several PCs on our lan that all want to make requests to the same server on the WAN and get their respective replies? The router does this for us through a mechanism generically called Network Address Translation, or NAT for short. There are many details we won't delve into here, a good overview can be found at http://en.wikipedia.org/wiki/Network_address_translation, with some useful references. Readers that wish a more in depth treatment might use the superb books by Comer at http://www.cs.purdue.edu/homes/dec/.
The problem NAT solves is analogous to sending mail between two apartment buildings. We know the street address where we want to send it (the IP address), and the apartment number. In the IP world, the apartment number is called the 'port'. For our PC game, the game client (what the gamer plays) needs to send requests to the game server(s), and it does so by sending requests to the IP address of the server, and including the port that address should go to on the server. The request needs to have a 'return address' so the server can reply, so the game will add the address of the game client, and the desired return port to the request.
Now as we've said, the client is on a private address. The server can't see this or do anything with it. So the router changes the address information, replacing the private LAN address with its public WAN address, and remembers the return address port for the request. If more than one PC on the LAN make a request to a server and specify the same return port, the router notices this, and changes the return port along with the return IP address, keeping track of which PC corresponds to which requested return port the router sends in the request to the server. When the server replies, it uses the return address of the client, which will be the public IP (WAN) address of the gamer, and the return port, which may have been changed from the actual return port by the router.
When the router sees this traffic, it peeks into the packet and determines which PC belongs to the requested return port. The router changes the return port to the one originally in the PC's request, if needed, changes the return IP address to that of the correct PC, and passes the traffic onto the LAN, where the PC that made the request will receive its reply from the server.
In general, we don't want random traffic coming from the WAN into our LAN. Because the router peeks into traffic to determine if it even belongs on the LAN, random attempts to enter the LAN are thwarted. Unless the user specifically needs to have requests from the WAN enter the lan (to a server of some sort on our LAN to reply to), this is precisely what we desire. Routers usually include some kind of 'firewall' capability, which considerably enhances the security of the client<->server interchanges, and provides even more probative capability toward unsolicited traffic from the WAN. We will not detail firewall functionality.
What if the gamer needs to have a server on the LAN that can be accessed by others on the WAN? How might we accomplish this? This is where the feature of the router called 'port forwarding' comes into play. The user can configure their router, and set it to allow traffic from the WAN to its WAN address into the LAN. The user does this by specifying what PC is going to reply to traffic on which port(s). For example, if we wanted to run our own web server on our LAN (or game server, just change the nomenclature and numbers), it would need to get requests on port 80, the default port number for HTTP (browser) traffic. If the PC running our web server on our LAN had an address of say 192.168.1.2, we would configure the router to forward any traffic from the WAN to its WAN address with a destination port of 80 to the PC at 192.168.1.2. When the web server (or game server) replies to the request, it is sent through the router back to the WAN address of the original requester. The same kinds of manipulations to the address happen via NAT as with the game client example, just in reverse. So forwarding is for clients on the WAN to get to a server on your LAN. Pretty simple, no?
Now, to kill the dragon!
Modern PC games played online need the game client to make requests to the game server. The game server, and other game clients, do not make requests to the game client. There are exceptions to this, namely some peer-to-peer games, and cases where one of the clients is also running the game server on one of their PCs. Both fall into the generalized description of a server from earlier. But in general, modern games are client-server based, where the server is run by a provider on the WAN, and the gamer plays the client on the LAN. At no time do the servers try to make an 'inbound' request to the client. Hence, forwarding of any ports to play the game is completely unnecessary, and accomplishes nothing. Forwarding ports when not explicitly required poses a security risk to the user, and can in fact interfere with proper traffic flow for games.
The game's client makes the requests, the router handles the manipulation and shepherding of the traffic to the server on the WAN and the corresponding reply traffic from the server on the WAN to the game client on the LAN. Not the other way around!
Unfortunately, 'You need to forward your ports!' is one tough dragon to slay, and this myth is constantly perpetuated in forums, and even by occasionally by misinformed game publisher support staff. There are even whole web sites devoted to the subject, with applications to automate this unnecessary and potentially security compromising router feature for the uninformed user.
Unless you are instructed that your game requires ports to be forwarded from an authoritative source (the game manual, the game developers, or in some cases the publisher with the caveat noted earlier), you are likely not required to do it. Abandon all hope ye that consider enthusiast forums to be an authoritative source!
To humanize it, think of it this way: You, in your household, act as the 'router' and 'firewall' in a way for traffic in and out of your house (your LAN). You, and others in the house are free to go out from the house to seek information (onto the WAN). When someone comes knocking at the door with the answer, you can peek through the peephole on your door and decide if you expected them, and let them into your house. If a stranger comes knocking, you're likely to decide they're uninvited, and not let them in. Port forwarding is giving a stranger the key to your door. In fact, its giving the key to your door to everyone in the world that knows how to get to your door! The 'experienced gamers' and 'net experts' that tell you there's no danger in forwarding ports when it's not explicitly required are doing just that: telling you it's OK to give the key to your front door to everyone on the planet. I'd venture most intelligent readers wold never subscribe to such nonsense.
How many readers in game enthusiast forums do you think blindly forward ports to 'fix' problems? How many of those same readers will download the latest coolest 'tweak tool' for the game when offered up on the forum? How hard do you think it would be to perhaps list some real ports for the game, and throw an extra one in that the later downloaded 'tweak tool' actually listens on, allowing a remote intruder in to the victim's PC to run amok? If you don't know how to verify exactly why a game should need ports forwarded, exactly which ports should be forwarded, and know exactly how to do this, you probably shouldn't. Since port forwarding, with a properly configured and behaving modem/router is not needed by any modern PC game client, you probably shouldn't anyway.
Before ending and in all fairness, it should be noted that some misbehaving or otherwise buggy routers can be 'worked around' by forwarding ports where this would not normally be required. Part of this 'You need to forward your ports!' malarkey is undoubtedly from uniformed users seeing this 'fix' an issue, not understanding that the problem in fact is elsewhere and the 'fix' is a bandage that may cause other problems and security issues. Used properly, this can allow routers that restrict the user to NAT other than Type 1/Cone to mimic a properly behaving full-cone router for a game. This will of course be limited to only one PC on the LAN side and will not allow multiple players to simultaneously play from the LAN if this work-around is needed. See Troubleshooting Multi-Player PC Game Connectivity Issues for examples of this.
I hope after reading this, the reader has a clarified understanding of what port forwarding is, and when its use is appropriate.
Most blindly follow this advice, not even understanding what it means to 'forward a port', much less the ramifications of doing so. My intent is to set the record straight for the reader, so that they may better understand the how, what, when, why, and where of port forwarding. I have greatly simplified and generalized the terminology and examples, which may offend experts, but is appropriate for the intended audience.
To be clear, forwarding of ports is seldom if ever required to allow the client of the online PC game to function properly. Unnecessarily forwarding ports is not only undesirable, it may expose the gamer to security risks, and can interfere with proper functioning of their environment, including games.
The typical PC gamer has a pretty simple environment: Their PC, a router, a modem (perhaps a unit that combines the two functions of router and modem), and...and that's it. The router serves the function of shepherding traffic from the gamer's local area network (LAN) to the wide area network (WAN), where the online game servers 'live'. The modem provides the electronic means for the gamer to access the WAN infrastructure. In some cases, these two functions (router and modem) are combined into a single unit, variously called a router or modem, depending on who you're asking. Often, gamers have a router in their environment without knowing it - they've been told 'that's your modem'.
Why these pieces of hardware are used comes down to the subject of addresses. Each PC in a network must be assigned a unique address. The gamer is probably familiar with these. They're the number sets like '192.168.1.123' you might see for you PC on your LAN, or the '74.125.19.106' you might see if you ping http://www.google.com/. You've probably heard them called the 'IP address'. The important thing is that each PC must have a unique address. Much like your mail goes to a unique address, if different households could have the same address, you can imagine the mess that would ensue.
Now early in the days of the 'net', the groups defining various standards and protocols decided it would be wise to have addresses that were 'public', that is, known to the world as the address to send to, and 'private', that is, addresses that the 'outside' (WAN) world can't even see. This was done for many reasons including reducing the need for public addresses to be used, and to allow enterprises to split up a 'public' address into one or more internal 'private' addresses.
The router's primary function is to manage, control, and manipulate the barrier between the 'private' LAN and the 'public' WAN.
In a typical environment, the modem provides the connection to the WAN, giving the user on the 'inside' of the modem connection some public IP address on the WAN assigned by their ISP. The router takes the traffic from the PCs on the LAN and passes it on through the modem to the destination server on the WAN. We'll call this the 'request' to the server. The server does whatever it needs to process the request, and responds to the WAN address of the gamer. We'll call this the 'reply' from the server.
The router will keep track of requests sent out to the WAN, and in general only allow traffic from the WAN to a PC on the LAN if it determines that traffic is an appropriate reply from a server to a request from a PC on the LAN. Now the router/modem usually have one, and only one public WAN address assigned to them. What are we to do if we have several PCs on our lan that all want to make requests to the same server on the WAN and get their respective replies? The router does this for us through a mechanism generically called Network Address Translation, or NAT for short. There are many details we won't delve into here, a good overview can be found at http://en.wikipedia.org/wiki/Network_address_translation, with some useful references. Readers that wish a more in depth treatment might use the superb books by Comer at http://www.cs.purdue.edu/homes/dec/.
The problem NAT solves is analogous to sending mail between two apartment buildings. We know the street address where we want to send it (the IP address), and the apartment number. In the IP world, the apartment number is called the 'port'. For our PC game, the game client (what the gamer plays) needs to send requests to the game server(s), and it does so by sending requests to the IP address of the server, and including the port that address should go to on the server. The request needs to have a 'return address' so the server can reply, so the game will add the address of the game client, and the desired return port to the request.
Now as we've said, the client is on a private address. The server can't see this or do anything with it. So the router changes the address information, replacing the private LAN address with its public WAN address, and remembers the return address port for the request. If more than one PC on the LAN make a request to a server and specify the same return port, the router notices this, and changes the return port along with the return IP address, keeping track of which PC corresponds to which requested return port the router sends in the request to the server. When the server replies, it uses the return address of the client, which will be the public IP (WAN) address of the gamer, and the return port, which may have been changed from the actual return port by the router.
When the router sees this traffic, it peeks into the packet and determines which PC belongs to the requested return port. The router changes the return port to the one originally in the PC's request, if needed, changes the return IP address to that of the correct PC, and passes the traffic onto the LAN, where the PC that made the request will receive its reply from the server.
In general, we don't want random traffic coming from the WAN into our LAN. Because the router peeks into traffic to determine if it even belongs on the LAN, random attempts to enter the LAN are thwarted. Unless the user specifically needs to have requests from the WAN enter the lan (to a server of some sort on our LAN to reply to), this is precisely what we desire. Routers usually include some kind of 'firewall' capability, which considerably enhances the security of the client<->server interchanges, and provides even more probative capability toward unsolicited traffic from the WAN. We will not detail firewall functionality.
What if the gamer needs to have a server on the LAN that can be accessed by others on the WAN? How might we accomplish this? This is where the feature of the router called 'port forwarding' comes into play. The user can configure their router, and set it to allow traffic from the WAN to its WAN address into the LAN. The user does this by specifying what PC is going to reply to traffic on which port(s). For example, if we wanted to run our own web server on our LAN (or game server, just change the nomenclature and numbers), it would need to get requests on port 80, the default port number for HTTP (browser) traffic. If the PC running our web server on our LAN had an address of say 192.168.1.2, we would configure the router to forward any traffic from the WAN to its WAN address with a destination port of 80 to the PC at 192.168.1.2. When the web server (or game server) replies to the request, it is sent through the router back to the WAN address of the original requester. The same kinds of manipulations to the address happen via NAT as with the game client example, just in reverse. So forwarding is for clients on the WAN to get to a server on your LAN. Pretty simple, no?
Now, to kill the dragon!
Modern PC games played online need the game client to make requests to the game server. The game server, and other game clients, do not make requests to the game client. There are exceptions to this, namely some peer-to-peer games, and cases where one of the clients is also running the game server on one of their PCs. Both fall into the generalized description of a server from earlier. But in general, modern games are client-server based, where the server is run by a provider on the WAN, and the gamer plays the client on the LAN. At no time do the servers try to make an 'inbound' request to the client. Hence, forwarding of any ports to play the game is completely unnecessary, and accomplishes nothing. Forwarding ports when not explicitly required poses a security risk to the user, and can in fact interfere with proper traffic flow for games.
The game's client makes the requests, the router handles the manipulation and shepherding of the traffic to the server on the WAN and the corresponding reply traffic from the server on the WAN to the game client on the LAN. Not the other way around!
Unfortunately, 'You need to forward your ports!' is one tough dragon to slay, and this myth is constantly perpetuated in forums, and even by occasionally by misinformed game publisher support staff. There are even whole web sites devoted to the subject, with applications to automate this unnecessary and potentially security compromising router feature for the uninformed user.
Unless you are instructed that your game requires ports to be forwarded from an authoritative source (the game manual, the game developers, or in some cases the publisher with the caveat noted earlier), you are likely not required to do it. Abandon all hope ye that consider enthusiast forums to be an authoritative source!
To humanize it, think of it this way: You, in your household, act as the 'router' and 'firewall' in a way for traffic in and out of your house (your LAN). You, and others in the house are free to go out from the house to seek information (onto the WAN). When someone comes knocking at the door with the answer, you can peek through the peephole on your door and decide if you expected them, and let them into your house. If a stranger comes knocking, you're likely to decide they're uninvited, and not let them in. Port forwarding is giving a stranger the key to your door. In fact, its giving the key to your door to everyone in the world that knows how to get to your door! The 'experienced gamers' and 'net experts' that tell you there's no danger in forwarding ports when it's not explicitly required are doing just that: telling you it's OK to give the key to your front door to everyone on the planet. I'd venture most intelligent readers wold never subscribe to such nonsense.
How many readers in game enthusiast forums do you think blindly forward ports to 'fix' problems? How many of those same readers will download the latest coolest 'tweak tool' for the game when offered up on the forum? How hard do you think it would be to perhaps list some real ports for the game, and throw an extra one in that the later downloaded 'tweak tool' actually listens on, allowing a remote intruder in to the victim's PC to run amok? If you don't know how to verify exactly why a game should need ports forwarded, exactly which ports should be forwarded, and know exactly how to do this, you probably shouldn't. Since port forwarding, with a properly configured and behaving modem/router is not needed by any modern PC game client, you probably shouldn't anyway.
Before ending and in all fairness, it should be noted that some misbehaving or otherwise buggy routers can be 'worked around' by forwarding ports where this would not normally be required. Part of this 'You need to forward your ports!' malarkey is undoubtedly from uniformed users seeing this 'fix' an issue, not understanding that the problem in fact is elsewhere and the 'fix' is a bandage that may cause other problems and security issues. Used properly, this can allow routers that restrict the user to NAT other than Type 1/Cone to mimic a properly behaving full-cone router for a game. This will of course be limited to only one PC on the LAN side and will not allow multiple players to simultaneously play from the LAN if this work-around is needed. See Troubleshooting Multi-Player PC Game Connectivity Issues for examples of this.
I hope after reading this, the reader has a clarified understanding of what port forwarding is, and when its use is appropriate.
Wednesday, March 17, 2010
Troubleshooting Multi-Player PC Game Connectivity Issues
Here lies the original post that started this blog, a troubleshooting guide for PC gamers. This guide provides suggestions for possible solutions to common, and not so common connectivity problems.
The suggestions are presented in a form generalized enough to prevent the document from becoming a book (and it's already plenty long), but not so much so that they become useless.
Using these suggestions with the details provided, along with resources on the web, your hardware and software documentation and Google should you need to do low-level changes where step-by-step details would have been impractical to provide for reasons of document length or where steps vary wildly for differing equipment, you should be able to resolve your connection problems.
Regardless, do note that this is not for the faint of heart: there is a lot of ground to cover and many subtleties regarding PC game connectivity and issues involved in troubleshooting problems.
You can view the current incarnation of this document at:
Please leave any comments and suggestions here, or via e-mail as shown in the document.
The suggestions are presented in a form generalized enough to prevent the document from becoming a book (and it's already plenty long), but not so much so that they become useless.
Using these suggestions with the details provided, along with resources on the web, your hardware and software documentation and Google should you need to do low-level changes where step-by-step details would have been impractical to provide for reasons of document length or where steps vary wildly for differing equipment, you should be able to resolve your connection problems.
Regardless, do note that this is not for the faint of heart: there is a lot of ground to cover and many subtleties regarding PC game connectivity and issues involved in troubleshooting problems.
You can view the current incarnation of this document at:
Please leave any comments and suggestions here, or via e-mail as shown in the document.
Subscribe to:
Posts (Atom)
Posts
