A few weeks ago, the fan in my trusty IBM T42 bought the farm.  This resulted in the unit heating up considerably, as well as numerous "fan error" messages on bootup.  It eventually became so bad that to boot up at all, I had to blow compressed air into the fan's exhaust grill for 5-10 seconds, in order to fool the BIOS and make it believe the fan was actually spinning.

Since IBM didn't recognize the FRU that was required (13N5442), I ended up picking up a used heatsink / fan assembly from ThermalFX for $40.

The installation was fairly straight forward, except for removal of the GPU's thermal pad, which had essentially glued itself to the ATI chip.  I also oops'ed, and used a wrong screw when putting everything back together, which resulted in a small dimple on the palm rest.

I also took lots of photos.

I tagged along for an iPhone quest…

ATT store in Ballantyne:

And, I waited over an hour to hold one for 5 minutes:

The Ballantyne store sold out, but the one near Carolina Place had some in stock. 2/3 of the people I went with walked away with iPhones.  *sigh*

Some more photos.

I finally got around to documenting some of my new weird network lab at home.

If you're wondering why ObexFS seems to not work anymore, it's probably because you've upgraded FUSE to 2.6.4.  Downgrade to 2.6.3, or take a chance and upgrade to 2.6.5!

Yeah, it's hot during the summer.  32°C every day, in the shade.

Lots of lizards:

Beaches aren't so crowded.  I suspect the majority of the population is up north, to escape the heat:

Neat-looking birds:

More photos are here.

Server move complete!  Lower latency, more speed, larger disks, etc.  See here for some stats.

Also, I found out the hard way that RRD files are architecture-dependent.  Since dax moved from FreeBSD/i386 to FreeBSD/amd64, I had to convert all the files to XML on an i386 box, then back to RRD on amd64.  Lots of fun, but some bash scripting made it easier.

If anything looks odd, let me know.

So, my parents recently decided to ditch CableVision and switch to Verizon's FiOS package for HD television, Internet (20/5), and telephone service.  Since I still have a Linux box at their place terminating VPN connections and providing NAT, I stopped home for the installation.

Be advised that I have a fair bit of hatred for Verizon as a company, mostly because of their evil cellphone-crippling practices and because they are in direct competition with the company I work for.

I took tons of photos.  They can be found here.

Installation

The whole installation process took slightly over four hours (10:00 to 14:01) which was apparently very fast, even with two technicians working in parallel.

First off, the tech. let us know that he had to pull fiber from a nearby pole, approx. two houses away, and said that it would take a couple hours to complete.  That's when he called someone else to help out, since I guess he didn't want to be there all day (and we actually needed to leave for NYC at 15:00..).  I directed him to the basement, where the current coax and phone lines made their way into the house.  He asked where the computer was, and I just pointed at my aging IBM ThinkPad T20, since it was mostly disposable.  It was then when he said he would be installing a router, so I asked him if I could use my own.  Flat out no, which was also the answer when I asked if there was any way to give my own router a public IP address, or configure their router to accept incoming connections (thinking DNAT..).  That already rubbed me the wrong way, but I figured I could work through it later.

He then went around installing the box on the side of the house, which had a couple connections: fiber transceiver, 2x RJ11 jacks, a 1x RJ45 jack labeled Ethernet, and a coaxial plug.  A battery backup was installed in the basement, that I was told would power the box on the side of the house for up to five hours (and last five years before replacing).  He made it very clear to me that lasers need electricity to operate, since I guess some other customers didn't understand the need for the batteries.

A couple hours later, they were ready to setup the Internet access, and one of the technicians proceeded to whip out a Verizon-rebranded Actiontec router with a coax port and 5-port switch (1-port dedicated to WAN connectivity).  They split the coax from the box outside between the television and the router.  I found this puzzling, since I expected them to run CAT5 from the box outside, directly to their router.  I later found out that the coax interface actually follows part of the MoCA spec, and is capable of a couple hundred megabits in each direction.

