PoTTY v.0.62 Testing Begins!

Last week, Simon Tatham announced the release of PuTTY v.0.62 which included a security fix that seemed serious enough to fire up the old compiler and shit out a new version of PoTTY.

I got to work on it last night and have the working binaries ready to rock and roll as soon as I can get them all tested.

This has gone much faster than the last time. I started hacking away at 1AM this morning and had a working PoTTY binary by 3AM. After a few hours of Sleepy Time I banged away at it and had the entire PoTTY "suite" done by noon.

Sometimes I amaze myself.

Not this time, though. I had a little help from our friends at AT&T. You see, we still have a land line here at Hinky House. For about a month the line started to degrade and it finally got so bad we had to call them out to the house to check the line.

Apparently the line had rotted out, so they replaced it. For a few days the new line laid on top of the lawn. Then on Thursday some time after 9AM they buried the line.

Cutting our CATV cable—and our Internet access—in the process.

So basically I had no distractions. I thought it would take a lot longer to "get 'er done" than it did, so in the process I decided to move the code over to VC++ 2010 Express, which I really haven't touched since I installed it. I thought that would add a half a day to the project but I was pleasantly surprised the transition went as smooth as it did.

Versions 0.60 and 0.61 were VC++ 2005 and 2008, respectively. 0.60 took forever to write. 0.61 took a whole weekend. I thought the cable would be fixed before I was finished, but it wasn't.

It still hasn't been fixed. And I have a funny feeling they're going to come here and say "we'll be back Monday" if they get here at all today.

Right now, I'm jacking in to the Web courtesy of one of my neighbors. The less said about that, the better, but in the process I learned an interesting lesson about using iwconfig (on BT5) to connect to open access points.

I couldn't stay connected for more than a dozen pings at a time. Then I noticed that whenever the link died the connection rate had been negotiated up to 30-54Mbps, which is not going to happen over your garden variety 802.11b link. You have to limit it yourself, since the default is "auto".

Check the man page. You'll figure it out.

UPDATE:

12/17/2011 — They fixed it. Now we have a coax cable running across the lawn. Maybe they'll cut AT&T's line when they bury it. This could go on forever!

UPDATE:

12/18/2011 — I missed a lot of cosmetic touches, mostly replacing almost every instance of "PuTTY" with "PoTTY". Then I checked to see what version OpenSSL was up to. Sure enough it had gone up a click since PoTTY 0.61 to version 1.0.0e. Building OpenSSL on a quad core machine is a lot more fun than on the old box 0.61 was built on.

After all that, I have what I believe to be the final build.

I checked to see if the old RDP back-tunneling issue had been fixed, but no luck there. Same old Black Screen of Death.

Another issue that might be Windows' problem concerns IPv6. I have had several PoTTY sessions connected over IPv6 that lasted for days and then all of them crash all at once. I have never seen this with IPv4. I'd like to get a Wireshark capture of this happening, but like I said it takes days of waiting.

The Unending Saga Of the Disappearing Access Point

Yeah... about that.

I rewrote my scripts to double-check the availability of the AP. It waits 30 seconds and checks again. The "problem" disappeared immediately.

That lasted about a month before it came back. Now, it dies about twice a week. Seven times since rewriting the script, and only once when anyone was at home to notice it (and no one did).

It's not a power failure issue, since it's on the UPS. It is using POE (Power Over Ethernet) now, so that's another change.

The next step is either triple-checking or using a dedicated wireless NIC to do the scan.

BT5 on a Stick

A STICK!!!!

I've been running BT5[r1] as a "disposable OS" almost every day on a laptop for months now, booting up from a CD. Great stuff. Boot up, do your dirty work, shut down, and all the evidence is gone.

A few weeks back I installed the BT5 ISO to a USB stick with UNetbootin and tossed the CD forever. Excellent perfomance. Now it boots up fast and quiet. But there's one tiny issue: it still thinks it's a CD so I have to run my apt-get script every time to get the utilities I can't live without. I thought I could get the same performance by installing the OS itself onto stick, so I bought a cheap 16G thumb drive and tried it out.

Boy was I wrong!

I installed using the defaults and booted the stick up. It was dog shit slow—slower than using a CD at times—but it was still usable. Disappointing, but usable.

After a few days of this I did some research to see what I did wrong. And I found that it's not a good idea to install onto USB using the ext4 filesystem (the default). Either ext2 or UVFAT (formerly known as UMSDOS) is recommended, and UVFAT doesn't work on 2.6 kernels.

I reinstalled to ext2 and booted the stick up. It didn't boot because it switched from sdc during installation to sdb at boot time. Editing grub.cfg took care of that, but after rebooting it was still dog shit slow. Not sure why that wasn't a problem with ext4.

So I decided to simplify things. Instead of messing around with multiple partitions I made one big one and used a swap file instead of a swap partition. This offered a mild improvement but it's still a dog.

There must be a better way.

Oh and by the way... if you've ever installed BT5 to anything, you will find that the last 1% of "almost finished copying files" does indeed take for-fucking-ever. With the ext4 install, it took twenty minutes. With the ext2 install, it took from one hour to "screw it I'll check it in the morning". So be patient. And don't use a CD. Install it from USB.