Note: Be sure to read my Update to this post

When trying to update my shiny new iPod via iTunes on Windows XP, I kept getting the following error:
Delayed Write Failed
Windows was unable to save all the data for the file x. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.

The iPod would lockup and I’d have to reset it to get it to work again. After some research I found the cause: Write Caching was disabled on my hard disks. Because iTunes tries to push as much data as possible as quickly as possible, Windows was unable to keep up, resulting in the error.

To enable Write Caching on your hard disks:

Start > Control Panel > System > Device Manager > Disk Drives > Properties > Policies > Enable Disk Caching

Note that this option was unavailable to me (grayed out), and after some research I realized it was because I had the Intel Application Accelerator installed, which turns OFF write caching and prevents you from enabling it. So after a quick uninstall of Intel Application Accelerator and a quick reboot, I was able to enable Write Caching on my hard disks, and now the error is gone and my iPod is updating as expected.

I’ve been a Winamp diehard since the beginning. Back before CNN even knew what MP3 was, I was using my 14.4 modem to download, download, download, and using Winamp to listen, listen, listen. I love WinAmp and have been a loyal user since v1.0, but I have to admit that the past couple years have left much to be desired. The way we listen to digital music has changed over the past couple years, and Winamp was starting to feel inadequate to handle things like 35GB music libraries. On top of that, it just doesn’t seem stable or fast any more. Here are some problems I’ve had with WinAmp:

• The random shuffle sucks. It often seems to like a certain “section” of a huge playlist and stay in that general area. If I’ve got 20 days-worth of non-repeatable music in my library, I shouldn’t be hearing the same band 4 times in an hour.
• Winamp doesn’t seem to “watch” my library folders very well. In otherwords, if I rip or download some new tunes and stick them in my library, I have to manually re-scan my library and wait 5 minutes for my new MP3s to show up. Sure, I could just schedule a rescan to automatically happen every minute, but that’s rediculously slow and unneccesarily bogs down my system. I want my new music files available for play now.
• As much as I like the modern skin, it sure is a resource hog
• WinAmp doesn’t support the newest ID3 2.4 tags. They’re great for album artwork, grouping (eg: compilation releases, multi-disc sets), auto-normalization for quiet tracks, etc.

I fear change, but these problems more than encouraged me to try out Itunes to see if it would solve them. While it’s been cool so far, there are some things I miss and/or don’t like. Here are some comments:

• The Song Name column is stuck as the left-most column in all views. Why? I like to sort my tracklistings as Artist – Album – Track# – SongName. One problem I’ve always had with Mac stuff is that they assume they know what’s best for me. I know what’s best for ME. This is very annoying, and it makes me feel like a prisoner in my own system. I don’t see any reason why Song Name must be locked as the left-most column, so it makes me very angry. Hey Apple, why am I on lockdown?
• The taskbar doesn’t show the currently playing Artist/Track. So when I have Itunes playing in the background, and I hear a song and want to know who it is, I need to swith to Itunes to find out. This makes me less-than-productive when I’m trying to code or whatever as it forces me to stop what I’m doing and switch appplications.
• Similarly, with Itunes open, the currently-playing-track display only shows either Artist, Song Name, or Album Name, never a combination of the 3. I want the display to show “Artist – Album Name – Song Name,” but of course, that is not an option. To get the information I need, I have to click 3 times instead of just looking at the screen. Sure I can just look down at the playlist, but what if I’ve scrolled far far away from the currently playing track? Finding it again by scrolling is impossible in a 30GB library.
• It would be nice if applications kept the native UI. If I wanted a brushed metal UI I’d use OSX. But I am using WinXP and I expect my apps to look like they belong. I’ve always hated Mac’s widgets (eg: play buttons, volume slider pully things), and it bothers me that when the tables are turned and you’re running non-Mac software on OSX, you’re forced to use their native widgets. But I guess Winamp is the same (non-native UI), so this shouldn’t bother me too much.
• I’m very anal about my file nameing & directory structure, and for some reason Itunes gives me the uneasy feeling that it’s going to magically hijack all my stuff, rename files, re-order directories, and convert eveything to AAC. Perhaps it was all the promps on install asking me if I wanted to do all this stuff. LEAVE MY SHIT ALONE, and just play the freakin’ music.

Overall, Itunes feels more solid and stable than WinAmp, which is pleasant if you’re someone like me who is on their machine all day with MP3s playing. Itunes also wins with their superior ID3 support, as well as the superior playlist shuffling algorithm. The auto-volume adjustment is a godsend, as I was never able to find a suitable compressor/normalizer DSP plugin for Winamp. However, Itunes lacks in terms of customization, and what I would call obvious usability and interface design. This is the utmost ironic thing, because Mac, the supposed “superior user interface designers” fail miserably – and on the simplest of things!

