Extra Pepperoni

To content | To menu | To search

Tag - super-tent

Entries feed - Comments feed

Tuesday, August 29 2006

EarthLink Sucks

So http://www.brooklynfreespace.org/ needs an Internet connection for 2 700MHz eMacs. Earthlink is cheap for decent speed. I ordered a couple AirPort Extreme cards, a Linksys WRT54GR, and DSL service (and Kid Pix 4 Schools).

Those of you who are eMac savvy will know the first problem already -- although the slot (cleverly concealed behind the CD-ROM door) is about the right size, they need an old (802.11b) AirPort card, not an Extreme card. Fortunately I have my father's old AirPort card, which has outlasted 2 iBooks and still works great (it was worth more than the last iBook I salvaged it from -- original blue, with 3gb drive and dead battery).

Second problem: CD-only drives. Target Disk Mode and my PBG4's DVD drive solved that problem.

Now to the good (bad) stuff:

The WRT54GR comes configured for, with DHCP on. The EarthLink DSL modem (which they charged me $20 for, despite telling me there were no set-up charges), comes configured for with DHCP too. Now it's neat that a $20 piece of hardware is a full router with decent NAT control, but I can't access it through the WRT54GR, since goes to the Linksys, and never reaches the DSL modem.

I got them working with Internet access on Sunday, but cannot reproduce yet. Everything is seriously hampered by a strange error that I keep getting out of the DSL modem when I try to configure it. Suddenly, all the configuration pages start returning this:

Protected Object

This object on the P-660R-ELNK is protected

Then I cannot configure the DSL modem until I reboot the Mac I was using. I suspect it has to do with changing IPs on the Mac (perhaps there's a cookie which it doesn't like seeing come from another IP), but haven't figured it out yet. I sent email to Zyxel, in hopes they'll take pity on me and explain what causes this error (and how to avoid it!).

EarthLink assures me that a full reset of the modem (which they didn't tell me how to do, and isn't covered in their docs) will clear the problem. I doubt it, but we'll see.

So to get support, they want me to use web-based chat. Except that to open a chat session, I have to answer some questions, and click a radio button confirming that the answer wasn't in their knowledge base, and when I Submit the form, I get an error that I didn't check the button. So it's impossible to get support with Safari. I fire up Firefox, and am able to get past that barrier. So much for the first Mac-friendly ISP!

Today, the chat applet didn't drop my characters, or crash Firefox -- a big improvement over 2-3 weeks ago, when I used it to get pre-sales info (and they told me there was no set-up charge).

Also, the school's EarthLink email address was 31 characters. The service is PPPoE, which requires me to enter the address, into a box which only allows entry of 30 characters! I tried without @earthlink, and it didn't work. So I went to EarthLink's support site, and tried to change the email address. I tried three times, and each time it told me I had mis-entered the captcha. It's 5 upper-case letters -- apparently they can't even get that to work in Safari!

