At Wit's End with Wii Wireless

A couple of weeks ago, I snagged a Nintendo Wii on a Sunday morning from a Target in my area that had gotten a shipment during the week and had released them for sale as their new ad flyer featuring the Wii came out that Sunday.

As I've previously posted, I have a Linksys BEFW11S4 wireless router, hardware revision version 4.

When I initially set up the Wii for wireless connectivity with the router, it worked like a charm. I was able to connect, and the various online functionality -- the store, news, weather, web browsing, and the "Everybody Votes" application -- all worked just fine.

However, the next day, the Wii reported that it was unable to connect to the Internet. I reset the router (by disconnecting it from wall power for a couple of seconds and then plugging it back in), and the Wii was once again able to connect successfully.

I knew to try resetting the router because I recognized the behavior as the same as what my TiVo has been exhibiting -- the TiVo will work normally for about a week, but then report that TV program data is low because it hasn't been able to successfully connect to the server, and I'll need to reset the router to get it to connect successfully again.

This problem hadn't been terribly annoying when just the TiVo was affected, since it wasn't too bad to just briefly pull the plug on the router once a week or so (since the TiVo is able to get TV program data for about a week in advance each time it connects). With the Wii, though, it will usually only go about half a day or so before it will lose the wireless connection and be unable to reconnect; this means that pretty much any time I want to use any of the online functionality of the Wii, I need to run upstairs to my office and pull the plug on the router first. And even then, the Wii takes longer than it should to display the news, since it didn't have a chance to download it in the background earlier while the system was idle via the "WiiConnect24" feature, and instead needs to download it on-the-fly. Annoying!

My desktop PCs, which are connected to the router via wired connections, aren't affected by this issue. Further, although I use my PDA's wireless connection functionality at home only infrequently, I've also never observed it be affected by the issue; the PDA seems to be able to connect with no trouble, even at times when the Wii won't connect.

The problem does seem to be with the router as opposed to with the Wii, since the TiVo is affected by the same problem.

