Building a Wireless Network with Linux
While being able to network two laptops wirelessly is a lot of fun and can be quite handy, I was still not satisfied. I have a local area network (LAN) in the house, spanning several computers hubbed together in the basement and up two levels to an upstairs office with another hub of three computers. Being a Linux user, I want more from my hardware and wanted to get much more functionality out of my wireless network. I wanted to be able to roam the house or sit by the pool with a wireless laptop, and also network with all computers on the LAN while browsing the Web, doing e-mail and so on. The cards are advertised as being able to communicate at least 500 feet through walls and 1000 feet within “line of sight”.
Unfortunately, according to Webgear, the Aviator 2.4 cards are meant to be used only for peer-to-peer networking. If you purchase the Aviator Pro line of cards, you can then buy a piece of hardware called a wireless “access point” that hooks into your LAN via RJ45 to provide a bridge into your network or from another network. The access point costs several hundred dollars, even with diligent Internet shopping. A wireless access point is not offered for the Aviator 2.4 series.
This is where being a member of a Linux users group comes in handy. Thanks to friends in the Northern Virginia Linux Users Group, NOVALUG, I was able to create my wireless network. Following tips from messages on NOVALUG's mailing list, I installed one of the Aviator ISA PCMCIA slot adapters in my server in the basement. The server's first interface, eth0, has an assigned IP address of 192.168.2.XX. I installed the Aviator card as eth1 with an IP address of 192.168.1.1. After the wireless card was “started”, I then used the route command to route wireless (eth1) traffic through eth0:
/sbin/route add 192.168.1.1 gw 191.168.2.
To complete the services, I then crafted a simple IP masquerading script (based on information courtesy of Greg Pryzby, NOVALUG's founder):
#!/bin/sh
case "$1" in start)
/sbin/modprobe ip_masq_ftp
/sbin/ipchains -A forward -s 192.168.2.0/24 -j MASQ
/sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ
echo "NAT Started" ;; stop)
/sbin/ipchains -F
echo "NAT Stopped" ;; *)
echo "Usage: ipmasq {start|stop}" ;;
esac
After enabling my PPP connection, wireless card, masquerading and
routing on the server, then connecting to the rest of the LAN and
using the Internet from my wireless laptop (with an assigned IP
address of 192.168.1.2) was quite simple. Again, using the route
command, but this time on the wireless laptop:
/sbin/route add default gw 192.168.1.1This configuration allowed me to communicate with all the other computers on the LAN (such as LaptopA and ComputerB), along with access to the Internet.
Then I ran into trouble. When I was down in the basement near the server, connection tests ran okay with the wireless laptop. However, when I ranged too far from the server, for some reason the cards would lose communication, or I could not “join” the “started” server connection. If you read more about wireless networking's coverage and reliability, you'll learn that the quality of a connection can be influenced by many factors. I later found out the equipment in the basement was located too close to an earthen wall, and for some reason, the signal was being blocked. I had to move the connection, but I still wanted full access to the LAN and the Internet.
I then removed the Aviator card from the server and reinstalled the card on an ancient spare laptop (LaptopA) upstairs with two Type II PCMCIA slots. Like the server, one laptop slot provided an eth0 interface to the LAN (with an IP of 192.168.2.32), while the other was configured as eth1 with the wireless card (and an IP of 192.168.1.1). IP masquerading on the server was forwarding packets from the PPP connection to the laptop, but in order to provide service to the wireless laptop, I had to use IP masquerading on LaptopA again:
/sbin/ipchains -A forward -s \ 192.168.1.0/24 -j MASQ
Now everything worked fine! I could communicate with the rest of the LAN (such as from the Wireless to Computer B or the Server).
A simple route command on the server, using the wireless laptop's IP address along with the “hardwired” eth0's IP address (from LaptopA) also allowed the rest of the LAN to ping the wireless computer:
/sbin/route add 192.168.1.2 \
gw 192.168.2.XX
Believe me when I say it was somewhat of a learning experience—I never envisioned having to forward information from two computers.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Weechat, Irssi's Little Brother
- New Products
- Developer Poll
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




2 hours 28 min ago
3 hours 13 min ago
3 hours 23 min ago
3 hours 28 min ago
5 hours 39 min ago
5 hours 40 min ago
6 hours 25 min ago
7 hours 13 min ago
7 hours 37 min ago
9 hours 14 min ago