Category Archives: mobile

Wifi roaming on the move redux

It has been nearly six years with a netbook and five since I last wrote about wifi roaming from the bus to stay on irc without a costly celluar link during the daily commute.  Since then, some readers have asked me to share my refinements to the method in a followup post. So here it is.

The software

On the server:

  • openssh-server
  • screen
  • irssi

On the client:

  • screen
  • wpasupplicant
  • isc-dhcp-client
  • openssh-client
  • openbox
  • sudo & gksudo (optional)
  • urxvt
  • wavemon (optional)
  • three shell scripts (provided below)

Putting it together: on the client

Make sure if you have a wireless manager installed (such as NetworkManager) it is configured to skip your wireless interface, disabled entirely, or if possible, removed. Set up /etc/wpa_supplicant/wpa_supplicant.conf and /etc/network/interfaces for roaming, as per the instructions in /usr/share/doc/wpasupplicant/README.modes.gz. Don’t forget to add yourself to the netdev group if you are not in it already.

In /etc/wpa_supplicant/wpa_supplicant.conf, list common names of open networks. Normally the catch-all network that associates with any essid, i.e. the first stanza below, works well. However, occasionally the strongest signal is neither one of the common networks nor an easily accessible network (e.g. web portals), so having a list of common open networks helps to quickly select from among those instead. The more you travel, the more of these will discover and add. Just use reconfigure from wpa_cli to reload your edited list each time you add a new one.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
        key_mgmt=NONE
}
network={
        ssid="default"
        key_mgmt=NONE
}
network={
        ssid="linksys"
        key_mgmt=NONE
}
...

Since you’ll be using ssh repeatedly to connect and it has to be fast, make sure your server is set up to accept your key and use ssh-add so that you only have to enter your ssh key password once.

You can tweak isc-dhcp-client to make connections faster. In /etc/dhcp/dhclient.conf, use:

backoff-cutoff 1;
initial-interval 1;

Here are a few scripts I wrote to facilitate quick roaming from one open AP to another and reconnect to irssi running in screen, to break a connection and try the next one, and to recover from occasional lockups (more about that later).

~/bin/screen_reconnect

This is a script to reconnect continuously via ssh to a screen session:

#!/bin/sh
reset
while ! ssh -t 10.9.8.7 'screen -UDr' 2>/dev/null ; do echo -n "." ; sleep .1 ; done

Just substitute the IP of your own server here. Using an IP instead of domain name makes the connection faster because a DNS lookup is not required.

~/bin/wifi_reassociate

This script closes any open ssh sessions and informs wpa_supplicant to attempt to connect again.

#/bin/sh
/sbin/wpa_cli rea
killall ssh >/dev/null 2>&1

~/bin/wifi_killall

This optional, somewhat ugly script addresses an issue I hope you never have. On my ASUS Eee PC 1001PX, occasionally scanning stops. When this happens, and I have never figured out why, apparently ACPI events are blocked. At this point wifi becomes unusable and ACPI sleep is inhibited. By trial and error I found that if you bring down the interface, kill all network-related processes, and bring it up again, ACPI events are unblocked and wifi is usable once more (and any pending request to sleep will finally happen). The script requires sudo, and to use the openbox key binding, gksudo.

#/bin/sh
sudo ifdown wlan0
# in case any of these are hung
sudo killall dhclient3
sudo killall wpa_cli
sudo killall wpa_action
sudo killall wpa_supplicant
# in case any of these are *really* hung
sleep 1
sudo killall -9 dhclient3
sudo killall -9 wpa_cli
sudo killall -9 wpa_action
sudo killall -9 wpa_supplicant
sudo dhclient -r
sudo ifup wlan0

Openbox

Since certain actions need to be performed repeatedly and quickly, it is useful to have hotkeys bound in your window manager to the scripts. In ~/.config/openbox/rc.xml, key bindings for <alt>-r to reassociate and <alt>-d to disconnect a hung connection would look like:

  
<keyboard>
  <!-- My keybindings -->
  <keybind key="A-R">
    <action name="Execute">
        <execute>/home/synrg/bin/wifi_reassociate</execute>
    </action>
  </keybind>
  <keybind key="A-D">
    <action name="Execute">
        <execute>gksudo /home/synrg/bin/wifi_killall</execute>
    </action>
  </keybind>
</keyboard>

Putting it together: on the server

There is very little to do here. Just start screen, and start irssi in screen. Running screen on the client as well as the server means you should either bind the screen meta keys to a different key sequence on each system, or else learn to press meta twice to pass through meta to the server screen as needed. I use the latter approach. Alternatively, you could use a tabbed terminal on the client, or separate terminals per client process instead of screen. This is a matter of personal taste.

Ready to roam

Here is a typical setup for roaming on the bus:

In a terminal (I use urxvt), first ssh-add, then start screen with these three processes running in separate virtual terminals:

  • /sbin/wpa_cli
  • screen_reconnect
  • wavemon (optional)