It's a frustrating problem to troubleshoot, since each time I change a setting on my router to try and address the problem, I need to wait at least half a day before the Wii's connection will fail again (and thus establish that the attempted fix didn't work).

I've tried the following steps so far to fix the problem, one at a time; none have been successful so far:

• Assigned the Wii a fixed IP address (and DHCP server IPs) rather than having it pick up an IP via DHCP.
• Changed the broadcast channel of the router. (Tried channels 1, 2, 6, and 11).
• Disabled the WEP security on the router. (Turned it back on afterwards after this didn't help.)
• Disabled restriction of clients permitted to connect based on the client MAC address. (Re-enabled this after it didn't help.)
• Reverted the firmware from 1.52.02 (the latest version) back to 1.50.14, after reading online about people having (unrelated) problems with the 1.52.02 firmware.
• Changed the router's "Internet Connection Type" setting from "Connect on Demand" to "Keep Alive", thinking that maybe if my router's DHCP IP address lease from my ISP had expired, then the wireless connection from the Wii wasn't for whatever reason triggering the router to request a new IP, and that this setting change might trigger the router to always make sure that it had a current IP.

Unfortunately, none of these attempted solutions have had any impact on the problematic behavior. (After I applied the firmware version downgrade, I thought that might have done the trick since the Wii behaved itself for a little over a day after that, but the problem subsequently returned, just as before.)

I also haven't been able to find anything about this specific problem by searching around online. I've seen lots of posts about problems where people can't get the wireless connection to work at all, or where specific areas of functionality (like the online store) won't work, but no posts about this type of problem where the connection just seems to expire or time out after several hours.

At this point I feel like my best option to address the problem is to just pick up a new router, but I hesitate to throw $50 at the problem to fix it, since it really is just an annoyance.

If anyone knows of a fix for this issue, or even just has a suggestion for something else to try that might fix the problem, by all means please let me know! I'll update this post if I ever do come up with a solution for this issue.

Update 5/4/2007: Everything is working once again now! The Wii and the Tivo are now able to connect to the Internet over the wireless connection on a daily basis with no problem. So what did I change?

Nothing!... except that I left the BEFW11S4 router powered off for about 9 days straight while my family and I were away from home on vacation! When I returned and powered the router back up, everything started working fine. Prior to that, I had always had the router plugged in around the clock (except when I'd unplug it for a few seconds at a time to get the Wii and Tivo connectivity temporarily working again).

So if you're having this problem and have tried everything else, you could try unplugging your router for a while, perhaps overnight, or longer if you can get away with it. I'm not sure why this solution worked in my case -- maybe some hardware component in the router had overheated and needed some time unplugged to cool down? -- but I'm happy that things are working once again!

Possible fix: IE7 won't show Favicon

I ran into a problem this morning where my install of Internet Explorer 7 was refusing to show the new favicon that I had dropped into the root directory of the website on my local IIS 5 installation for web pages hosted on the server. (Previously, the site had been running without any favicon.)

(A "favicon" is the icon image that gets displayed in the browser's address bar and as the bookmark icon, among other places, for websites that are designed to take advantage of that functionality. For example, the University of Michigan site uses a maize-and-blue "M" icon as the favicon. Note that in IE6, you need to bookmark a site and load that site back from the bookmark before the favicon will display in the address bar.)

Although all the reading I had done suggested that IE7 has full support for favicons, the new icon wasn't being displayed for any of the pages on my site; IE7 would instead just show the generic "IE document" icon. The icon did display correctly in Firefox, and also in another copy of IE on a different machine. Looking at the web server's IIS log, I could see that IE7 wasn't even attempting to request the favicon.ico file from the server.

I tried some simple workarounds to try and trigger IE7 to request the new icon, such as clearing IE's temporary internet files and re-bookmarking the web site, but didn't have any luck. And I could see that my IE7's support for favicons wasn't totally broken, as other sites in my bookmarks (favorites) list did still correctly display their favicons.

After spending a fair amount of time researching the problem across various websites and newsgroup postings, I finally came across a suggested workaround/solution at Wickham's XHTML & CSS tutorial (thanks Wickham!) that ended up fixing the problem for me. The workaround was to clear my IE7 browsing history. (Ctrl+H to bring up the History panel, then select each of the top-level items and delete them with the Delete key).

After clearing my IE history and closing and reopening the browser window, the favicon finally did display properly.

I'm unable to reproduce the issue now; my copy of IE7 is now correctly immediately picking up changes when I remove the favicon.ico file or drop a different favicon.ico into place, so I can't be certain that deleting the IE7 history (which admittedly seems like an odd solution) was what actually fixed the problem. Still, I'm posting this here in hopes that the workaround of clearing IE7's browsing history might be helpful to anyone else who is having a similar problem getting IE7 to properly show a particular website's favicon.

Update 3/7/2007: Jeff Davis ("jeffdav") from the Microsoft Internet Explorer team has posted to his blog a troubleshooting guide for favicons in IE7. It actually does mention clearing browsing history as a possible fix for favicons not showing up as expected. Go check it out if you're having trouble with favicons in IE7! (Thanks for the info, Jeff!)

My 60-second RSS primer

If you're already reading this and other technical blogs, there's a good chance that you're already familiar with RSS feeds. I wrote this 60-second primer to explain RSS for a co-worker today, and I thought I'd share it here as well for any other RSS beginners out there. Everyone was a beginner once!

RSS stands for Really Simple Syndication. It's a way for you to "subscribe" to frequently-updated web sites such as blogs, and be notified any time there is new content available on each site. Further, you can use an "RSS Reader" application to manage all of your subscriptions, and to read all of the new content from within the reader application.

Why bother with using an RSS reader instead of just directly visiting the website of each individual blog that you like to read? Here are two pretty good reasons:

(1) You don't have to spend time visiting a site only to find that it hasn't been updated since your last visit.

(2) It's faster to skim/read all of the new content from the sites that have been updated from a single centralized location, instead of having to visit them all individually.

How do you know if a site provides an RSS feed of its content? Such sites will generally display a small orange RSS icon somewhere on the page: In Firefox, the RSS icon be displayed at the right end of the browser's address bar when you're at a site that provides an RSS feed. You can generally copy-and-paste the site URL into your RSS reader to subscribe to the site's RSS feed. In Firefox 2 you can just click on the orange icon in the address bar, and it will automatically handle the subscription for you, if you already have an RSS reader program set up.

Here are a couple of links for you to get started with. The RSS reader I use is a free web-based application called Bloglines, located at http://www.bloglines.com One of my favorite blogs to read is Jeff Atwood's "Coding Horror" technology issues blog at http://www.codinghorror.com/blog/.

Windows Forms in IE don't load properly in ASP.NET AJAX 1.0

I'm currently running into a problem where Windows Forms .NET controls embedded in a web page, when included in an ASP.NET AJAX UpdatePanel, fail to load properly after the UpdatePanel is updated. An "x" icon is displayed where the control should be.

For a simple UserControl that would normally appear like this:

This is displayed instead after the AJAX update:

Unfortunately, I haven't been able to figure out the root cause of this issue yet. I took a look at the post-update HTML (using a trick from Rumen Stankov -- thanks Rumen!) generated by ASP.NET AJAX, and the HTML looks to be ok.

The problem can be reproduced using a simple .aspx page:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
 <title>ASP.NET AJAX and Windows Forms</title>
</head>
<body>
 <form id="form1" runat="server">
   <asp:ScriptManager ID="ScriptManager1" runat="server" />
   <asp:UpdatePanel ID="_gaugesUpdatePanel" UpdateMode="Conditional" runat="server" >
     <Triggers>
       <asp:AsyncPostBackTrigger ControlID="_updateButton" />
     </Triggers>
     <ContentTemplate>
       <object id="TestControl" name="TestControl"
         classid="TestControl.dll#TestControl.SimpleUserControl"
         height="100" width="200">
       </object>
     </ContentTemplate>
   </asp:UpdatePanel>
   <asp:Button ID="_updateButton" Text="Update" runat="server" />
 </form>
</body>
</html>

When this page initially loads, the Windows Forms control displays correctly. After the "Update" button is clicked (triggering the UpdatePanel to be updated), the control fails to load and the "x" icon is displayed.

For this sample, the "Default.aspx.cs" codebehind page is just the default empty page generated by Visual Studio, and the TestControl.dll is a .Net library with a single simple UserControl, "SimpleUserControl", which just displays itself with a gray background and the "SimpleUserControl" label (as shown above).

The issue is reproducible on both Internet Explorer 6 and Internet Explorer 7.

When the issue occurs, I don't see any warnings or errors recorded in the Fusion Bind log, the web server's IIS log, or the client's Application Event log. (IE is generally pretty bad about providing any detailed error information when something goes wrong with loading a .Net control embedded in a web page, but there is usually at least some information recorded in one or more of these logs.)

My dev group is opening an incident with Microsoft Support for this issue. If we end up getting a workaround from them, or if I am able to come up with a workaround on my own, I'll update this post with the new information.

Update 3/6/2007: I've now discussed this issue over email and phone with Adam S., a member of Microsoft's ASP.NET developer support team.

Adam put together a simplified repro case for this issue with a simple .html (rather than .aspx) page showing that the problem isn't directly with the ASP.NET AJAX controls, but rather with Internet Explorer's implementation of displaying a Windows Forms .Net control that has been placed on a page by setting the innerHTML property of a <div> element with HTML that includes the control's <object> tag. (ASP.NET AJAX leverages the innerHTML property to do its content refresh of UpdatePanel controls, which is why I saw the problem happening with ASP.NET AJAX.)

Adam let me know that this IE bug with setting an element's innerHTML property with HTML that includes an <object> tag is tentatively scheduled to be fixed in Internet Explorer 8.

Of course, while a future IE8 fix for this issue would be nice, it isn't especially helpful to me right now, since I need to have my web application working on IE6 and IE7! For now, I'm going to rewrite my web app to use standard full-page postbacks to update the set of Windows Forms controls displayed on a page, instead of being able to update just a particular portion of the page using AJAX.

Partial Fix: "Address Bar [Url] is currently unavailable" in IE7

I previously posted about an issue in Internet Explorer 7 (IE7) where when an IE window is first opened, it hangs for a few seconds with a "Connecting..." message, and if the user tries to navigate to a new page while that message is still being displayed (generally by pasting an URL from the clipboard into the Address Bar and pressing Enter), the navigation fails with the error "[Url] is currently unavailable."

Based on several posts to the microsoft.public.internetexplorer.general newsgroup I looked at this morning, I've found a partial solution to this issue. One possible cause of the long "Connecting..." time in IE7 is the load time of the browser's add-ons.

I took a look at the active add-ons in my copy of IE7 (at Tools | Options | Programs tab | "Manage add-ons" button).

Somewhat to my surprise, I had as many as 30 or 40 add-ons enabled (among the 4 add-on categories shown in the dialog). Probably 80% of the add-ons were labeled as being from Microsoft and which I didn't remember installing; the other 20% were 3rd-party add-ons that I did remember installing -- things like Sun's Java plug-in, Google Toolbar, Macromedia Flash Player, and Adobe Acrobat Reader.

As an experiment, I tried disabling all of the enabled add-ons. I didn't know whether disabling the Microsoft add-ons would break my IE7 and result in it being unable to display web pages correctly, but I figured that in the event that it broke, I could always go back into the Options menu and re-enable extensions until IE7 was working again.

The experiment was a success! IE7 now initially starts up a lot faster, and I can immediately paste in and navigate to an URL via keyboard (Alt+d to focus the address bar, Ctrl+v to paste, Enter to navigate) as soon as the IE7 window appears.

Further, even with all add-ons disabled, I haven't run into any problems with displaying web pages in my brief testing so far. IE7 even displays XML documents correctly despite my having disabled many Microsoft add-ons with names like "XML Document".

I would imagine that I might need to re-enable at least some 3rd-party add-ons to view certain websites (like the Flash add-on for sites that use Flash), but for now, I am happy to use IE7 extension-free -- the delay in startup time was a significant annoyance for me. On the other hand, I could just use Firefox to view Flash sites and other sites requiring similar 3rd-party extensions; my copy of Firefox doesn't have any issues with startup time despite loading several extensions at startup.

I'm not sure why IE7 has this addon-related issue with startup time when IE6 did not. Perhaps one or more of my add-ons which were optimized to run in IE6 just perform really badly under the new IE7 engine, and future versions of the affected add-on(s) will address this.

One of the newsgroup posts I looked at also pointed to a built-in shortcut which runs an instance IE7 with all extensions automatically disabled for that instance; this is accessed (in Windows XP) from Start | All Programs | Accessories | System Tools | "Internet Explorer (No Add-ons)". Interestingly, when I launch IE7 from that shortcut, it is still affected by the "[Url] is currently unavailable" issue that my original copy of IE7 was affected by when attempting to immediately navigate to an URL when the window opens. This may be because opening IE with that shortcut brings up a window with a special "Internet Explorer is currently running without add-ons" homepage (including a yellow "information bar" at the top of the screen), whereas my normal IE homepage is a simple, quick-loading .html page hosted on my local machine.

If your copy of IE7 is starting up slowly with the "Connecting..." message, you may wish to examine the IE add-ons that you have running (Tools | Options | Programs tab | "Manage add-ons" button) to see whether one or more of them might be the culprit.

Update 2/3/2007: In the course of the past several days, I've had to re-enable several of the IE7 add-ons that I'd disabled to get various websites to work properly. Unfortunately, this has caused IE7 to mostly revert to the slow startup behavior, even though the majority of the add-ons that I had disabled remain disabled.

I've updated the title of this post to read "Partial Fix" instead of "Fix", as it seems just disabling all available IE7 add-ons to address the slow startup problem isn't a very good solution (since many web pages need one or more add-ons to work properly).

This issue is enough to make me hesitant to recommend upgrading to IE7 for any power users running Windows XP who hasn't yet upgraded from IE6. I say "power users" here because typical users are probably less likely be bothered by the extra startup delay -- it could easily be attributed to a part of the load time for the user's homepage if they don't attempt to immediately navigate to a different page, as I was doing when I first ran across this issue. And power users are likely to be already running Firefox or another alternative browser, and thus don't need to install IE7 to gain access to features like tabbed browsing and PNG alpha transparency support.