Deploying WLANs at Home: A Case Study

As a case study, I will describe a series of events that actually happened to me when I was visiting friends after Christmas 2002.

The friends had broadband Internet access via a cable modem, which was attached to their only PC (they had another PC, but it was not part of the home LAN…it turns out that it wouldn't have worked if they tried to connect it, for reasons that will become clear in a moment). My friends had purchased an AP so that they could use their laptop at home, but they were frustrated because even though their laptop worked wirelessly in the office, it did not work at all at home. This was supposed to be easy. The AP just had a simple Ethernet interface, and the laptop appeared to associate with it, but it couldn't access the Internet through the cable modem. They both had a Wi-Fi logo, so what was wrong? I guessed correctly what was wrong, and it had nothing to do with the wireless functions of either the laptop or of the AP.

The AP was working properly. The cable modem was the problem. The cable modem was also working properly, within a definition of "proper" that suits the cable company, but that is counter-intuitive to the user, and in this case made it look like it was the AP that was broken. The cable modem has an integrated Ethernet-to-DOCSIS bridge. As part of the fundamental operation of this (and any) bridge, it watches all frames arriving on each of its interfaces, looking for MAC-SAs that it hasn't seen before. The bridges in cable modems are specially modified to help the cable companies make more money, in that they are limited to learning only one MAC address on the interface to which the home network is attached. This is to allow the cable company to sell you connectivity for multiple devices at a higher marginal cost per month. This is not surprising…the cable company does a similar thing with extra TV connections.

However, there is no reason to pay extra. Many home gateways have a "MAC Address Cloning" feature. It works as follows: First, disconnect your PC from the cable modem. Connect the PC to the new home gateway and connect to its configuration utility (probably Web-based). On the PC, open a DOS window (click the Start button / select "Run…" / type cmd and click OK). Under Linux and the MacOS, there are utilities that can be used to determine the local MAC address (the ifconfig program and the TCP/IP control panel, respectively).

Figure 8-9 illustrates the previous steps to open a DOS command window in Windows 2000 Professional, the OS that I happen to have on my laptop. Windows XP requires similar steps to open a DOS command window. Screen shots are provided here as a convenience for the Windows users of the world. Unfortunately, it is not practical to include screen shots of every OS, but all OSs will have a way to display the MAC addresses of their network interfaces.

Figure 8-9. Accessing a DOS command (cmd) window from the Start button

After the DOS command window appears, you can type "ipconfig /all" (note that this command is not usable on all versions of Windows…on some versions, the command may be "winipcfg", and in some versions of Windows, that command or a similar one may be launched directly from the "Run" dialog box, without needing to open a DOS command window). Figure 8-10 shows the DOS command window with the output of the "ipconfig /all" command (the MAC address of my laptop's built-in Ethernet interface is highlighted).

Figure 8-10. Determining a PC's MAC address

Once I had written down the PC's MAC address, I went to the portion of the home gateway's user interface in which one may adjust the MAC address of the Internet interface of the gateway. My own home gateway does not have this feature, so I cannot easily show you a screen shot of this configuration step. Suffice it to say that I made sure that the feature was listed on the box when we went to the office supply store to purchase a home gateway for my friend.

Once the home gateway was configured with the PC's MAC address, I connected the home gateway to the cable modem. As far as the cable modem was concerned, it was once again talking to the PC. The fact that the PC is still using the same MAC address on a different interface of the same home gateway is not a problem, since the gateway is acting as a router. It is trivial to disambiguate the two instances of the same MAC address, since each is associated with a different IP address.

Speaking of which, on the PC, after I connected it to the home gateway, I typed one further command into the DOS command window before closing it, namely "ipconfig /renew", which forced the PC to forget its old IP address and use DHCP to request that a new IP address be assigned to it. The home gateway integrates a DHCP server, which quickly complied with that request. The old IP address, which was valid when the PC was directly attached to the cable modem, would no longer work now that the PC had been moved to a different IP subnet on the other side of the router from the cable modem.

As with my laptop's configuration (as shown in Figure 8-4), my friend's PC was assigned a private IP address from the range 192.168.0.x. After the PC had obtained a new IP address, I typed "exit" to close the DOS command window.

The home gateway also supported NAT, which means that multiple devices can be active in the home, simultaneously accessing the Internet, and on the Internet side, all of the connections will appear to be emanating from the external (public) IP address of the home gateway. Therefore, after the original PC was plugged back in, now to the home gateway instead of the cable modem, and verified to be working properly, the next step was to attach the AP to the one of the home gateway's Ethernet interfaces and try to access the Internet from the wireless laptop.

It worked, but this whole experience shows an important lesson in networking and troubleshooting. It was very easy to look at the situation that first presented itself and conclude that the AP must be misconfigured or broken. After all, the laptop worked in the office, but not at home. My friend had no reason to suspect his cable modem, or to have a clue as to why the cable modem's basic operation might be causing this problem. Moreover, knowing that a home gateway with NAT and MAC address cloning could solve his problem was simply way beyond his level of knowledge. And, to be honest, this stuff is still way too complicated for normal people. I was happy to help him, and I'm happy to admit that it's not normal to know how to fix what was broken in his setup.

Even if the AP had some diagnostics that would show that it was passing frames to the Distribution System (i.e., the wired LAN), that would not even have helped much, since the AP would have indicated that all was well.^[37] The AP, even with diagnostic capabilities, would have had no way of knowing that the problem was in the cable modem. What looked (to my friend) like a problem with the WLAN was actually not a problem at all…it was working fine all along. The cable modem was just eating all the frames that didn't come from the one MAC address it was allowed to know about, the original desktop PC's MAC address. No reasonably intelligent person would suspect that this was happening.

^[37] Of course, one might have suspected that something was amiss when no frames were ever seen to be coming back in the other direction, but who would suspect the cable modem? Most people would probably jump to a conclusion that something was wrong on the Internet, but when the desktop PC was working fine, and the laptop wasn't working at all, it was very frustrating for my friend. The cable company could have helped him, by giving him another cable modem and charging him more per month, but they probably never would have been able to explain what was broken.

After the original PC's MAC address was programmed into the home gateway, the cable modem was none the wiser, and everything worked the way my friend thought it should have all along. You've never seen someone so happy to be able to be checking email via his corporate VPN while watching a football game downstairs.

Back to that nonconnected PC that was mentioned earlier. The reason it wouldn't have worked was the same as why the wireless laptop ultimately did not work…the cable modem had locked on to the MAC address of the primary PC, and would not accept traffic from any other device (more properly, it would not have accepted traffic from any device with a different MAC address). Had my friend ever connected the second PC to his home LAN, surely the fact that it didn't work would have been extremely mystifying, perhaps even more so than the case of the wireless laptop, since there was another PC right next to it that worked fine. Even basic troubleshooting tricks, like trying to have only the second PC connected, without the first one, would have failed. Now that the home gateway with NAT was installed, my friend could have a very large number of PCs and other devices sitting behind the gateway, appearing (to the cable company) to be the one PC that they originally knew when the cable modem was first installed.