With the Actiontec router powered up, they connected the T20 to one of the switch ports, and it received 192.168.1.2/24 via DHCP, with a gateway of 192.168.1.103 (uh, I didn't ask).  It appeared that we were online, at that point, since when they popped up IE the default Microsoft page appeared.  The tech. typed in www.activatemyfios.verizon.net first, which threw a DNS error, and then removed the www. prefix.  A ZIP code was entered, and he had me enter an email address and password.  After setting up yet another useless email account, some ActiveX control started downloading almost 100MiB worth of software, and required a reboot.  The poor T20 was left with several additional icons on the desktop, as well as a branded Internet Explorer browser.  Yuck.  Glad I used a disposable machine.  I just left that as is, and proceeded with the remaining installation tasks.

The television setup was pretty simple.  My parents have a 46" Sharp Aquos and a 20" CRT, so they naturally got two different STB's, both Motorola.  The HD one appears to be an OIP6201 (?), while the non-HD model is a DCT2500.  Both work well, but some of the HD channels have noticable compression artifacts, possibly due to sloppy encoding.

At 14:01, everything was done.

The Router

Here's where things started to get a little bit annoying.

First off, although I'm not shocked about it, since (lately) ISPs are taking more and more control away from the residential customers, I'm rather annoyed that I'm supposedly not allowed to to run my own router, whether it be a OpenWrt'ed WRT54GL or even a Cisco PIX.  What if I want to pin up an IPSec VPN with main mode, when NAT-T isn't available, or maybe use 6to4?  It feels like some sort of cheap "Hotel" Internet access.  Maybe I'm just old fashion (or a control freak?), but I believe if a residential ISP is going to dedicate a public IP per subscriber, they should, at the very least, allow it to be bound to an interface on CPE equipment.

Anyway.. I logged into the Actiontec router, changed my password, and was presented with a good selection of network and firewall-related options, surprisingly.  I'm fairly sure the box is running some version of Linux, since the logs kept referring to Linux-style interface names, but it could just be VXworks, too.  From the looks of it, the coax interface was configured as a DHCP client, and wireless and the built-in switch were configured to hand out IPs in the 192.168.1/24 range.  There were also options for port forwarding, DMZ host, and static NAT.. looked good so far.  The software also presented bridging options, which is pretty much what I wanted.  If I could turn the box into a bridge, I figured I'd be all set.  However, it appeared that even though you can bridge the coax and Ethernet ports together, it's impossible to disable the DHCP client on the coax interface, which prevented the whole setup from working correctly.  I'm thinking it's some Verizon patch to the software, since every time I disabled the DHCP client, after a few page refreshes, it was once again enabled, and online.  Scratch that idea.

At first, thinking the Actiontec box was just a cable modem, I figured it wouldn't hurt to try out the old Surfboard cable modem that was used w/CableVision.  No dice.  It didn't even lock onto the downstream frequency, since MoCA operates on a different bandwidth.

Since I was fed up at this point, I connected my Linux box [nat] to the Actiontec router and enabled the DMZ feature.  I also disabled DHCP and selected a small random IANA-reserved (in the 2/8 range) network instead of the 192.168.1/24 subnet.  I was lazy, and didn't want to update tons of iptables rules that are configured to deny any RFC1918 traffic through the external interface.  I brought up a couple of my OpenVPN tunnels, and was back online.  I was still annoyed, but at least things were working.

The next day I decided to upgrade the aging UPS that powered the Linux box and a couple other things.  After restarting the Actiontec router and Linux box, I found that none of the VPN connections came back up.  A couple packet captures revealed that port translation was occurring for the UDP ports that OpenVPN was configured to use.  Basically, I have both sides of the VPN tunnel using the same port directive in the OpenVPN configuration file, so either side can bring up the channel.  The port selected is used as both source and destination port, so if port translation is being performed, the VPN won't come up.  I didn't want to make the tunnels one-way, so I plugged in some random rport and lport's, matched them up, tweaked firewall rules, and the VPNs came back up.  So, it seems that the dumb router not only is bugged by Verizon, it also has some problems with UDP connections where the source port is the same as the destination port.

One hack after another, but it's still working at time of writing.

Performance

Well, advertised speed is 20/5, and that is what I get:

Resolving ftp-atl.osuosl.org... 64.50.238.52
Connecting to ftp-atl.osuosl.org|64.50.238.52|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian-cd/4.0_r0/i386/iso-cd ... done.
==> PASV ... done.    ==> RETR debian-40r0-i386-businesscard.iso ... done.
Length: 33,615,872 (32M) (unauthoritative)

100%[====================>] 33,615,872     2.46M/s    ETA 00:00

Latency is another story, it's a little high to several destinations.  Although AS19262 (VZGNI-TRANSIT) has several dozen peers, the majority of the traffic doesn't appear to utilize them, and paths to most destinations take a UUNet (owned by Verizon) route.  Inbound traffic seems a little more diversified.

Conclusions

Although the installation wasn't too painful, and the Internet performance is great, I still have some reservations about the HD quality and included Actiontec router.  I also wonder how Verizon can possibly offer a 50/5 plan over coax, unless they are using DOCSIS 3.0, which I highly doubt.

Update 20070617:

I found some instructions for turning the Actiontec router into a bridge.  They didn't work for me, though.

So, it appears that randomizing the source and destination ports worked for awhile, then abruptly stopped working.  Port translation was happening once again!  Rebooting both boxes did not do the trick.

I decided to call Verizon and see if they would just enable the Ethernet port on the ONT box.  I asked them several times, and all I got was no no no.  I even threatened them with service cancellation if I couldn't get this to work.  So, they called up Actiontec in India and conferenced me in.  (I figured I'd play along, what do I have to lose, but an hour of my day?)  After some back and forth with them, I was told to downgrade the firmware of my router from 4.0.16.1.45.160.27 to 4.0.16.1.45.160.  So, assuming that they knew of some issues relating to UDP-based VPNs, I did this, and the OpenVPN connections came up (after compensating for an IP change, and an unexpected configuration purge).  I then asked the lady in India why exactly I was told to downgrade, and if they could give me a description of the issue that is apparently present in the .27 code.  She went away for a minute, then came back and said that there is a known issue with .. get this .. SurfControl.  I told her I wasn't using SurfControl, and asked how these two things were related, and she said they weren't!  Huh?  I was pretty confused at that point, so I told them I would just call them back tomorrow if things started getting randomly translated again.  So far, it's still working, so maybe there were some undocumented changes to the NAPT that is performed for the DMZ host, with the newer release.

Truly a horrible experience if you want to just use your own hardware.  Avoid at all costs.

I just finished putting up a motd about this, so I figure I should post it here, too.

During the week of June 10th, 2007, the server that powers this website (and its DNS) will be moving from Parsippany, New Jersey, to a new Voxel Dot Net, Inc. facility at 111 8th Ave., New York, New York.  Supposedly, this facility is in the most connected building on the eastern seaboard, so bandwidth and latency should not be a concern.  Here are some links.

• Voxel Dot Net Expands its Optical Network
• 111 Eighth Ave. - Meet Me Room
• Google Taps Fiber with Manhattan Move

In addition to just a server move, hardware will be upgraded to the following:

• Intel Core 2 Duo E4300
• 1GiB System RAM
• 2x 250GB SATA Disks
• FreeBSD 6.2-RELEASE

IPv4/IPv6 addresses and VPNs will not be affected, and all user data will be migrated prior to the cutover.