Showing posts with label port forwarding. Show all posts
Showing posts with label port forwarding. Show all posts

Sunday, December 23, 2012

Battlefield 3 Disconnects

For months I'd been having issues with lag and stuttering in the PC version of Battlefield 3. Worse, though, were frequent, seemingly random disconnects.

I'd connect to a server, be able to play for 10 minutes or more, then my system would lock up hard, unresponsive even to Ctrl-Alt-Del for a few minutes until finally BF3 exited and the Battlelog site came back with anything from a disconnect message to one saying I'd been kicked from the server. 

Despite having the latest updates to BF3 itself, as well as for EA's bloated and unnecessary Origin software, PunkBuster, and my system's video drivers and Windows updates, the disconnects continued to occur, making it so that I seldom if ever got to the end of a round without being disconnected.

Finally I decided to take the plunge and configure my DSL router with port forwarding specific to BF3's needs, according to this page on EA's support site.

The site handily provides instructions specific to many router makes and models for the PC, XBox 360, and PS3 versions of Battlefield 3. One note, for the listed TCP ports specific to the PC version, I found that all but ports 80 (http) and 443 (https) were necessary to seemingly work around the disconnect issues I'd been having. You might need these ports forwarded if you plan to have your PC act as a BF3 server, but given that I don't it doesn't seem to make a difference.

Why the BF3 installer or the game itself doesn't specifically tell you which ports to forward in the beginning I don't know. Why EA and DICE rush out their games hurriedly without addressing their users' complaints, I don't know either. I'm happy to have found this works around my problem, and that the game is at least playable for more than 10 minutes or so at a time, but given their track record with previous games and their various issues, I'd like to see BF3 go open source someday and get in the hands of numerous software developers who would likely care more about the game and its users than EA.

Friday, January 20, 2012

DD-WRT Port Forwarding Problems

Recently I bought a Buffalo WZR-HP-G300NH wireless router accompanied with a branded version of the popular third-party linux-based firmware DD-WRT to replace my previous router, also a Buffalo but an older model, the WHR-HP-G54
Buffalo WZR-HP-G300NH2, my soon-to-be-nemesis.

My old router ran rock solid for 5+ years' worth of torrenting and wireless and innumerable bits of data transfer until inexplicably one day a power surge appeared to have killed the wireless. Wireless is too handy not to have, so I bid my venerable router farewell. I figured this also would be the opportunity to do something I hadn't tried in some time, host a web server on my local machine. My ISP doesn't block port 80, so I figured I could pretty easily set up port forwarding and invite some folks to test out a site I've been developing.

I began by setting up Port Forwarding for TCP port 80 to my computer's IP address on my LAN in DD-WRT. I also used DynDNS to redirect a custom public URL to the dynamic IP address assigned by my ISP. Curiously, after rebooting the router, for some reason port 80 traffic returned "The connection has timed out" in Firefox, not only when I tried to hit the URL from a remote session to a computer at my office, but even using that same URL or even the local IP address on my own LAN. 

To rule out the possibility of my ISP blocking port 80 traffic, I tried setting up a spare Linksys WRTG54 v6 router I had lying around, using its factory firmware to set up a port forwarding rule. This worked fine, so clearly my ISP was not to blame. Indeed, a visit to CanYouSeeMe confirmed that port 80 was closed off to the outside world.

Undaunted, I decided to upgrade to the newest firmware from the manufacturer's support site. Buffalo seems to have had a bit of a disconnect with their product labeling. Whereas I thought I'd ordered the WZR-HP-G300NH, the model number on the router itself indicated it was actually a WZR-HP-G300NH2, which turns out to have different internals. The product dropdown list indicated two flavors of this particular router, both indicating WZR-HP-G300NH, and to the far right, one indicated as v1, the other v2.

This in itself was no big deal until I tried updating to the latest available firmware from Buffalo's support site. I assumed WZR-HP-G300NH2 corresponded to the entry for WZR-HP-G300NH v2, and chose the firmware accordingly. I proceeded to update the firmware via DD-WRT installed at the factory, and even got a message that the update went successfully and that the router commenced a reboot. Minutes passed, the DIAG light on the router flashing for a while, at first, but then ominously steady.