March of the dots

Most of the commute, just enjoy watching the dots march by, waiting for a new connection. If you estimate a connection is unusable, press <alt>-r to reassociate immediately, giving the next network a chance. If the connection is already firmly established, this might not work on the first try. If the dots don’t resume immediately, wait a bit and press it again. This might take a few tries.

Changing selected networks on the fly

Use wpa_cli when you need to do some fine-tuning of network selections on the fly. While normally you can just watch the march of the dots until a connection is acquired, sometimes you can improve your chances of connecting to a good network by manually controlling the selected candidate networks here.

For example, by watching the speed of the bus relative to known “good” APs, you can predict which networks are more likely to succeed. Rather than connect to any arbitrary network, you might select a specific one by id, and then later when it goes out of range, revert to the original configuration, e.g.

> select_network 5
...
> reconfigure

You can use tab-completion in wpa_cli to type these commands quickly or else just abbreviate the commands.

Another common scenario is when you pass through a business area with many captive portal hotspots. These rarely make good choices because they either require a password not known to you or else you can’t click through “I agree” in time before the bus moves on. In this case, you might just disable the catch-all stanza and let the common open network stanzas you listed (“default”, “linksys”, etc.) do the work:

> disable_network 1

Become a type ahead wizard

While running, a continuous stream of periods fills the screen, which provides you with a highly visible cue that no available APs are in range. When the movement stops, you know a connection is being attempted.

While waiting to connect, you can type ahead any comments you want to make in the current irssi window (taking care to remember which one you are in!) While having periods interspersed in what you type may be disorienting at first, you get used to it.

There is a point when a connection is first established and ssh is accepting input, but anything you type can no longer be seen while you’re typing. Depending on whether the connection was completely successful or not, what you type now may or may not finally be sent. For best results, only type ahead before the dots stop moving.

Eventually you can become skilled enough at this to type ahead a comment in one channel, switch channels with /win # and continue typing ahead in the new channel, all buffered until the next few seconds (or even fraction of a second) of connection time.

Fine-tune antenna direction with wavemon

When the bus has come to a standstill, you may find wavemon useful to pull in a weak signal. Because wavemon has continuously updated signal level and link quality bars, you can use it to fine-tune the antenna position. Just turn your laptop until the bars are at their maximum.

Captive portals

I have not figured out how to do any automation for this, so it really is a crapshoot, as it is likely the bus has moved on by the time you’ve managed to manually navigate the login through a captive portal. But in rush hour, you may have the luxury of time to connect to these as you pass them. I have recently learned about the CoovaFX Firefox plugin which automates logins to captive portals. I’m going to give it a try to see if it helps. Update: I can’t recommend this plugin, as it is not compatible with Iceweasel >= 23.0. Also, the standard it is based on, WISPr, appears to have an uncertain future. That, coupled with the fact that the plugin appears to not be open source means I’m still looking for alternatives.

Summary

If all of this sounds a bit nuts to you, well, it probably is. But after half a decade enjoying free access to irc from the bus, it all seems perfectly natural to me! If you try this method and like it, please let me know in the comments. Likewise, if you have any improvements to the process or scripts, please share them!

Debian-eeepc now has atl2 ethernet

With Kel Modderman’s help, we now have a working atl2 driver for the Eee PC. This brings the Debian-eeepc project one step closer to providing a pure Debian replacement for the Xandros OS that ships with the unit. Now that Asus has released the GPLed source that was missing before, we now just have to ensure both the atl2 and asus_acpi modules get merged upstream.

The driver for the wifi in the Eee isn’t under the GPL, however, and therefore only works on the Xandros kernel provided with the default OS. Since I really can’t live without wifi and it is not my first choice to buy replacement hardware, in the interim, I’m living with using the Xandros kernel and modules on Debian. I can learn from studying the Xandros components in action, but it’s not a solution I’m happy with in the long term. The Debian-eeepc project’s goal is to produce a pure Debian solution, at least as far as that is possible given the hardware present in an unmodified system. On that front, I think the best bet is for ath5k to support the particular Atheros chip in the Eee. (Yes, I know about ndiswrapper, but for both technical and philosophical reasons I won’t use it.)

Debian-eeepc: the ideal mobile text editing device realized

The search for the ideal mobile text editing device is over. While the price was well over my original budget, we’ve since gone ahead and splurged on two new Eee PCs: one for me, one for my wife. In the end, I think it will be worth it because these systems are capable of far more than just editing text.

Now comes the challenging part. Xandros is the default OS and we want Debian on it instead. I have started supplementing the system with packages from Etch and Etch-backports using apt pinning, but already I have noticed some cracks beginning to develop: with pure Xandros, an SD card was automounted when it was inserted. Now it fails. Also, the Network utility no longer launches. I can work around these glitches for now, but it is plain that in the long term this Xandros/Etch hybrid is going to be more grief than it is worth.