So I got someone from EarthLink to change my email address, and I told him that (since they're obviously selling more DSL than dial-up), they should either fix the stupid Zyxel web page to remove the stupid HTML attribute that prevents more than 30 characters in the address field for PPPoE, or warn people when they create email addresses > 30 characters. I asked the rep to tell someone about the 30-character limit, but doubt it happened.

So today (actually yesterday, by now), I sent email explaining the problem to support@earthlink.net. I get back an auto-response telling me to use their web form. I fill out the web form (again, doesn't work in Safari, so I have to use Firefox), and describing my problem, I get a page that tells me they don't take this type of query by email! I try another, and am again stymied.

Oh, well. That much frustrated effort, trying to help EarthLink fix their problems, requires that I point out their idiocy in a public forum.

Update: I managed to send my report via their Feedback form, which warns me not to expect an answer. But perhaps someone will read it.

Not holding my breath.

And again, this was the Mac-friendly ISP! (Open Door Networks was cool, but never local to me) I remember seeing EarthLink folks getting started at MacLeak's MVB events pre-Expo, back in the day!

Update: No thanks to Earthlink, I eventually figured out that if I used a self-assigned IP address (instead of one assigned by the DSL modem's DHCP server), I always got this error. Dumb. People who use static addresses are much more likely than average to use the DSL modem's configuration interface.

Friday, August 25 2006

bash: Clearing History

The excellent bash shell keeps a history of recently executed command lines and lets users cycle through them with up/down arrow, edit commands, and re-execute past commands.

Every once in a while, I make a mistake and type a password at a bash prompt -- today it happened because I had a remote session waiting for a password, which timed out, so I typed my password at the "Password:" prompt, but my workstation noticed the connection was down and dropped me into bash, which failed to execute my password (because it's of course not a valid command), and helpfully cached it on disk for future shells to take advantage of.

The quick fix is "history -c", to flush the whole history (and Command-K in Terminal or whatever's necessary in a different terminal program to clear the screen and scroll-back buffer).

A less drastic step is to use "history | tail" to find the line number of the bad command, and "history -d 503" (or whatever the appropriate line number is) to clear just the bad line, preserving the rest of the history. Further details are available with "man bash".

Tuesday, August 22 2006

Apple Keychain: Problems with Intrusiveness & Encrypted Disk Images

I find the Apple Keychain very useful, but need to protect my keys -- apparently more than Apple anticipated. On all my machines, I used to have my login keychain set to close after a couple hours of "inactivity". This was very intrusive, as it also locked SSHKeychain, even if I was actively using ssh keys (since Keychain didn't know SSHKeychain was actively being used). I recently discovered the security command. Now I have a cron job which flushes my login keychain when I'm done working for the day/night on all my machines, and it's enabled me to crank up login's inactivity timer. Twice a day, cron runs "security lock-keychain ~/Library/Keychains/login.keychain".

Locking the Keychain has revealed several problems (which I have reported to Apple). First, .Mac syncing assumes the Keychain is always unlocked. This makes a certain amount of sense, but means .Mac syncing doesn't really work unless you leave your .Mac password always available in a keychain. To address this, I use a separate keychain (lowsec) for the relatively low-security .Mac password -- lowsec never locks itself (until I reboot). I'm not happy about this, but it's the best I could do without giving up the one really useful .Mac service.

This leads to the second problem (a straight bug): extra password prompts. If I use my account password for my login keychain, it should be automatically unlocked whenever I unlock the screensaver (just as it's unlocked when I log in after a reboot). But it isn't. I still get prompted to unlock my login keychain after unlocking the screensaver. What's worse, I often get a couple prompts for my login keychain, and on an untrusted laptop I typically get a couple more for lowsec (for a stalled .Mac sync, and to set my iChat status). On the laptop, SSHKeychain is set to lock my keychains when it sleeps, and SSHKeychain is not selective -- it locks all keychains (also reported to Bart).

The untrusted laptop found another serious problem. I don't trust FileVault, so I created a 2gb AES-encrypted disk image with Disk Utility. I moved ~/.ssh and ~/Library/Keychains (yes, I know about ~/Library/Caches/) onto the disk image, and created symlinks from the original locations. The bug I found is that, if the Keychain can't be used (perhaps, say, because ~/Library/Keychains is a dangling symlink, and it's configured to use one or more keychains there), Disk Utility is unable to present the password dialog for an encrypted disk image. This meant because I'd "broken" the Keychain by dismounting the disk image containing my keys, I was unable to remount the disk image to "fix" the keychain, because the broken keychain was preventing disk mounting! I escaped the vicious circle by moving aside the symlink and creating a new ~/Libraries/Keychain directory, which un-broke the Keychain enough that I could get the disk image back online. Now I leave ~/Library/Keychains/lowsec in the normal place, so the Keychain is functional, and manually specified the locations of my (normally unavailable and mostly empty) keychains on the disk image, so they're available when it's mounted.

Friday, August 18 2006

ssh sessions hang when adding a higher-priority network connection

I have an MBP which is always connected via AirPort. When I come back to my desk, I typically plug it into an Ethernet cable, on a different (more trusted) subnet.

If I have any ssh sessions open when I bring up the Ethernet connection (which is of course faster and prioritized above AirPort in SP:Network), the ssh sessions hang. If I notice quickly, I can disconnect Ethernet, finish my work (if possible), and disconnect before plugging back into the Ethernet, but this shouldn't happen. The ssh connections are established on the AirPort interface, which is not disturbed, and should remain usable even when an additional connection is introduced.

I have reproduced this behavior on a PBG4 and an MBP, both using the latest

Friday, August 11 2006

Security Flaws: AFP-over-SSH Broken

After a discussion with Rich Mogull, where we both agreed that AFP is a threat (note that Apple fixed 4 different AFP threats in Security Update 2006-004), I decided to require ssh tunneling for AFP connections to www.reppep.com. Apple provides a neat feature for automatically tunneling AFP through ssh, but unfortunately it's broken in half a dozen ways...

My initial report:

It is impossible to connect to an AFP server without access to port 548 -- this should work if ssh is available, and AFP-over-SSH is enabled. Instead, with 548 blocked by a firewall, the AFP connection times out -- even using an alias created when connected via AFP-over-SSH.

Connect To Server should accept afps://host as a scheme that specifies AFP-over-SSH. Instead it gets converted to afp://afps/host, which is wrong and nonfunctional.

It's impossible to require ssh for AFP from the server.

It's impossible to support AFP on the server without leaving port 548 open, even though with ssh tunnelling 548 shouldn't be needed.

Note: These are not exploits, but they are real problems with the security of Mac OS X (Server

Apple has redefined sleep

For a long time, Apple's put an LED on all Macs. When it's flashing, the machine is asleep. Modulo some limitations on "deep sleep" imposed by non-compliant PCI cards, sleep has been very simple. When a Mac is asleep, it's almost off -- it consumes very little power, and you can't do much besides wake it up. When you wake a Mac up, it comes back to full functioning quickly.

I have a MacBook Pro at work, and strongly believe computers should never sleep -- I do most of my job via ssh, without looking at whatever system I'm working on. So I always set System Preferences > Energy Saver > Power Adapter to Never sleep.

Intel-based PCs have several different low-power modes, including at least one ("hibernate") where they save the contents of RAM to disk, so the machine can completely shut off but still "wake up" without booting again. This type of behavior will feature more prominently in Vista. Apparently booting Vista is so slow that people are going to spend real money for large flash drives to reduce booting...

Anyway, Apple has apparently redefined the meaning of the white LED on the MacBook Pro. Even though I'd set cayenne (my MBP) to never sleep when plugged in, I kept noticing that while on my desk, the screen would go black and the LED would flash. "Hmm, this is not as intended!", I thought.

I checked "pmset -g", which confirmed sleep cayenne was configured never to sleep when plugged in, but it kept happening. I called Apple to ask about this, and was told that the LED meant the MBP was indeed sleeping despite the configuration. I reset the power manager a few times, and Apple sent me a box. Wednesday I got cayenne back, with an upgraded logic board, but after sitting on my desk, the screen again went black, and the "sleep" LED again started flashing.

"Hmm," thought I, "perhaps Alex was right and 3 Apple Support reps were wrong." Alex had told me that the LED flashing on his MacBook did not mean it was in fact sleeping, but foolishly I believed Apple Support and my own historical experience instead.

I was able to ssh into cayenne while the LED kept blinking, which proved that it wasn't really asleep in the PowerBook sense at all.

Moral of the story: Apple upgraded my logic board through ignorance of its own equipment, and I lost use of the MacBook for a week because I didn't take Alex's word for it.

Update: It's more complicated. The documentation doesn't match my experience, and Apple actually started changing the sleep behavior with the next (final?) generation of PowerBooks, released immediately after my 1.5GHz PBG4.

Sunday, June 4 2006

USENIX 2006, Boston

I just got back from USENIX in Boston, which was interesting. You know you're at a good technical conference when all the rooms have open wireless, and each table has a power strip...

But why wasn't there a session on advanced SSH???

This year's social event was (watching the penguins at) the Aquarium. The poor BSDers didn't get to visit with Beastie, though. I got a bunch of pics and a little video (snake