Updates:
May 29, 2001 ntpd, xmodmap
June 2, 2001 ntpd again
June 29, 2001 X server
October 10, 2001 Thinkpad 240
October 12, 2001 802.11b networking
March 19, 2002 Link to solution for slightly different NTP problem
(Updates are at the bottom)
I've recently bought a ThinkPad 240X to use as my daily laptop. It's not enormously powerful and the 800x600 screen is not huge but it's very small and light so it's not annoying to carry it in my courier bag on my motorcycle. eCost.com seems to have them (albeit not the most recent version) at a fire-sale price.
The information here is based on my personal experience. I hope that it's useful but I don't guarantee that it is correct or that it will be useful to you. If you find something unclear, misleading, or wrong, or you have other suggestions for improvements, please mail me at matt@mondoinfo.com.
I decided to install Red Hat Linux 7.1 on it and the installation was pretty straightforward. There were only a couple of things that needed fussing with but I'll run through the installation briefly first in case that's of use to anyone.
First, I shrunk the Windows partition to about 3GB of the hard disk using Partition Magic (a great program) and formatted the remaining 3GB as a Linux partition. I don't know if the formatting was strictly necessary but it didn't hurt. I created the PCMCIA boot floppies according to Red Hat's instructions and did the installation using a cheap pretty generic PCMCIA CD-ROM from Addonics. I accepted the defaults for the laptop installation and the installation went just fine, including automatically creating partions for swap and /boot. I would have liked it better if the installation had told me a little more about what it planned to do, but the defaults mostly turned out to be fine.
I found the graphical lilo screen to be really ugly but it turns out to be easy to get rid of it by removing the message line in /etc/lilo.conf and running /sbin/lilo.
It turns out that the X server that's installed by default doesn't work very well with the 240X's video chipset. I found that if I booted from power off to Linux and ran the X server, I'd get funny transparent windows and menus that weren't where they were supposed to be. Booting into Windows and then rebooting into Linux without powering down fixed the problem.
It turns out that Red Hat distributes XFree86 version 4.0.3 servers in 7.1 in addition to the version 3.3.6 servers that are installed by default. And, happily, the 4.0.3 server that's appropriate for the 240X has that bug fixed. After poking around a bit, I found that Xconfigurator has the command-line option --preferxf4 and running it with that option installed a server that works just fine. If there's a way to get Red Hat's installer to install the 4.0.3 version in the first place, I didn't see it. But running Xconfigurator after the installation is done is pretty painless.
Of course, you wouldn't want to specify that the machine should boot into X, at least until you had the right X server installed.
The only other thing that took some manual fiddling is the ipchains firewall that I let the installer go ahead and install. I'm not absolutely sure that I want a local firewall on this machine but I'm inclined to leave it in place for a while and see how it works out in practice.
Since ipchains is set up to act as a pretty normal firewall, if you want to run any servers on a machine that has it installed, you need to specifically open the appropriate ports (it's often necessary to tweak /etc/hosts.allow too). Since I run sshd on all my machines, I needed to add:
-A input -s 10.0.0.0/24 -d 0/0 22 -p udp -j ACCEPT
-A input -s 10.0.0.0/24 -d 0/0 22 -p tcp -y -j ACCEPT
to /etc/sysconfig/ipchains (replace the IPs with those appropriate for you).
It also seems that ipchains (pretty reasonably) doesn't associate inbound UDP packets with outbound ones. Since I want to run ntpd, I needed to explicitly allow UDP packets on the NTP port from the appropriate host:
-A input -s 10.0.0.4 -d 0/0 123 -p udp -j ACCEPT
My 3Com 3CXE589ET PMCMIA Ethernet card works fine in the 240X as does my Zoom 2975LA PCMCIA modem. There may be a way to get the built-in Lucent Winmodem to work under Linux but since I already had the Zoom card, I haven't yet tried.
Update May 29, 2001
ntpd
(Kevin Salt has written a description of a way to deal with a similar but different synchronization problem. Link at the bottom.)
It turns out that getting ntpd to run correctly on the 240X is a bit of a nuisance. It will run on a vanilla machine but it won't sync to a time server. Instead it will step the clock constantly. Here's an extract from my log:
May 18 19:26:42 test ntpd: ntpd startup succeeded
May 18 19:26:42 test ntpd[699]: ntpd 4.0.99k Thu Apr 5 14:21:47
EDT 2001 (1)
May 18 19:26:42 test ntpd[699]: precision = 15 usec
May 18 19:26:42 test ntpd[699]: using kernel phase-lock loop 0040
May 18 19:26:43 test ntpd[699]: frequency initialized 62.112 from
/etc/ntp/drift
May 18 19:26:43 test ntpd[699]: using kernel phase-lock loop 0041
May 18 19:47:29 test ntpd[699]: time reset -3.378527 s
May 18 19:47:29 test ntpd[699]: synchronisation lost
May 18 20:29:13 test ntpd[699]: time reset 1.131065 s
May 18 20:29:13 test ntpd[699]: synchronisation lost
May 18 20:51:45 test ntpd[699]: time reset 0.272887 s
May 18 20:51:45 test ntpd[699]: synchronisation lost
May 18 22:40:22 test ntpd[699]: time reset 1.155248 s
May 18 22:40:22 test ntpd[699]: synchronisation lost
That's just an extract, the same thing would go on for days. It seems that APM (Advanced Power Management) stuff confuses ntpd.
In order to get the clock to sync, you need to turn off APM in the BIOS and in the kernel. Turning it off in the kernel is easy, it's done by giving the apm=off parameter to the kernel when booting or adding a line to /etc/lilo.conf. Red Hat gives details.
Turning it off in the BIOS is also straightforward: On boot press F1 for the IBM BIOS Setup Utility. Drill through the menus Config and Advanced Setup to Power. Under Power set Power Mode for AC to Customized (if you don't, the options below it are ignored). You probably want to leave Power Mode for Battery set to Maximum Battery Life unless you're likely to have a network connection and thus access to a time server when running on batteries. Then set Suspend Timer to Disabled.
It took me a little while to figure that out and there's a bit of irony here: It's probably almost pointless to run ntpd on a laptop even though I've done it for years. It's probably quite sufficient to use ntpdate (or, with a very recent version of the package, ntpd -q). ntpdate (part of the package with ntpd) just sets the clock once by brute force. It doesn't try to keep it synchronized with the time server. Here's why I think that's probably about as useful: Most laptops are rebooted once a day or more and switched off for hours at a time. While the machine is off, time is kept by the CMOS clock on the motherboard which, in the case of the laptops I've owned, seems none too accurate. So a little after the laptop is booted, ntpd is likely to find a difference that requires it to step the clock.
Here's a log extract from another laptop:
May 29 17:37:25 test2 xntpd[573]: synchronized to 10.0.0.4, stratum=4
May 29 17:37:26 test2 xntpd[573]: time reset (step) 1.088362 s
May 29 17:37:26 test2 xntpd[573]: synchronisation lost
May 29 17:41:43 test2 xntpd[573]: synchronized to LOCAL(0), stratum=10
May 29 17:42:46 test2 xntpd[573]: synchronized to 10.0.0.4, stratum=4
May 29 17:42:46 test2 xntpd[573]: kernel pll status change 89
The laptop was off for about half an hour and that step occurred about 5 minutes after it was booted.
Since most laptops don't usually stay on for more than 12 hours or so at a time, even without the help of ntpd, the kernel clock will probably not go too far wrong.
So when running ntpd on a laptop, you're likely to get a decent-sized clock jump some time shortly after boot and then a stable clock. Running ntpdate at startup (at the bottom of /etc/rc.d/rc.local for example), you're likely to get a decent-sized clock jump right after boot (which is better than 5 minutes later since it's less likely to confuse something) and then a clock that slowly drifts out of sync. And with ntpdate, you won't need to remember to turn APM on and off in the kernel depending on whether you're running on batteries or AC. Neither is obviously and always better than the other, but ntpdate requires less fuss.
Update May 29, 2001
.Xmodmap
Here are a few lines from my .Xmodmap that I find convenient. The Teletype model ASR-33 that I learned to program on had the control key to the left of the A. In my opinion, any keyboard that has it anywhere else is defective, broken, and wrong. So this plays a little game of musical keys: it puts Control on the 240's Tab, Tab on the 240's grave/tilde key (where it belongs, above the new Control), and grave and tilde on the 240's left Control key.
! Fix some slightly goofy key positions on the 240. Tab becomes
control,
! grave becomes tab, and Control becomes grave.
remove Control = Control_L
keycode 0x31 = Tab
keycode 0x25 = grave asciitilde
keycode 0x17 = Control_L
add Control = Control_L Control_R
Update June 2, 2001
ntpd
It turns out that the init script (/etc/rc.d/init.d/ntpd) that's part of Red Hat's RPM for ntpd anticipates that you might want to run ntpdate before starting up ntpd. If the file /etc/ntpd/step-tickers exists, the startup script calls ntpdate using the server named in the file. (Actually, it works for me only if I put the IP, not the name, in the file presumably because between PCMCIA and DHCP initialization, the network isn't really ready to do name lookups by that time.) Very handy. Except that the ntpdate command line has the -u flag which directs ntpdate to use an unprivileged port and the firewall won't allow that. It works of you remove the -u flag from the line and I haven't been able to think of a reason not to do that.
Update June 29, 2001
X server
Clarified the text of the section on the improved X server. Thanks to Brian M. Spindel for pointing out that the original text was unclear.
Update October 10, 2001
Thinkpad 240
I've been playing with a Thinkpad 240 (the predecessor to the 240X) and as far as I can tell, everything here applies just as well to that machine with the possible exception of the need to turn off APM in order to get ntpd to work right.
Update October 12, 2001
802.11b wireless network
802.11b wireless Ethernet hardware has gotten cheap enough that I decided it was time to add some to my network.
802.11b is Ethernet (MAC addresses and all) over short-range (generally tens to perhaps hundreds of meters) radio. You plug a "wireless network access point" (they could have just called it a radio hub) into your Ethernet network and plug wireless LAN cards (radio Ethernet cards) into one or more machines and throw away your cat-5.
Around here, it's not that much harder to plug a Thinkpad into cat-5 and AC current than it is to just plug it into AC (and the battery life of a Thinkpad 240X isn't all that great so it does generally get plugged into AC) but a wireless network has a certain cool-factor to it and, um, I really need to know about this technology for my clients. Yes, that's it. A consultant definitely needs to know about this important and tax-deductible technology.
Anyhow, my local Micro Center was having a sale so I went and got a Linksys WAP11 Instant Wireless Network Access Point and a Linksys WPC11 Instant Wireless Network PC Card. The total came to around US$200.
You configure the WAP11 hub using a Windows app that talks to it over a USB cable. Actually, the documentation suggests that it can also be configured using another utility (also on the CD) that talks to it over (wired) Ethernet using SNMP. That suggests that it might be possible in principle to configure the thing without using Windows and without having a USB connector. But since the SNMP MIB doesn't seem to be documented anywhere that's obvious and we're talking about Thinkpad 240s here which have Windows and USB ports, I didn't bother to investigate that any farther. I keep a small Windows partition around for just this sort of thing.
The hub has an IP address (the default is 192.168.1.250) but it doesn't appear to need one except for being configured by SNMP. Since I configured mine over the USB cable and I don't care about gathering statistics from it by SNMP (if indeed it collects any and the MIB is published somewhere), I left the default address alone. That address isn't on my network so it's not reachable from outside my network. That way, if there should be a security problem in the unit, it would be very hard for someone to exploit it. I have no reason to think that there is any security problem with the unit but good network administrators are paranoid.
There isn't much to configuring the unit. Mostly, it's a matter of specifying the ESSID ("Extended Service Set ID", they could have just said "a name for this radio hub"), turning on WEP ("Wired Equivalent Privacy", that is, encryption), and specifying a key.
The ESSID is just a string that identifies the network based on a particular hub. As for encryption, the WAP11 supports only 40-bit WEP encryption. It seems that 40-bit WEP has some limitations. But it's surely better than nothing. In the defense of the people who wrote the spec, they did call it Wired Equivalent Privacy. And it's probably true that cracking it is about as hard as sneaking in here and sniffing Ethernet frames off of the cat-5.
Interestingly, all the hardware seems to accept 4, 40-bit WEP keys and you specify which of the 4 to use. I can't begin to guess why. You can also specify the key as a string that's then hashed into the 160 bits of the 4 keys. (It appears that only 5 characters of the string are significant.) Since I don't know how good the hash function is, I specify my keys as 10 random hex digits.
I installed the WPC11 card under Windows on my 240X first to make sure that it worked, and it worked just fine. Oddly, the card will support 128-bit WEP though the hub will only do 40-bit. But alas, the driver that's loaded when the card is inserted under Red Hat 7.1 won't do encryption at all. (The same seems to be true of all cards based on the Prism II chipset.) It worked fine with WEP turned off on the hub but wouldn't communicate with the hub if the hub had WEP turned on. /sbin/iwconfig would take the appropriate commands and display the right status but no data moved. It seems that there may be a driver that supports WEP with the Prism II chipset but I've already compiled one too many kernels.
So I returned the card to Micro Center (they were very nice about it) and ordered an Agere (formerly Lucent) Orinoco Silver PCMCIA card from Micro Warehouse since Micro Center didn't have one. It was a few dollars more than the Linksys card but, heck, we're in this far.
As with the WPC11, I got it working under Windows first. (Happily, it seems that there aren't many interoperability problems with 802.11b hardware.) Since the 240X's CD uses its PCMCIA port, the installation was simple but not quite perfectly straightforward. To do the installation, I first connected my CD drive to the machine's PCMCIA port and inserted the CD. The installer ran automatically so I quit it. I then ran Windows Explorer and copied the contents of the CD to a folder in a handy location. Then I ejected the CD, stopped the CD's card from the taskbar, and ejected the CD drive's PCMCIA card. Then I inserted the Orinoco card. When Windows asked where the new card's driver was, I told it to look in the DRIVERS/Win_98 directory that was somewhere in the stuff I had just copied over. Windows gave me a chance to edit the profile for the card (ESSID and WEP key) and the installer complained that the client manager wasn't installed. Then I rebooted and started using the card.
I decided to configure the card manually under Linux first since rebooting to try a configuration change is a nuisance. So I booted the machine with no PCMCIA card at all. Once it was up, I inserted the card (fully, it requires a little more force than other PCMCIA cards I've used) and got Linux's PCMCIA software's happy beep. A check of the syslog showed that the card had been recognized:
Oct 11 17:15:58 localhost cardmgr[636]: initializing socket 0
Oct 11 17:15:58 localhost cardmgr[636]: socket 0: Lucent Technologies
WaveLAN/IEEE Adapter
Oct 11 17:15:58 localhost kernel: cs: memory probe 0xa0000000-0xa0ffffff:
clean.
Oct 11 17:15:58 localhost cardmgr[636]: executing: 'modprobe wvlan_cs'
Oct 11 17:15:58 localhost kernel: wvlan_cs: WaveLAN/IEEE PCMCIA
driver v1.0.6
Oct 11 17:15:58 localhost kernel: wvlan_cs: (c) Andreas Neuhaus
<andy@fasta.fh-dortmund.de>
Oct 11 17:15:58 localhost kernel: wvlan_cs: index 0x01: Vcc 5.0,
irq 3, io 0x0100-0x013f
Oct 11 17:15:58 localhost cardmgr[636]: executing: './network start
eth0'
Oct 11 17:15:58 localhost kernel: wvlan_cs: Registered netdevice
eth0
And a check with /sbin/ifconfig said that the machine now had an eth0 device. Then to configure the eth0 device:
# /sbin/ifconfig eth0 up
# /sbin/ifconfig eth0 10.0.0.42 netmask 255.255.255.0
and to configure the card:
# /sbin/iwconfig eth0 essid example
# /sbin/iwconfig eth0 rate 11M
# /sbin/iwconfig eth0 enc on
# /sbin/iwconfig eth0 key deadbeef00
and to configure routing:
# /sbin/route add default gw 10.0.0.254
and to see if it all worked:
# ping 10.0.1.200
PING 10.0.1.200 (10.0.1.200) from 10.0.0.42 : 56(84) bytes of data.
64 bytes from 10.0.1.200: icmp_seq=0 ttl=252 time=20.962 msec
64 bytes from 10.0.1.200: icmp_seq=1 ttl=252 time=19.950 msec
And all was well.
To convert that to a boot-time configuration was just a matter of editing the top of /etc/pcmcia/wireless.opts. Here's the new version:
# Lucent Wavelan IEEE (+ Orinoco, RoamAbout and ELSA)
# Melco/Buffalo Networks WLI-PCM-L11
# Note : wvlan_cs driver only, and version 1.0.4+ for encryption
support
*,*,*,00:60:1D:*|*,*,*,00:02:2D:*)
INFO="Wavelan IEEE example (Lucent default settings)"
ESSID="example"
MODE="Ad-Hoc"
RATE="11M"
KEY="deadbeef00"
It appears that the authors have a driver for the Orinoco card that's newer than the one shipped with Red Hat 7.1 but I plan to stick with the old one until I run into a problem. As of this writing, I have only a day or so's experience with the card but haven't had any problems yet. If I find anything more interesting, I'll add it here. Oh, and it is really cool.
Update October 20, 2001
up2date
Red Hat recently made new kernel packages available that fix an important bug. I consider upgrading the kernel to be a big nuisance not because it's really all that hard but because of the consequences if something goes wrong. Though not recently, I've managed to render systems unusable by botching kernel and C library updates. Since I installed Red Hat 7.1, I've used up2date to keep the installation current. Generally speaking, that has been a minor convenience: getting an updated telnet server with a few clicks rather than a few dozen keystrokes is nice but no big deal. I was a little concerned about using it to upgrade the C library but everything went fine for both new packages that Red Hat has made available.
Since I didn't much look forward to upgrading the kernel RPMs by hand, I was pleased to see that Red Hat said that up2date would do the job as long as I had up2date 2.5.4 or later (check with up2date --version). I was a little concerned about turning up2date loose on the kernel packages but I was a little concerned about doing it myself, too.
As it turns out, I needn't have been concerned. up2date upgraded the kernel with as little fuss as upgading the telnet daemon.
March 19, 2002
I received a very nice note from Kevin Salt about his solution to a slightly different NTP sync problem. His laptop has an oscillator that was sufficiently far off that ntp wasn't converging and he has posted his solution here. He also has information there about getting XFree86 to switch automatically between his laptops's display and an external monitor there.