To that end, enter Debian-eeepc. Building on the work started by timbobsteve and drawing from the collective experience of the Eeeuser.com community we will make a debian-live cd + debian-installer to install Debian (as pure as possible—obviously the kernel is going to be our most contentious issue) on the device. So stay tuned for more articles on that work-in-progress.

And how does my new toy shape up for mobile text editing so far? I’m delighted! For starters, this article was drafted on the bus home from work. The keyboard, while small, is still quite usable for touch-typing, the display is crisp and bright, and the size is just perfect for the cramped quarters of a public transit bus seat.

But beyond just editing text, I have loaded up the system with all of the tools that go around it: subversion, git, ruby, gcc, meld, etc. I’ll be able to manage a fair amount of development on the bus, with the exception being really large builds that will continue to be done on remote build systems.

Adequate mobile text editing device

Ideal mobile text editing device redux

As I read the responses1 to my search for the ideal mobile text editing device, reality began to set in. The heating season is now upon us, and even used technology meeting my criteria would likely exceed my stated budget. Furthermore, I’d risk replacing my current issues with a whole new set of issues and end up with a less-than-ideal mobile text editing device.

So I have rethought the problem and have decided it would be best to work on with what I have now while I wait for this ideal device to arrive on the market.

Keyboard

While I can’t change the keyboard of the ZR-5000, with a practiced lighter touch on the keys I can, in fact, touch-type passably well. It has served me well enough to draft several blog articles so far.

Software

Although not up to the high standard set by Vim, for quick note-taking, I don’t really need a fancy editor. My thoughts flow directly through my fingers into the device with only light editing. Cut-and-paste, motion keys and delete are the bare essentials. Anything more is a frill.

Synchronization

I do have an ACTiSYS IR-200L infrared dongle for my PC. The trouble is, although this is supported in Linux using IrDA, the ZR-5000 insists on speaking ASK-IR which is not supported.

There is a Windows-only program, ZRLink, which might work. I’ll try it either on an XP system at work, (… mixed reviews out there as to whether it will work on recent Windows,) or under Wine. I can get the dialogs to display properly on Wine, but I have my doubts about whether serial emulation works. My initial tests at home under Wine indicate it doesn’t. (Could #277618 have something to do with this?)

There is a 15-pin serial connector on the device, but I have no cable for it. And there’s a PCMCIA slot, but compatible devices are likely limited to older, harder-to-find components: either a 2M CF card or a modem card. While I have the latter, it exceeds the power available from batteries and I have no DC adaptor for the unit.

Perhaps I overrate synchronization anyway. My best articles are rewritten from scratch more than once.

Summary

Living in an embarrassingly technology-rich country, it is too easy for a geek like me to convince himself that his gadget cravings are needs whereas, in fact, there is still plenty of life left in the devices he already has. After all, my venerable ZR-5000 was given to me by a fellow who figured if any one of his friends would still be able to use it for something, it would be me. Well, I won’t let him down. I’ll stick with it and make it work.

There is one virtue of this device I doubt if any modern device of the same form factor can match. After a week of daily use, I still haven’t had to change the 2 ordinary AA NiMH batteries. Top that.

1 Thanks, everyone, for your responses. Although there were the inevitable few that mentioned modern devices way over my budget, and I’ve decided now to stick with the ZR-5000, your suggestions did help me bring the real issues into focus.

Ideal mobile text-editing device

Dear Lazyweb,

I’m looking for a small, (easily fits on my lap on the cramped seat of a bus,) inexpensive, (around $100 CAD,) mobile text-editing device with a 90%-sized keyboard and decent battery life that runs an open source OS and Vim, and that I can sync to my desktop system.

My first mobile device was a NEC PC-8201A, circa 1984. It ran on 4 AA NiCad batteries which I hardly needed to change more than once a week. At the time, it was my ideal mobile notetaking device. Its near-full-sized keyboard, Wordstar-compatible text editor, terminal program and serial interface allowed me to take notes which I would sync to my father’s Mac at home or to the VAX at the university.

Today, my mobile computing needs have hardly changed: text editing is almost all I do. I don’t ask for much of a display, but as an 80 to 90 wpm touch-typist, I won’t settle for anything less than a near-full-sized keyboard. I’d prefer a system that runs Debian, and Vim is a must. Some means of easily synchronizing the device with my home system is necessary: PCMCIA wireless-B would be ideal, but is not a must-have.

At the moment, I’m using an old Zaurus (not Linux-compatible) ZR-5000 which has good battery life but a very cramped keyboard, poor software, and no functional means of synchronizing the device to my PC. OK for jotting down quick notes, but frankly, I’d rather have my PC-8201A back again. I could at least type on it and sync it across the serial cable.

I took a brief look at various Psion models, but they appear to be near-impossible to find. The HP Jornada 720 looks intriguing. And the NEC Mobilepro 780
appears to be another possibility. Have I overlooked anything?

So, suggestions please.