3 Things I Hate About My Clear WiMAX Gateway

I recently signed up for Clearwire's WiMAX service. So far the service itself has been great. Performance is good at all times, and we haven't lost our connection once in the past two weeks. This is pretty important since I work from home and also run a couple of low-profile servers over this connection.

Most of my problems with Clear stemmed from the fact that they advertised their Motorola gateway as a modem when it's actually a router. Unfortunately the gateway has continued to cause problems--so many that I would not recommend Clear's service to anyone with a home network (or at least anyone with more than the plainest vanilla configuration). Wait until you can purchase a better WiMAX modem or gateway than what's provided by Clear.

First, the gateway refuses to properly forward requests originating on the local network to my public servers. Every LinkSys home router I've owned for the past 8 years has handled this correctly. But the Clear Motorola gateway returns the router's administration console for all local network requests to the gateway's private AND public IP addresses. The router includes an option to enable/disable administration from the Internet, but that makes no difference. In practical terms, this means I can't see what my home servers look like to the outside world without either A) accessing them through a different ISP or B) routing my http requests through a slow and invasive proxy server such as this one.

Second, the gateway apparently eats traceroute packets. The screenshot below shows a traceroute to www.google.com with a timeout of 10,000 milliseconds:

Now I can't prove that the gateway is actually eating these packets because I don't have another device on Clear's network to compare. It could be that the packets are eaten by an upstream router on Clear's network. But I doubt that's the case. (As an aside, I see the same behavior when I run a traceroute to other hosts on the Clear network, such as their DNS servers and time server.)

A big reason I'm inclined to blame the gateway for eating traceroute packets is also the third thing I hate about it: It doesn't fully implement the DNS protocol. I discovered this when my mail relay stopped working after switching to Clear. After several wasted hours monkeying around with my SMTP server and Wireshark I found that the gateway was eating DNS lookups for mail exchanger records. This was especially difficult to diagnose because the A record lookups were working just fine.

The screenshot below shows an nslookup of the MX record for gmail.com, which times out:

This screenshot shows an nslookup of the A record for gmail.com, which succeeds:

Once I identified the problem it took just a few minutes to fix by bypassing the Clear gateway for DNS lookups on the mail server. As you can see below, the same MX lookup works fine when routed specifically to Clear's primary DNS server (75.94.255.12):

This DNS server is where the gateway passes DNS requests it can't resolve, which indicates to me that the gateway itself is responsible for mangling the DNS packets.

Signing up for Clear WiMAX in Atlanta

During our 9 years in Atlanta we've tried both DSL and cable broadband. We started with AT&T Broadband cable, and that was pretty horrible. We then tried DirectTV and SpeedFactory DSL. These were great companies, but DirectTV stopped providing DSL service, and SpeedFactory was killed off by BellSouth. We returned to cable with Comcast and they've been so-so: intermittent outages, poor customer support, and expensive--but usually available and fast.

Needless to say, I've been eager to find an alternative provider for quite some time. When I discovered several days ago that Clearwire had just rolled out WiMAX service in Atlanta--for very competitive prices--I was ready to try it out.

I tried to place an order that night but ran into some issues with Clearwire's Web site. I finally ordered the service yesterday and received my equipment today. It has definitely been a mixed experience so I thought I'd take a few minutes to highlight the good and bad here. Local blogger Bruce Bracey has catalogued his experiences in some detail here and here if you want another opinion.

The Clearwire web site is pretty, but has some serious usability issues. For one thing, the site really overuses AJAX. This is a problem during the signup process, but the best example I can show you is the FAQ page:

Notice the tiny little scrolling area in the modal pop-up window. Nice. I have a 20 inch monitor, but I'm forced to view their FAQ through a 200 pixel-high portlet--and scroll down 18 times to read the whole thing!

Other issues I ran into:

• You can only lease a WiMAX modem if you sign a 2-year contract. Month-to-month plans require a $35 activation fee and a $79 modem purchase. I can understand the activation fee, but the modem purchase/lease options don't make sense, and it wasn't initially obvious why the modem lease option kept appearing and disappearing during the signup process as I switched between plans.
• The 2-year contract requires your SSN and birthdate for a credit check plus your credit card number, expiration date, and security code. The site rejected my choice for a username at least 5 times (once for including an underscore character and multiple times because the usernames I selected were already in use). Each time my SSN, birthdate, and credit card information were discarded so I had to repopulate these 5 fields 5 times each. (Perhaps this was for security reasons, but the site also neglects to set autocomplete="off" on these form fields so they were conveniently remembered for me by Firefox--negating any security benefits.)

After all this I was rejected for not passing the credit check. Huh? I've always had excellent credit so I was concerned enough to surf over to AnnualCreditReport.com and check my credit files for the first time this year.There were no problems with my credit history so I have no explanation for the rejection. I returned to Clearwire's site and this time succeeded in signing us up under my wife's name--apparently she's more likely to pay due to the enormous salary she earns managing our household and homeschooling our kids!

