Author: Olaf Piesche
I’ve got an Athlon XP 1700+ that I use for my personal and professional tasks, and two more
computers in the house, all hooked to a DSL modem through one of the machines, which acts as a gateway. All of the computers are running Windows, including the gateway.
A couple of weeks ago the modem began crashing several times a day. You can’t fix it by just turning it off and back on, because Windows’ DHCP client is unable to retrieve a valid IP address from the modem if you do that, and Windows’ Internet Connection Sharing and its DNS settings won’t work anymore. Instead, you have to reboot the gateway, set the DNS server from a static IP to retrieval via DHCP, click OK, wait half a minute or so, then open the properties again and set the DNS back to static IP addresses, since dynamic DNS retrieval won’t work at all. Click OK and wait again. Then, maybe, it works.
The two other computers are hooked to the gateway via 802.11b adapters in an ad-hoc network, which was a whole can of worms of its own. Connection dropouts were more
or less an hourly thing, and don’t even think about rebooting one of the machines. Often, the only thing that helped get the wireless connection back up was to uninstall and reinstall the Wi-Fi card on the machine in question. A pain in the rear? You bet.
Viruses and worms were another species of problems we had to deal with. One day I counted eight infections on the gateway, four on one of the client machines, and three on the other, all within less than 24 hours — despite antivirus software and firewalls running on the gateway and the other computers.
And of course, we would have liked to run a Web server, FTP server, and maybe a couple of other niftynesses on the gateway. Now, take all of the above problems, put them in one package being delivered at least once daily on average, and there goes your sanity.
Linux to the rescue
I’d had a little experience with Linux, mainly as a desktop user. I had downloaded and installed Mandrake’s distro a year back, was quite happy with it, and used it a fair bit in a dual-boot configuration on my machine. As a software engineer by trade, I had little actual experience in network setup and configuration beyond plugging in a cable and assigning an IP address, and not very much of a clue of what to do with Linux’s command-line tools.
When I began my project to build a Linux gateway to replace the Windows version, I set out with the following (in addition to the computer and the installation CDs):
Network cards — a trip to the garage produced a 3Com and a Linksys Ethernet card, as
well as a hub. Since I wanted to run the Linux box as a gateway for the wireless machines, it needed one of the cards, so one of the clients had to be hooked to it via an old-fashioned wire.
ndiswrapper — For network cards that are unsupported in Linux, ndiswrapper can load the Windows binary drivers and function as a wrapper. The operating system and applications access ndiswrapper as the network driver, and ndiswrapper in turn uses the Windows drivers to do the job. While this may seem like a kludge, it works very well in my experience, and opens a whole host of previously unsupported devices to Linux users.
Hard disks— another trip to the garage resulted in three old hard drives I decided
to use (have I mentioned I’m a computer parts pack rat?) — one 6GB, one 1.6GB, and one 2GB, all IDE drives.
The mission
I hooked my CD-ROM drive to the old computer (a 233MHz Pentium II with a whopping 80MB RAM) and
started Mandrake’s installation. Because I had a bad CD burner, two of the three installation CDs weren’t working, so I decided to go ahead and copy the whole thing onto one of the hard drives and install from there. The CDs contain a Windows executable that prepares for the installation, and one of the options is to generate a boot floppy for several installation options like network or hard drive installation.
The latter was almost as simple as installing from CDs — boot from the floppy disk, tell the installer on which hard drive to find the installation files, and we’re off. Mandrake’s installer automatically ran its text mode install because my old Trident video card wasn’t able to handle the graphical version. The text mode install works pretty much the same as the graphical one, and within
30 minutes (they’re very old hard drives) I had a bootable Linux installation. I did not install X nor Gnome nor KDE; I wanted to administer my gateway remotely via Telnet, so it seemed silly to install a windowing environment.
I shut down, installed the 3Com network card, and rebooted. Mandrake detected the card and loaded the driver. Beautiful.
The insertion of the second network card wasn’t as simple, because instead of PCI, the Linksys adapter was ISA. I found out from running a Google search and browsing some message boards that I needed the ne kernel module, as well as a working combination of IRQ and IO address. Changing to
superuser and typing modprobe ne io=0x320 irq=9 did the trick. A quick check with lsmod showed that the module was successfully loaded, and ifconfig -a showed the 3Com adapter as eth0 and the Linksys card as eth1.
Instead of configuring the adapters through Mandrake’s tools, I decided to do it manually, for the sake of the learning experience. With ifconfig, I had the Linksys card set up quickly for the wired side of my LAN. I hooked it and my Windows box to a hub, and could immediately ping from and to both sides.
The 3Com card on the DSL modem called for a DHCP client. Instead of Googling again, I decided to just give it a shot. I typed dhc and hit the Tab key, which revealed dhclient as an option. I tried dhclient eth0, and to my amazement, the card had its IP address and DNS server configured in the blink of an eye, and I had access to the Net. This was almost too easy to be true. Wasn’t Linux supposed to be difficult, cryptic, and mind-boggling to configure without the
help of third-party or distribution-proprietary tools like Mandrake’s DrakConf?
When I first installed Mandrakelinux, I chose Samba as one of the packages to set up, because I was toying with the thought of sticking a few bigger hard drives into the box once I was done and using it as a file server. On a hunch, I turned my chair around to the Windows box, which was now connected to my future gateway via the hub, and opened Windows’ Network Neigborhood browser. After a few seconds of waiting, I could hardly believe it — there was my Linux box showing up, including a shared “PDF writer” printer. I was impressed — Samba was set up and running, and I had access to my box without having to perform any configuration whatsoever.
Look Ma, no wires!
After plugging a Siemens Speedstream 1024 wireless adapter into the Linux box and restarting, the hardware detection automatically recognized the card, but was unable to load a driver for it. This is what ndiswrapper would have to take care of. I had downloaded the latest ndiswrapper source package to my Windows box, and since I had Samba already running, I decided to go ahead and configure a shared directory, so I could copy it from the Windows machine to the Linux box that needed it.
Setting up a share was not difficult once I figured out some vim editor commands. (Later I realized that I could have used the Samba Web Administration Tool (SWAT), since I’d had installed it and Apache, and been spared from editing the file manually.) The configuration file contains many comments that show how to do things, and within minutes I had configured a different host name, allowed users, and defined a share directory. After figuring out that I had to restart Samba to make it reconfigure itself according to the new smb.conf, my new share was up and running. Adding new users with smbpasswd was equally easy, and in no time I had a working file sharing setup on my Linux box.
I tried to copy ndiswrapper from the Windows box into the share, and found that I had no access to it. A quick Google search revealed that I had to change the access on my share directory. Now copying the package as well as the needed Windows .sys and .inf files from the driver CD was no problem, and I could install ndiswrapper without any trouble.
I ran ./configure, ./make, ./make install (with the proper parameters to tell the script where to find the driver files), and everything was ready to go — the
driver was loaded, and ifconfig -a showed wlan0 to be available. Since I had done this part before (only with much more help from readme files and Web searches) it was a smooth
process. Configuring the card with iwconfig was relatively easy, and I quickly connected and pinged the Windows box via Wi-Fi.
Am I coming through?
Configuring Linux to share its connection to the DSL modem was one of the major reasons I started this whole process, and I had done my homework in form of Google searches and browsing through message boards. I knew I had iptables installed, and the three commands I needed to set it up seemed to be easy enough:
iptables -F -t nat
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
While not exactly easy to understand, these did the trick. My gateway was up and running. Quick checks from all three Windows clients (one wired through the hub, two wireless) showed that access to the Net worked from all of them.
File sharing woes
While, thanks to Samba, file sharing worked just fine between the Windows boxes and the gateway, it just wouldn’t work between the Windows computer on the hub and the ones on the wireless cards. When I set up the network cards, I put each on a different subnet — the Linksys card was configured as 192.168.0.1, and the Speedstream as 192.168.1.1. I had known beforehand that two different network cards in one computer could not be on the same subnet without troubles, which is why I set it up this way. What I didn’t know was that traffic between two subnets was not possible without troubles, either.
Luckily, I found an IRC channel where helpful people gave me a hint: bridge the wireless and the wired network card. A bridge is like a wire between network interfaces, in my case eth1 and wlan0, with its own IP address. So, instead of having two different gateway addresses and subnets, one ends up with a single address that connects to all network interfaces via the bridge.
Going back to Google, I discovered that I needed the bridge-utils package, which I downloaded and installed. brctl proved to be easy enough, after consulting its manpage and the Linux bridging HowTo. Creating a bridge, adding the interfaces to it, and bringing it up with ifconfig posed no problem. However, it still wouldn’t work. Where I was able to ping between the two subnets before, now not even ping would go through.
Going back to the HowTo and the IRC channel, I learned that I had forgotten to set both NICs to an IP address of 0.0.0.0, which was necessary for the bridge to work. So I did, brought the bridge down and back up, and tried to ping. Still nothing.
Another consultation of a few message boards suggested that putting the two NICs into promiscuous mode (so that they would listen for all incoming packages, regardless of subnet) would help. So I tried
ifconfig eth0 promisc
ifconfig eth1 promisc
with no positive result. No traffic between the two network cards seemed to be possible, while
connection to the Net from any of the Windows boxes through the gateway functioned flawlessly. I decided to take a break and went off to dinner. Strangely enough, when I tried again about an hour later, things worked without a hitch. I could ping between the wired and wireless interfaces, Windows file sharing worked as well, and everything seemed to have snapped into place. Maybe it took the bridge a few moments to “learn” about the two network interfaces and actually make the connection. But now it
worked, and my gateway machine was complete.
Summary
Getting a Linux-based gateway to run from scratch was an interesting learning experience. Some
things were quite opaque and difficult to get working, and it takes some tolerance for frustration to get things up and running (and again, I’m talking about without the help of GUI-based tools that are included in most distributions to make the processes much less difficult). Bridging is my major pet peeve in this respect — some more solid documentation is needed here. Getting an ISA card to work can be annoying as well, thanks to the inherent shortcomings of ISA, since it can involve trying several different IO addresses and IRQs; some diagnostic tools would make this step easier and less frustrating.
Still, most tasks, including installation in general, getting network interfaces up and running, DHCP, and even Samba, are not difficult even without help from GUI-based tools. All one needs is a bit of patience and the knowledge of how to read man pages or do a Web search. With the tools that the different distributions include, most of the configuration that I did the hard way should be easy enough for pretty much anyone.
In the end, the results were worth the bits of trouble. The DSL modem crashes have completely disappeared, which makes it obvious that Windows must have repeatedly done something wrong. The Linux-based gateway, though on a much slower computer, is noticeably faster than the Windows-based alternative.
Connection problems with the wireless cards are much less frequent, which is strange — ndiswrapper is using the same drivers, after all. It appears that, one layer above the drivers, Windows’ much touted plug-and-play capabilities and ease of networking aren’t all they are said to be — especially when Windows is running as a gateway.
I have not encountered a single virus or worm on any of the Windows boxes since they were connected
through the Linux gateway. I’ve also managed with relatively little pain to get FTP and Web servers running, set up the two remaining hard drives in a RAID configuration, installed a couple of chat-related servers, and tinkered and played here and there — and the whole thing is still solid as a rock.
While the desktop side of things in the Linux world is getting better, with setup and configuration being less confusing than in Windows in many cases, even using simple command-line tools for projects like mine is not as daunting of a task as it may seem. Considering I didn’t have much of a clue of what I was doing when I started, setting up a gateway was much less complicated than I would have thought.
Olaf Piesche was born in Germany, and moved to the U.S. in 2000, where he works as a C++ software engineer, mainly in 3D graphics. His favorite Linux distribution so far is Mandrake, for its completeness and ease of use.