I’m in the process of “upgrading” my desktop, and part of that upgrade includes a cooling overhaul. My desktop is a loud bitch, and my goal was to cool it as best as possible… and more importantly, as silent as possible. As part of my plan to lower the case temperature and get rid of the front air intake fan (as recommended by AMD’s Cooling Guide), I decided to order some Nexus Memory Heatspreaders from EndPCNoise.com to cool my RAM.

Installing them seems easy enough, so easy in fact, that I ran into a few problems. 🙂

First, you must ensure that when sticking your RAM onto the adhesive tape, you line up the RAM exactly in the middle of the heatspreader casing. While this may seem blatantly obvious, even a slight millimeter deviation from center can cause problems when seating your RAM back into the motherboard socket. One of my RAM sticks was slightly off-center in the heatspreader, making it impossible to re-seat the stick. The overhanging edges of the heatspreader were preventing the RAM clip from properly locking into place and seating the RAM. I ended up having to use a pair of pliers to bend the overhanging part of the heatspreader to make it fit.

Second, do not seperate the two pieces of the heatspreader when sticking your RAM to it. The heatspreaders have a little hinge at the top, and in order to close the heatspreader over your RAM, there needs to be a slight bit of head room for the hinges to slide into place. I made the mistake of sticking one half of the heatspreader on my RAM first. I wrongly positioned the RAM flush up against the top of the heatspreader, but this prevented the other half of the heatspreader from clipping back on! Think of it as a 3-ring binder: if you put too many papers in the binder, the binder won’t fully close. I ended up having to attach only one hinge, and the other one (that wouldn’t slide into the other hinge) I had to bend up with a pair of pliers. The provided clips hold both sides of the heatspreader in place well, so I’m not too worried about it, but for a moment there I was worried that I’d have a RAM stick with only half of a heatspreader.

Finally, that adhesive tape is amazingly sticky. If you mess up placing it on your RAM, there’s no going back, so make sure you do it right the first time!

So let this be a lesson to you if you’re installing heatspreaders on your RAM – it may look like an easy no-brainer, but it actually requires quite a bit of attention.