Once I ordered service the Motorola CPEi 25150 modem arrived in just over 24 hours--a pleasant surprise. The packaging and instructions were very simple and indicated that I only needed to attach the modem to my computer via an Ethernet cable to get connected. Unfortunately, it wasn't that simple.

I tried swapping out my cable modem and replacing it with the WiMAX modem, but that didn't work. I next hooked the Clearwire modem directly to my computer and could then connect to the Internet. It took several more steps on the Clearwire site to finish configuring my account and the site timed out several times during this process.

Because the modem didn't work when I first attached it to my network I was suspicious it was more than just a modem. Sure enough, after a little investigation I discovered the "modem" was actually a full-fledged router with firewall, NAT, DHCP, etc. support and a Web administration interface (default IP is 192.168.15.1, default password is "motorola"). The router capabilities are not mentioned anywhere on the Clearwire site, packaging, or setup instructions. This was quite a nasty surprise since it took several more hours of wrestling with my network configuration to make the new modem co-exist with the (much nicer) Linksys router required for my Vonage phone service.

On the positive side, signal strength and network speed were very good. Our house is located near the top and on the east side of the ridge that carries Jones Bridge Road between Highway 120 and McGinnis Ferry Road in John's Creek. When placed by the east wall on our first floor (not in front of a window) the modem shows a steady 5 signal bars (strongest possible).

I selected the 786/384 kbps plan ($20 per month) to try out the service, but I achieved significantly higher speeds on my initial Speakeasy test at 4PM EST:

• Atlanta - 5862/458 kbps
• Seattle - 5581/423 kbps
• LA - 4257/503 kbps

Later in the day Clearwire must have throttled me back to my contract speeds because the results were not quite so spectacular at 12 PM:

• Atlanta - 1100/360 kbps
• Seattle - 1095/336 kbps
• LA - 1092/345 kbps

Atlanta is just Clearwire's third market nationwide so hopefully they'll improve the signup process quickly while keeping the network fast!

P.S. If you found any of the above information useful and decide to sign up for Clear WiMAX feel free to show your appreciation by entering my referral code: "b25rd7". Thanks!

UPDATE: Three things I hate about my Clear gateway.

Determining Html Element Visibility with WatiN

I recently started using WatiN to write automated Web application tests for the first time. WatiN is a great and rapidly maturing tool with lots of developer support, and I highly recommend it based on my experiences so far. But after writing several tests of dynamic screen elements I realized the tests weren't verifying everything I thought they were verifying.

When you use WatiN "Find" syntax to search for elements and screen text there's no obvious distinction made between hidden and visible elements. The screens I was testing use ASP.NET validation controls to perform client-side validation and include other dynamic elements such as the AJAX.NET ModalPopupExtender. I wanted to verify that these elements were visible and hidden at the appropriate times, and the simplest way of accomplishing this with WatiN was not immediately obvious.

After digging around in the API a bit I came up with a method that's simple, robust and seems to perform reasonably well. As demonstrated in the sample tests below, you can simply walk up the element hierarchy checking whether an element or any of its parents are styled with "display: none".

   1: using System.Text.RegularExpressions;

   2: using NUnit.Framework;

   3: using WatiN.Core;

   4:  

   5: [TestFixture]

   6: public class WatinTest

   7: {

   8:     [Test]

   9:     public void PopupDisplayed()

  10:     {

  11:         var ie = new IE();

  12:         ie.GoTo("http://www.example.com");

  13:  

  14:         Div popup = ie.Div(Find.ById(new Regex("pnlPopup$")));

  15:         Assert.IsTrue(IsDisplayed(popup));

  16:     }

  17:  

  18:     [Test]

  19:     public void ValidatorDisplayed()

  20:     {

  21:         var ie = new IE();

  22:         ie.GoTo("http://www.example.com");

  23:  

  24:         Span validator = ie.Span(Find.ByText("Required field"));

  25:         Assert.IsTrue(IsDisplayed(validator));

  26:     }

  27:  

  28:     public bool IsDisplayed(Element element)

  29:     {

  30:         if (string.Equals(element.Style.Display, "none"))

  31:         {

  32:             return false;

  33:         }

  34:         if (element.Parent != null)

  35:         {

  36:             return IsDisplayed(element.Parent);

  37:         }

  38:         return true;

  39:     }

  40: }

The first test case (PopupDisplayed) searches for the div element representing a modal popup panel by the element id. It uses a regular expression since the ASP.NET control ids for nested controls are unwieldy and variable. In this test we are checking whether the div itself is displayed, but this method would also work for any control contained by the div (such as a submit or text input element).

The second test (ValidatorDisplayed) searches for the span element representing a RequiredFieldValidator by the validation text contained in the span.

Some caveats apply when using this method:

• It works only with embedded CSS styles. If the "display: none" style was applied using a CSS class contained in a style sheet the WatiN Element.Style property would NOT automatically reflect this.
• It doesn't determine true element visibility--only whether the element is displayed. Elements may also be hidden using "visibility: hidden", occluded by other elements with a higher z-index, or moved offscreen using the position style.

As a side note, I highly recommend that you grab the Internet Explorer Developer Toolbar and take some time to understand the WatiN page model before writing many tests.