It took time and effort, but the decision was made and the cash was laid! I'd heard rumors and horror stories surrounding the difficulties of getting Linux boxes to communicate with the latest development in Internet technology: the cable modem. Steadying my nerve (and my pocketbook), however, I decided that it was time to brave the storm, dodge the truth, and let the @home technicians stare blankly at my Linux screen.
Check out TechRepublic's TechProGuild!
This article appears courtesy of TechRepublic's TechProGuild, the subscription Web resource for IT administration and support professionals. Among other great benefits, TechProGuild offers in-depth technical articles, e-books, and weekly chats moderated by industry experts on hot topics such as the latest OS developments and career advancement. Sign up now for a FREE 30-day trial of our TechProGuild service.
Many of my fellow Linux users instructed me to avoid telling the local cable company about Linux because the cable company might deny me service if I didn’t have the standard Microsoft Windows environment. Therefore, I made my trusted dual-boot laptop available—just in case! Fortunately, when the technicians arrived, their curiosity (or their high “geek factor”) overwhelmed them, and the main technician was more interested in watching Linux work than in setting up service for Windows. Due to this streak of luck, I managed to wrangle nearly all of the necessary information in order to get the cable modem service up and running—well, once the modem finally managed to sync with the @home service—but that's another story.
Let's take a look at the environment. If your machine is a stand-alone desktop, this section won’t be relevant to you. If you have a small network at home, however, you'll need to run two network interface cards (NICs). If you had two NICs in one machine, you would need to set up each device individually. The first Ethernet adapter should be up and running already because it runs your private/local network. The cable company will supply the second NIC, which you will have to install and configure. (NOTE: When you sign up for the service, make sure that you ask for a PCI card—not ISA.) If you’re running one of the newer distributions, this configuration will be a snap! With its new kudzu application, Red Hat 6.1 makes the configuration of newer hardware a breeze. Once I installed the new piece of hardware (Allied Technologies—a.k.a. RealTech clone), the OS detected it at boot and dropped it in the proper driver. I was ready to configure.
If your OS isn’t a newer release, you need to go into your favorite network adapter setup tool (such as netcfg in Red Hat) and add the new device. In Red Hat's linuxconf, you can open the basic host information section, go to the adapter 2 tab, and enter the proper information. In Caldera's Open Linux, there are similar tools that allow for multiple device setups (like Ethernet Interface Configuration, which is found in the COAS toolbox).
The basic host information that you need in order to configure this device follows:
- Config mode: Manual (static), Dhcp, or Bootp
- Primary name + domain
- IP address
- Net device
- Kernel module
- I/O port
- Routing and gateways
- Default gateway
- Enable routing
The above information is common to the configuration of any net device, and it shouldn't throw any Linux user. What may throw a user off is the static vs. DHCP vs. bootp options. Typically, the cable modem industry prefers that users run their machines with Dynamic Host Configuration Protocol (DHCP). This preference is understandable, seeing that cable modem services must have control over how Internet Protocol (IP) addresses are assigned or changed. Although it isn’t typical for an IP address to change, it can happen, and your service must be able to make that change. These changes can cause problems when users have defined their connections as static due to the less-than-friendly way in which Linux DHCP configuration is handled. Unlike Windows’ ability to let clients receive dynamically assigned IP addresses, Linux must be tweaked and prodded in order for the service to run.
We'll deal with those issues later. First, let's get your machine up and running with a static IP.
Setting up a cable modem for use with a static IP address is an easy task. Without the knowledge of some “hidden” scripts, however, you might find yourself reloading OSs left and right. The primary scripts that we need to deal with are /etc/sysconfig/network-scripts/ifcfg-eth* (where * is the Ethernet device that will be used for your connection), /etc/sysconfig/network, and /etc/resolv.conf. Fortunately, front ends (like netcfg, netconf, and linuxconf) handle the writing of most of these scripts.
Generally, the first script is handled by the installation, linuxconf, netconf, or netcfg. Each of these applications is a front end that writes and edits this script. The biggest difference is that, with netcfg, there’s no way of choosing a driver for a given card. In some cases (like PCMCIA cards), it will be fine. But for most situations, you’ll need to choose the driver. Therefore, consider using netconf or linuxconf. With either of these front ends, you simply enter the information into the required fields and save the changes. No rebooting is involved.
The ifcfg-eth* file looks like this:
There are other lines involved, but these are the critical lines that allow your machine to connect to the cable modem service. These entries declare the information that’s either given to you by your service or taken by “other” means. What do I mean by “other”? Should your cable installation technicians not be willing or able to give you your IP address and other pertinent information, you can get that information from an old pal: Windows. When Windows is configured properly, you can run winipconfig from the command line and secure all of the necessary information. You can learn what service the DHCP servers have assigned to your machine. (Usually, it's safe to assume that an IP address will be gold for quite some time.) Once you have this information, all you need to do is transfer it to your Linux system's configuration files.
The next file holds the primary and secondary Domain Name Servers (DNSs). Again, you can obtain this information either from the cable technicians or through running winipconfig in Windows. This particular file will contain two lines, and it looks very much like this (where *** are the DNS numbers for your connection):
Note that the file is written in the following format when it configures the DNS through linuxconf or netconf:
search ***.***.***.*** ***.***.***.***
Although the latter format is acceptable, the first format is standard and should be followed. In order to change the shape of this file, simply su to root, open your editor of choice (pico, vim, emacs, etc.), and make the necessary changes.
This file is tricky because it isn’t documented as well as the others, yet without it, the connection can’t be made. The file has four lines, and it looks like this:
HOSTNAME='********' (where ******* is the machine's hostname)
GATEWAYDEV="eth*" (where * is the device used for the connection)
When this file is correctly in place, you can test your connection.
Testing the connection
First, run /sbin/ifconfig. You should be greeted with something like:
eth0 Link encap:EthernetHWaddr 00:A0:D2:17:3C:18
inetaddr:***.***.***.*** Bcast:***.***.***.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32023 errors:0 dropped:0 overruns:0 frame:0
TX packets:26254 errors:0 dropped:0 overruns:0 carrier:0
Interrupt:10 Base address:0xec00
What you should receive is your IP address (the one that was assigned by your cable service), your broadcast address (which includes the first three sections of your IP, while the fourth part changes to 255), and your netmask. You’ll want to make sure that you see the word “MULTICAST” in the output. If the word doesn’t appear, then you know you’re using an old kernel and you’ll have to recompile the kernel to support your technology.
If the output reads correctly, you’ll want to move on to ping. At a console terminal, run ping in conjunction with a known IP address or URL. For instance, you could use ping 22.214.171.124 (Yahoo!). You should receive a response similar to the following:
PING yahoo.com (126.96.36.199) from ***.***.***.*** : 56 (84) bytes of data
64 bytes from 188.8.131.52: icmp_seq=0 ttl=240 time=88.4 ms
64 bytes from 184.108.40.206: icmp_seq=1 ttl=240 time=86.4 ms
If you receive this output, then you’re in luck. If not, then there are a few steps you can take to troubleshoot the situation. First, you need to make sure that the Ethernet device is up and running. There are many tools that can help you start and stop such network devices. In Red Hat, there’s usernet, which is a GUI that allows the user to stop and start network devices with a click of the button. With later releases (6.0 +), the configuration of these devices is available through the same tool. At a command prompt, type usernet to bring up the tool.
When the usernet tool appears, you can right-click to access the configuration tool or the properties dialog. Of course, this is a Red Hat GUI tool, but there are many other network configuration/monitoring tools. The command line is the most common. The basic command for starting network connections is /etc/sysconfig/network-scripts/ifup eth* (where * is the device that will be used for the connection). To bring down the same connection, type /etc/sysconfig/network-scripts/ifdown eth*. You could run /etc/rc.d/init.d/network start to start the connection, /etc/rc.d/init.d/network stop to stop the connection, and /etc/rc.d/init.d/network restart to restart the connection.
Tomorrow, I’ll cover the use of DHCP and cable modem security. If you’re running Linux, you won’t want to miss it.
Jack Wallen, Jr. is very pleased to have joined the TechRepublic staff as editor-in-chief of Linux content. Jack was thrown out of the "Window" back in 1995, when he grew tired of the blue screen of death and realized that "computing does not equal rebooting."If you'd like to share your opinion, please post a comment below or send the editor an e-mail.
Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website jackwallen.com.