Wireless on the Road
Wireless Internet access has become easy to find in large cities. But I take vacations in more out-of-the-way places, where "the Internet" still is a new concept. Getting Internet access in most small towns isn't always a straightforward task. Here are some tips that might help you keep your Linux laptop connected on your next trip.
A few preparations before you leave home may help a lot down the road. Test your wireless card thoroughly. If you don't have a wireless network at home, work or school, try to find a local Internet cafe. You don't want to be diagnosing the problems of an unfamiliar network when you're not even sure if your card's driver works or if your hotplug setup is handling PCMCIA cards properly.
Add entries to /etc/hosts for important sites you need to contact, such as your mail server. Make a copy of your /etc/resolv.conf file while you're at home, along with the IP addresses of any other nameservers you trust. As we'll see, you can't always rely on getting accurate DNS information on the road.
The ideal situation is to find a hotel that offers Wi-Fi access, but this is harder than it sounds. Auto-club road guides are no help; they offer a symbol for data port, which means the telephone has an extra place to plug in a phone cable. Why anyone thinks this matters is beyond me. If you want modem access, simply unplug the phone from the wall.
Watch for hotel billboards as you drive in to a town; sometimes the snazzier hotels advertise "High-Speed Internet". If the billboards are no help, read the hotel signs and watch for banners on the hotels as you drive through town.
But beware! High-speed Internet does not mean "We have Wi-Fi that reaches your room". Sometimes it means, "We have one public Windows computer with a DSL connection in the hotel lobby, and you can use it if you don't mind typing your e-mail info and all your passwords into Internet Explorer or Outlook on a public terminal that a hundred guests will use right after you." Look for key phrases, such as "wireless Internet" or "in-room Internet".
If you see no billboards or banners, you may have to go from door to door and ask. Most hotel desk clerks do understand the question these days, and if they don't offer wireless, they may be able to direct you to a hotel that does.
Side note: many hotel clerks, when describing their wireless Internet services, start to hand you a card and a CD with Windows drivers. Assure them that you have your own laptop and wireless card, and they become much happier and stop scaring you with driver discs.
So, you've found a hotel with Wi-Fi access. You're using your own wireless card, which you tested before you left home. You're all set, right? Nope--there still are a lot of potential issues to work through.
The first issue is range. In my experience, fewer than half of the hotels that claim in-room Wi-Fi actually have a signal that can reach a typical PCMCIA card's antenna in most of the rooms. When you check in, be sure to tell them you care about Internet access, as they may give you a room closer to the access point. But don't count on it, even then. If you don't get a signal from the room, try the hotel lobby and see if it's any better from there.
An external antenna can help with reception, either a purchased antenna or a homemade cantenna--a wireless antenna made from a soup can. The trick is finding a way to connect an antenna to the wireless card. Many internal wireless cards already have an antenna connector; it may be as simple as unplugging the wire to the built-in antenna and replacing it with an external one, although you may have to make your own connector. If you use a PCMCIA wireless card, it's more difficult, as few of these cards offer an external antenna option. If you can't find such a card, all is not lost; it's sometimes possible to modify an existing card to add an antenna. Try a Web search on the model of your card plus the phrase "antenna modification". Obviously, don't try this with your only wireless card or with a card that's so expensive you can't risk destroying one or two.
Now you have a signal. Most hotel and cafe wireless access is set up as an open line (no WEP encryption) with dynamic addressing using DHCP, the dynamic host configuration protocol. So, you obviously should set up your machine for DHCP. But what if the server doesn't give you an address? Try running /sbin/ifconfig -a. You should see output something like this:
eth0 Link encap:Ethernet HWaddr 00:03:6D:00:83:CF inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:47 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:7112 (6.9 MiB) TX bytes:1522 (1.4 KiB) Interrupt:11 Base address:0xd000
If the card is marked UP and there is no inet addr, then DHCP probably isn't working. In this case, you may be able to connect using a static address.
How do you choose a suitable address? That's tricky. Most public wireless networks use the 192.168.1.* address range, so you could choose an IP address between 192.168.1.1 and 192.168.1.254 and try it. That's somewhat unfriendly, but it may work. Alternatively, you can use a Net sniffer, such as Kismet or Airsnort, to snoop on the Net and see what sort of addressing scheme they're using. But in small-town hotels, you might find that no one else is on the Net, especially if it's not working correctly. In this case, guessing might be the only option.
A static address also may help with a flaky connection. If you're on the ragged edge of reception, constantly losing a connection and then getting a new one, as so often happens with hotel networks, not needing to make a new DHCP query every time can make the difference between a connection that is merely slow and one that doesn't work at all.
Much more common is to get a valid DHCP address but no nameserver, the service that maps domain names such as example.com to Internet addresses. If this is the case, your network will be up and you'll be able to get to IP addresses or hosts specified in /etc/hosts, but you'll hang any time you try to reference any other host by name.
On Linux, user cat /etc/resolv.conf to find out what DNS information you've been given. It may be wrong in some fairly obvious way. For instance, one hotel listed 0.0.0.2 as the nameserver, but DHCP had assigned our machines addresses of the form 10.0.0.18. After editing /etc/resolv.conf to change the nameserver's address to 10.0.0.2, everything worked fine.
If there's no obvious error in resolv.conf, try using the DNS server you use at home. Pull out the resolv.conf you copied at home and install it in /etc. It may help.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide