Software Use

Here's how I set up tethering from my ThinkPad T400 running Debian Lenny (5.0) to my iPhone, based on an article at Adam Harvey's Five Minutes. This is a quick post more for my own reference than anything else.

On the iPhone, open Settings -> General -> Bluetooth. Set Bluetooth on.

Run hcitool scan and note the MAC address of your iPhone's Bluetooth adapter. It is 00:26:b0:00:00:00 here.

Add the following to /etc/network/interfaces:

iface bnep0 inet dhcp
    pre-up /bin/sh -c 'echo enable > /proc/acpi/ibm/bluetooth'
    pre-up /bin/echo -e '\n*** On the iPhone, open Settings -> General -> Bluetooth\n'
    pre-up /usr/bin/pand -r PANU -d NAP -A -E -S -c 00:26:B0:00:00:00 -e bnep0 -n
    post-down /usr/bin/pand -k 00:26:B0:00:00:00
    post-down /bin/sh -c 'echo disable > /proc/acpi/ibm/bluetooth'

To enable tethering, open Settings -> General -> Bluetooth then run ifup bnep0. Wait for the dialogue box to pop up on the iPhone then respond with Pair. The computer should soon receive a DHCP lease from the iPhone.

To disable tethering, run ifdown bnep0.

Setting up my iPhone's Mail to connect to an IMAP server (uw-imap) was a bit of a hassle. For some reason, the client would remain stuck at Verifying IMAP account information indefinitely[1] while the server log indicated Command stream end of file, while reading line and nothing else. It wasn't an SSL issue, nor was it a password issue; the process would cleanly fail when an incorrect password was entered, and tcpdump showed that everything was encrypted and going through port 993.

Having experience troubleshooting IMAP+SSL settings, the first thing I wanted to do was to connect on port 143 and then switch on encryption with STARTTLS. While I don't claim to know why that makes a difference, in reality it often made the problem go away, so I looked for an Advanced menu on the iPhone to give it a try. Bad news: while the account setup process had an Advanced menu in iPhone OS 1, starting in version 2 it was removed. This functionality became only available in the Settings application, only available after the account is already set up. Unfortunately, I could see no way to get to this Advanced menu, not even by first skipping the verification step and setting up a non-working account. No, the software was far too user-friendly to allow either of those things to happen.

In the end, I had to make two distasteful changes to my mail configuration — thankfully only temporarily — in order to make the verification step go away so I could access the Advanced menu so that I could actually enter the real configuration. First, I had to reconfigure inetd not to listen on 993/imaps, so that the iPhone would back off from trying to make that work and ask me if I would like to connect without SSL. Second, I had to allow plaintext cleartext logins on 143/imap2, so that the iPhone, in its only "non-imaps" attempt, would not fail to log in due to not being allowed to send plaintext logins without STARTTLS. After making these changes, and clicking through the non-SSL dialogue box on the iPhone, the mail client finally managed to validate the account settings and move on.

(For anyone reading this to try to troubleshoot a similar problem, here are the steps I took. Note that this is not intended to be a tutorial in system administration. To disable the imaps service, edit /etc/inetd.conf and comment out the appropriate line, then HUP the inetd. To enable plaintext cleartext logins to uw-imapd, create a file /etc/c-client.cf containing the following two lines: I accept the risk (newline) set disable-plaintext nil.)

After the account settings were validated on the iPhone, I immediately re-enabled the imaps service and re-disabled cleartext plaintext logins to uw-imapd. Then I went into the Settings application and dug down into the Advanced menu for this mail account. I enabled SSL and set the server port to 143. I started another tcpdump session then opened Mail. Mail pulled up the mail in the account, tcpdump showed a connection to 143 and a STARTTLS followed by encrypted traffic, exactly the behaviour that should have taken me half a minute to configure had the iPhone OS not tried to be excessively user-friendly. It was finally working.

Thank goodness I run my own mail, meaning it was actually possible for me to do this. (I do have a handful of users; I hope I didn't inconvenience anyone!)

The obvious lesson here for software developers is to be careful not to go too far in trying to hide the details from the end user. Make an Advanced menu; as long as it's labeled as such, only those who need to be there, and the curious, will go in; and if you're afraid that users will fiddle settings inside then call for help when it doesn't work, speaking from years of technical support experience, let me tell you that ingenious fools will manage to shoot themselves in the foot no matter what you do. Put another way, as Einstein said, make everything as simple as possible, but not simpler.[2]

[1] There was a timeout of sorts: after several minutes the Mail application apparently crashed and the iPhone returned to the Home screen.
[2] Close enough.

While setting up tethering over Bluetooth from a Windows XP netbook to a BlackBerry Curve 8300, I encountered a problem where the "Verifying username and password" stage of dial-up networking would hang, and then a 718 error would appear after several minutes.

After some web searching, I came across a blog post that had a pair of useful (to my situation) comments:

Vecheva said...
I'm also running an IBM ThinkPad and get Error 732: blah blah could not agree on PPP protocols. Anyone else have this problem?
4/02/2007 09:37:00 AM

Vecheva said...
Never mind. I was able to solve the problem by disabling LCP extensions under the Configuration for PPP. I kept software compression enabled.
4/02/2007 10:04:00 AM

And that was the solution. Now, watch me flex my help desk muscles.

Open the Control Panel. In Network Connections, right-click the BlackBerry connection, then click Properties.

In the Properties window, select the Networking tab, then click the Settings button.

In the PPP Settings window, de-select the Enable LCP extensions option. Optionally, also de-select the Enable software compression and Negotiate multi-link for single link connections options. Click OK to close the PPP Settings window.

Click OK to close the Properties window.

That should be it.

Lesson learned? When implementing a protocol that has extensions, make sure to detect when those extensions aren't supported. I'm not sure whose fault this one is, whether on the computer side or the phone side, but somebody wasn't doing proper error checking.

This starts out a little off-topic for this site; but, as it comes from after spending a couple of hours this evening hacking on and thinking about a software problem, I think it belongs here.

Sun recently released a Linux x86_64 version of their new Java browser plugin, libnpjp2.so. This is really great news for anyone running 64-bit Linux as it means Java applets can now run in the Sun JVM without resorting to installing a 32-bit browser. Of course, given how recently this was released, it hasn't made it into many distributions yet. Fortunately, according to the Internet, it's as easy as unpacking the JRE somewhere sensible (which means not in OS-controlled directories like /usr/lib/jvm; try your home directory, /usr/local, or /opt) and making a symlink to libnpjp2.so from ~/.mozilla/plugins.

After downloading the latest JRE (1.6.0_13 at this time) I realised that it was a binary installer. I hate binary installers. The Windows software culture that makes it easy to fool users into running random things (such as malware, including trojan horses and DRM rootkits) as Administrator is rooted in the custom of binary installers. Now, as binary installers go, this wasn't the most horrible one that I've seen, as it doesn't demand to be run as root, and as it's actually a shell script sitting on top of what appears to be a self-extracting ZIP file, but it was still a binary installer, and the self-extracting ZIP file was still a binary blob. I didn't run it. Instead, after picking it apart and seeing what it was, I just unzipped it. The whole file, shell script and binary blob claiming to be a self-extracting ZIP file and all, went through unzip, which detected the ZIP header buried inside and started from there.

I really wondered why Sun tried to make me jump through hoops just so I could unzip some files. I can't imagine they believe the license is any more or less enforceable as a result of displaying it, especially since it can be cleared after showing just the first screenful.

However, after making the symlink to the plugin inside the newly extracted JRE, Firefox (3.0.8 as packaged in Ubuntu Intrepid) would crash out as soon as I loaded any applet, printing the following:

Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

I tried setting JAVA_HOME and even PATH, as some forum posts suggested, and I even tried moving aside /usr/lib/jvm temporarily to see if there was an unfathomable conflict. It didn't help.

Finally, I stumbled upon the answer by doing something I should have done earlier: I inspected the binary installer more closely. It turns out that it doesn't simply execute the self-extracting ZIP file. It also meddles around in the newly extracted directory and packs up some jar files. (I knew that; the JRE/JDK installer has been doing this dance for as long as I can remember, which is apparently not very long at all.) With that remembered fact in mind, I set up another user on the machine, switched into it, and ran the binary installer. It executed the self-extracting ZIP file, meddled around in the newly extracted directory, and exited successfully, leaving one directory containing the extracted and meddled JRE. Then, after I moved the correctly "installed" JRE somewhere sensible, applets loaded and all was well.

The lesson here is that binary installers are a gigantic failure. The Unix software culture does not include their use. Certainly half-clued software vendors have been hawking software for Unix systems that come as a binary installer for decades, but this is a distasteful exception. What purpose do binary installers serve? If they merely produce files in a directory, then there are many trustable ways of achieving this; if the user is suspected of being inept, a shar file accomplishes the same thing with full transparency. If they meddle around in the system, especially with root privileges, well, they shouldn't! With complicated OS detection functions they needlessly restrict their use to specific releases from specific vendors, almost always severely out of date; and without they make invalid assumptions about the system and trample all over it. Worse, as I suggested above, they train the user into believing that it's normal to run things without thinking, perhaps even as root, and that notion is a security vulnerability that absolutely cannot be removed once it's been installed in the user's mind.

The other lesson is that, when encountering a binary installer, it often pays to pay close attention to what it does. I think that holds true whether one decides to run it or not.

Getting the plugin to run in the end was a bonus, though a really nice one.

The current generation of web frameworks tend to process one request at a time, and depend on multiple instances running in order to handle multiple simultaneous requests. This is certainly convenient as it allows the programmer to ignore a great deal of concurrency concerns. Of course, this also means that a slow-running request can cause a backlog, even while other instances are sitting idle. Check out this screencast about HAproxy showing one solution to this problem.