I left it for an hour to grab something to eat. When I returned, the steady DIAG stared me in the face. I went ahead and cycled power on the router, and the DIAG again stayed steady. Worse, the router's DHCP appeared dead, leaving Windows to assign the default IP via its APIPA, a fallback in case the router doesn't give out an IP address dynamically. The router didn't even respond when I assigned a static IP in its default subnet.

My shiny new router became officially bricked.

I managed to unbrick the router thanks to this blog post and at least install a compatible build of DD-WRT contributed by Brainslayer, a DD-WRT forum user, located on the DD-WRT FTP site here

Incidentally, the DD-WRT Router Database is currently clueless about the existence of the G300NH2 version of the router; the "official" build of DD-WRT I downloaded on the off chance it might work (wzr-hp-g300nh-dd-wrt-webupgrade-MULTI.bin) upgraded fine, according to the DD-WRT web interface, but the router bricked shortly after rebooting without any message indicating failure. Attempting to use this same build to upgrade via TFTP returned "Unsupport MODEL." which seems to indicate that the GUI overlooked the crucial problem with trying to apply a firmware that the router's most basic boot code recognized as an incompatible version... but I digress!

I then researched port forwarding issues and posted details to the DD-WRT forums as well as ServerFault, and although I was able to fix the issue with port forwarding failing from a computer on the LAN thanks to a workaround posted on the forums, no matter what DD-WRT build I tried, external port forwarding failed.

After literally dozens of attempts to reflash the firmware with various builds of DD-WRT, searching for alternative firmwares like Tomato and HyperWRT only to find that they support the G300NH, not the G300NH2, I finally settled on OpenWRT. They, at least, have a wiki specific to the v2 version of the router, albeit one that doesn't appear toward the top of the search results. I also found a wiki for the v1 model, riddled with warnings about the mysterious hardware discrepancies between the v1 and v2 models, interspersed with various "fix me" tags which didn't bode well.

Fix Me? Warning?? Super.

Unfortunately, a big disappointment for me was OpenWRT's lack of a native web interface. I've used Linux so that's not so much of a problem, it's just more scripting and typing that I'd rather relegate to a web interface designed for the job. DD-WRT is leaps and bounds ahead of OpenWRT as far as its web interface is concerned.

Nevertheless, I found a separate web interface for OpenWRT named LuCI. I used the same TFTP method I'd utilized to unbrick the router to install OpenWRT itself, then proceeded to download and install LuCI. This seemingly simple process caused tremendous grief for several reasons, mainly through inconsistent documentation and aggravatingly terse responses to questions in myriad forum posts.

Case in point, I encountered numerous forum postings where someone reasonable familiar with Linux tries following steps outlined in the wiki to install the firmware and the web interface, but encounters a build error. All too often, the expert response to this conundrum essentially was "just do it this way" or "that's what you get for doing x instead of y".

Questions came to mind. Do what which way? How should I try what you're suggesting? What the hell is the context of this task with which you are intimately familiar, but which I, a mere Linux tourist, am unaware of? Those aren't the kind of replies that facilitate a satisfactory resolution of a problem. At best they're static, at worst they're a brush-off by someone who thinks they're doing you a tremendous service by graciously responding to your plea for advice with a few vague words.

As of now, my once bricked router is successfully running OpenWRT with LuCI. BONUS, port forwarding works!

From LuCI, clicking on Network => Firewall and then the Add button under the Redirections section lets you set up a forwarding rule. OpenWRT with LuCI may not win in the intuitive web interface department, but that's far less important than being able to freakin' port foward!

Problem solved, and thus ends a journey down a road I hope to never take again. If somehow I'm stuck having to go this route (pun intended) once again, I'm taking this router out back and crushing it to dust with a sledgehammer (its potential replacement is already en route from NewEgg just in case).