I’m in fairly creative mood tonight, as evidenced by one (now two) blog postings, the PHP coding I did earlier, and the upload of some 75 random pictures to Facebook. I guess that’s what happens when I avoid the work I really should be doing. (Blech, JavaScript.)

Anyways, a few days ago a coworker mentioned something to me about duck typing, and I again decided to shirk my responsibilities and experiment. The basic idea is to stand typing on its head and have an imperative system rather than declarative — as they say, “if it walks like a duck, and quacks like a duck, it must be a duck.”

Read more »

(The term High-Definition appears to be able to be applied to anything these days, so why not webcams?)

For the past few days I’ve been obsessing watching this webcam over at the Red Rock visitor center, and just now I wrote a quick script to fetch the latest image and update my desktop background with it. It’s almost like having my desk near the window back. (OK, not even close.) But, truth is, it makes a pretty crappy background at 1920×1200. Look at this other one in comparison — now that’s a webcam.

Then I remembered. Since buying a used 20D, I have an old D30 just sitting around. With a bit of Canon software magic, that can easily be setup to take a shot at any interval and automatically transfer it to the PC. I just have to write a little plumbing to get it up on the web.

I want to do this!

A lot of people know that OpenSSH’s client supports tunneling out of the box. But some don’t realize that it also supports tunneled SOCKS out of the box. Here’s how to set up a quick SOCKS proxy across an encrypted tunnel:

ssh -NfD 8888 user@host

The proxy will be on port 8888. The other flags just tell ssh to go immediately to the background (after getting your password, if needed) without running a command.

I’ve started trying to train myself to use Google Reader: rather than trying to remember all of the sites that I want to visit each day, and having to visit each one independently, I can go to one place and view them all. Sure, these are all benefits of RSS readers, and everybody else discovered them years ago. What can I say, I’m slow.

Anyways, Google Reader caches things on its own (which makes sense), and that has a peculiar effect: if Reader hits up the RSS feed while an article exists, and then the author decides to delete said article, said article will appear in Reader, but not on the site.

Which is where I find myself right now: I have an entry from Matt entitled, “A More Perfect Blog,” that shows nowhere on the site. So… where’d it go, Matt?

Tonight I installed dnsmasq as a caching DNS forwarder on our home network (under a VM, no less). Additionally, I changed our primary DNS servers to those hosted by OpenDNS. To double-check that things were working, I figured I’d whip up a quick script to make a bunch of DNS requests and give an average time. First round, I faced the OpenDNS server against Cox’s own. I’d never really benchmarked the Cox DNS servers, so this was quite enlightening:

andrew@ubuntu-server-vm:~$ php ./dns_bench.php dothedrew.net 208.67.222.222
Average response time: 27.53
andrew@ubuntu-server-vm:~$ php ./dns_bench.php dothedrew.net 68.105.28.11
Average response time: 158.58

This only serves to strengthen my belief that all cable ISPs are run by pharmacists.

To satisfy morbid curiosity, here are the results against the local dnsmasq daemon:

andrew@ubuntu-server-vm:~$ php ./dns_bench.php dothedrew.net 127.0.0.1
Average response time: 0.21

That’s only about, oh, a 755x improvement. Hopefully that’ll sufficiently speed things up.

After discovering that, if left up to Vonage, the D-Link VTA-VD device I just purchased off eBay would be useless, I became determined to get it working.

Turns out, my initial idea of cloning the MAC address from my old Vonage adapter was amateur (at best): while this changes the MAC address that the adapter uses for Ethernet communication, it must still report the old address to Vonage when it’s being provisioned. Long story short, changing the MAC address had no effect whatsoever.

I did, however, discover that the VTAs apparently run an embedded flavor of Linux (cool!) with an SSH daemon installed and running by default (cooler!). Unfortunately, it uses a different account than the web interface (bummer). A glimmer of hope was the instructions for unlocking various SIP devices, include the D-Link VTAs. But I was shutdown yet again: the manufacturers have apparently gotten smarter and started patching up the security holes that people have been hacking into.

Now it’s down to the wire. Wireshark, that is. I used Microsoft’s bundled ICS to become a gateway on my wired NIC, which is attached to the VTA via a cross-over cable. Then I started sniffing traffic. It looks like the VTA now has DNS server addresses hard-coded into the firmware, removing the easy way to rewrite DNS requests. ARP spoofing? But it’s definitely making a request for an XML provisioning file, which I was also able to download. Unfortunately, it’s encrypted.

Maybe this is more trouble than it’s worth.

I’ve had Vonage for just about three years now. Over the past year or so, our phone line has probably been down more than its been up (the miracle of technology). I’m not ready to blame that on Vonage, however, since the adapter itself appears to be on its last leg. While trying to reconfigure it a few weeks ago, I realized that the integrated switch (it’s a combined router/switch/VTA device) was no longer working. I also noticed that the device was inordinately hot, so I’ve chalked it all up to hardware problems initiated by overheating.

In the hopes of salvaging our home phone, I ordered a used VTA device from eBay. I didn’t think twice about it; it’s definitely not the first piece of technology that I’ve acquired second hand, let alone from eBay, and I’ve had very few problems with any of it.

Of course, I made the assumption that Vonage would allow me to activate a used device. That was apparently not only a naive assumption, but also a fatal one.

As chronicled in various parts and pieces here, here, here, and probably many other places, Vonage apparently refuses to reassociate the MAC addresses of their VTAs (unless, of course, it’s been “reconditioned” by them).

Did I just buy a paper-weight? I’d be more than aggravated.

Obviously, as most of us know, this is purely an artificial limitation imposed by Vonage. Why? Are they worried about people recording the MAC address, selling the device, and then cloning it to steal calls? Do they get a little bonus for selling new devices? I have no idea.

The worst part, however, might not be their refusal to reuse a device. I could live with that, had only I know before I spent money on something that’s (currently) useless. But even with a bit of searching, I can’t find a single warning from Vonage on the dangers of buying used. I can describe this as nothing short of irresponsible, almost criminal.

So the moral of the story is, and I’d say this in big bold, emblazoned letters if I thought that it would somehow get it more exposure across the interwebs: whatever you do, don’t use Vonage. Erm, I mean, don’t buy a used Vonage device.

Like the good deviant I one day hope to be, I’m currently in the process of attempting to clone the MAC address of my previous adapter on the new one. The device supports twiddling with the MAC address, but, once I changed it, has been unaccessible (at least from work via the various SSH tunnels I have going). Yet if I delete it’s DHCP lease from the router it immediately reacquires one, so I’m thinking it’s caught up in some endless reboot cycle after attempting contacting Vonage. I’m going to keep digging.

This post tells the humorous story of how a regular consumer hacked his neighbor’s wireless AP, then proceeded to lock his neighbor out of it with a new password, MAC filter, & c. Only to discover that his neighbor had, in fact, retaliated by hacking his wireless AP. Or something like that.

Use your Wii-mote to create a multi-touch system.