When upgrading my openssl installation, I forgot to include the “shared” option on the ./configure command. So I went back and re-ran “./configure shared” but it errored with:
openssl /usr/bin/ld: Warning: size of symbol `CAST_cbc_encrypt' changed from 496 to 1730 in c_enc.o - did not match any documents.
…and a bunch of other errors. WTF? After a little research I found out that I needed to run “make clean” first to re-compile with shared objects. So a quick “make clean” followed by “./configure shared; make; make install” worked like a charm!

The following is a compilation of posts I made to the Broadband Reports Cox HSI Forum. I am archiving it here for posterity and in the hopes that someone else may come across this and can use my findings and take them further, and that maybe Cox will come clean after they realize people aren’t happy.

After much research it has become clear that Cox is selectively monitoring and dropping certain P2P (Gnutella) traffic. I am in the San Diego area, so I do not know if this applies elsewhere.

Some details:

1) Cox is NOT blocking P2P traffic. “DROPPING” is the proper term.
2) This may be Gnutella specific. Soulseek and BitTorrent both still work fine. I am not sure about other file sharing networks, although there have been reports that WinMX is having the same problems.
2) Cox is selectively targeting UPLOADS only. All other aspects of Gnutella network activity (host connections, downloads) work fine.
3) On uploads, connections are reset right after the HTTP 401 Authorization is given by the uploader. Here’s a little graph to demonstrate (client on left, server on right):
CLIENT ==> sends out search
returns matches <== SERVER
CLIENT ==> sends HTTP GET request
sends HTTP 401 Auth <== SERVER
!!!! CONNECTION MAGICALLY RESET !!!
Sample conversation:
Upload to X.X.X.X:6346 ("BearShare Lite 4.5.0.63") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:123412341234123412341234 HTTP/1.1\r\n
Host: \r\n
User-Agent: BearShare Lite 4.5.0.63\r\n
Range: bytes=0-324965\r\n
Content-Disposition: inline; filename=somefile.mp3\r\n
X-Queue: 0.1\r\n
X-Gnutella-Content-URN: urn:sha1:123412341234123412341234\r\n
X-Connection-Type: Broadband\r\n
FP-1a: \r\n
FP-Auth-Challenge: JUKZSOUFLZ2TOG2KAILXH34JA7WJWK3J\r\n
X-Features: queue/0.1\r\n
X-Node: X.X.X.X:6346\r\n
\r\n--RESPONSE--
HTTP/1.1 401 Authorizing\r\n
Server: BearShare 4.7.0b38\r\n
Content-Length: 0\r\n
FP-1b: \r\n
\r\n
(At this point the connection is reset)

4) In a firewalled situation, outbound GIVs from a firewalled user are reset right after the GIV is received.
5) Cox is sniffing/dropping based on the DATA field of the TCP packet, NOT the packet header (source/dest ports), because uploads are dropped even while running over non-standard (6346) ports.
6) I’m not 100% positive, but Cox may allow uploads to other Cox subscribers in the same area. A few rare uploads slipped through to other Cox subscribers during my early testing. This may have just been a glitch/oversight in their traffic sniffer that has recently been fixed, because I have not seen a successful upload in weeks since. But for sure, all uploads heading outside the Cox area are dropped.

In the below TCPDump you will see a Bell South customer attempt to download a file from me. He makes two attempts. (LOCAL.PORT is me, note PORT is NOT 6346, but another random port, with NAT port forwarding, so I am effectively not firewalled)

1ST ATTEMPT
19:56:00.598539 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: S 910058714:910058714(0) win 65535
19:56:00.598624 IP LOCAL.PORT > adsl-1-139-33.clt.bellsouth.net.50736: S 591457694:591457694(0) ack 910058715 win 65535
19:56:00.714254 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: . ack 1 win 65535
19:56:00.725367 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:56:00.731713 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910058965:910058965(0) win 10240
19:56:00.732075 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910071468:910071468(0) win 10240
19:56:00.736472 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910058971:910058971(0) win 10240
19:56:00.736840 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910071474:910071474(0) win 10240
2ND ATTEMPT
19:57:01.850407 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: S 2222769745:2222769745(0) win 65535
19:57:01.850485 IP LOCAL.PORT > adsl-1-139-33.clt.bellsouth.net.50747: S 2025320299:2025320299(0) ack 2222769746 win 65535
19:57:01.982241 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: . ack 1 win 65535
19:57:01.993511 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:57:01.999252 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222769996:2222769996(0) win 10240
19:57:01.999618 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222782499:2222782499(0) win 10240
19:57:02.003452 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222770002:2222770002(0) win 10240
19:57:02.003816 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222782505:2222782505(0) win 10240
EQUIVALENT BS LOGS (one for each attempt):
Upload from 65.1.139.33 ("LimeWire/4.0.8") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:RJXSPMRB6EZO36USTVEQREOP6XFAM5KX HTTP/1.1\r\n
HOST: XXX.XXX.XXX.XXX:PORT\r\n
User-Agent: LimeWire/4.0.8\r\n
X-Queue: 0.1\r\n
X-Gnutella-Content-URN: urn:sha1:RJXSPMRB6EZO36USTVEQREOP6XFAM5KX\r\n
Range: bytes=0-99999\r\n
X-Features: queue/0.1\r\n
\r\n--RESPONSE--
HTTP/1.1 206 Partial Content\r\n
Cache-Control: no-cache\r\n
Server: BearShare 4.7.0b54\r\n
Content-Type: audio/mpeg\r\n
Content-Length: 100000\r\n
Content-Range: bytes 0-99999/6213632\r\n
X-Gnutella-Content-URN: urn:sha1:RJXSPMRB6EZO36USTVEQREOP6XFAM5KX\r\n
X-Create-Time: 1082000768000\r\n
X-Features: chat/0.1, queue/0.1\r\n
\r\n--RESPONSE FILE--
fileBytes: 6213632
szFileName: "somefile.mp3"
szBaseName: "D:\some\path"
Here’s an upload attempt using -nettt, windump output on top, Bearshare console output on the bottom.
000000 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 62: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: S 790131918:790131918(0) win 65535
000090 XX:XX:XX:XX:XX:XX > 00:06:25:ea:40:b9, ethertype IPv4 (0x0800), length 62: IP 192.168.X.X.MYPORT > 24.243.4.6.1773: S 107096962:107096962(0) ack 790131919 win 65535
061333 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: . ack 1 win 65535
015100 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 635: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: P 1:582(581) ack1 win 65535
004598 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: R 790132500:790132500(0) win 10240
000360 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: R 790145003:790145003(0) win 10240
005326 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: R 790132506:790132506(0) win 10240
000381 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP 24.243.4.6.1773 > 192.168.X.X.MYPORT: R 790145009:790145009(0) win 10240Upload from 24.243.4.6 ("BearShare 4.6.2.1") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:PZWSAFKCQSRZ32CZSKXBUH4VCMMH7M2K HTTP/1.1\r\n
Host: IP.IP.IP.IP:MYPORT\r\n
User-Agent: BearShare 4.6.2.1\r\n
Range: bytes=3932160-4194303\r\n
X-NAlt: IP.IP.IP.IP:MYPORT\r\n
X-Gnutella-Content-URN: urn:sha1:PZWSAFKCQSRZ32CZSKXBUH4VCMMH7M2K\r\n
X-Connection-Type: Broadband\r\n
FP-1a: \r\n
FP-Auth-Challenge: NAAVOYFU5T7NZJ666YT5VCJDRICINWJM\r\n
Content-Disposition: inline; filename="somefile.mp3"\r\n
X-Features: browse/1.0, queue/0.1\r\n
X-Node: 24.243.4.6:6346\r\n
X-Queue: 0.1\r\n
\r\n--RESPONSE--
HTTP/1.1 401 Authorizing\r\n
Server: BearShare 4.7.0b57\r\n
Content-Length: 0\r\n
FP-1b: \r\n
X-Features: chat/0.1, queue/0.1\r\n
\r\n
Cox is sniffing the data field of the TCP packet. So any sort of P2P communication gets dropped by matching the strings that P2P apps use in their handshakes (presumably). So no matter what port your P2P is on, packets will still get dropped simply because of the fact that they are using well-known and publically available P2P handshakes. The other option is to encrypt all P2P handshakes and communication. At that point Cox couldn’t succeed using this method because all their scanners would see is a bunch of jibberish passing through the lines. I’ve talked to some of the P2P developers about that, and while encryption is on their “wish list” it requires a fundamental overhaul of the P2P apps’ codebases, and is a big investment in time and money. In otherwords, encrypted connections won’t be coming to P2P any time soon.

This is a pretty sneaky move by Cox, because it keeps their users happy by allowing downloads, and keeps the RIAA happy by disallowing uploads. However, Cox is interfering with their customers’ outbound connections without their knowledge, and crippling legitimate uses for P2P networks (the debate over whether P2P is “server-based” and against Cox’s TOS is for another day/thread). It’s even more ironic that Cox recently ran a TV commercial for HSI, and one of the reasons they suggest getting Cox HSI is to “fill up that new iPod you just got for Christmas.” In other words, Cox is promoting drug use, but preventing drug dealing – having their cake and eating it too.

I was hoping this post would stay a technical one and not a philosophical one, but if Cox is allowing downloads, they need to allow uploads too. There are no gray areas in piracy. Either you allow it or you don’t.

If your argument is that uploads harm the quality of the network, Cox should at least allow a percentage of upload traffic through (proportional to the 4Mbit down/512Kbit up ratio), and not block ALL upload traffic.

Lets be honest here. Cox is dropping P2P upload packets because of pressure from the RIAA, it has nothing to do with network health.

The sneaky part of it is that they’re doing it unannounced, “behind our backs” if you will. Cox clearly states on their tech support pages that they block port 25 and other ports. And THAT IS FINE, because you know what you’re getting when you sign up. But ask a Cox technician if they are blocking P2P and they either won’t answer or deny it, and I don’t see it listed anywhere on their websites. Why? Because NO ONE WOULD SUBSCRIBE TO COX IF PEOPLE KNEW THEY WERE BLOCKING P2P. Like porn, music/movie/software piracy is what drives Cox’s business model, and the Internet as a whole. Imagine what would happen to their subscriptions if Cox came out and announced that P2P was blocked. BYE BYE COX.

When someone buys a service or product, they need to know what they get in return for their money. Cox needs to come clean and either stop blocking P2P, or clearly state that they do so in their TOS and on their websites. This, no one can deny, is a fact.

UPDATE: Looks like there’s an online petition to tell Cox to knock it off. Sign Up Here.

I recently upgraded my MRTG install from v 2.10.13 to 2.11.1, and while the upgrade went fine, I ran into problems running mrtg:
[bash] /usr/local/mrtg-2/bin/mrtg /etc/mrtg/mrtg.cfg
gd-png: fatal libpng error: Invalid filter type specified
gd-png error: setjmp returns error condition
gd-png: fatal libpng error: Invalid filter type specified
gd-png error: setjmp returns error condition
gd-png: fatal libpng error: Invalid filter type specified
gd-png error: setjmp returns error condition
.....
I did a thorough Google search and never found a good answer or fix, except for a patch to the MRTG source code, which I didn’t find satisfactory. So it turns out that it was a problem with the PNG libraries. The machine was running an old Redhat 7.2, and libpng had previously been installed via RPM, with the libpng files from this RPM residing in /usr/lib. Prior to upgrading MRTG I had installed a newer libpng via source, with the new libpng files residing in /usr/local/lib. So the problem was that I had two different versions of libpng installed in different places on the machine, and this was causing the problems. This was easily fixed by creating symbolic links from the old RPM dir (/usr/lib) to the new manually installed dir (/usr/local/lib)
[bash] cd /usr/lib
[bash] mv libpng.a libpng.a.old
[bash] ln -s /usr/local/lib/libpng.a libpng.a
[bash] ln -s /usr/local/lib/libpng.so.3.1.2.8 libpng.so.3
[bash] ln -s /usr/local/lib/libpng.so.3 libpng.so
Once this library hell was fixed, MRTG went back to operating as expected.