openssl /usr/bin/ld: Warning: size of symbol `CAST_cbc_encrypt’ changed

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!

Cox HSI Dropping P2P/Gnutella/WinMX Upload Traffic

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

Sample conversation:
Upload to X.X.X.X:6346 ("BearShare Lite") Processing request
GET /uri-res/N2R?urn:sha1:123412341234123412341234 HTTP/1.1\r\n
Host: \r\n
User-Agent: BearShare Lite\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
X-Features: queue/0.1\r\n
X-Node: X.X.X.X:6346\r\n
HTTP/1.1 401 Authorizing\r\n
Server: BearShare 4.7.0b38\r\n
Content-Length: 0\r\n
FP-1b: \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)

19:56:00.598539 IP > LOCAL.PORT: S 910058714:910058714(0) win 65535
19:56:00.598624 IP LOCAL.PORT > S 591457694:591457694(0) ack 910058715 win 65535
19:56:00.714254 IP > LOCAL.PORT: . ack 1 win 65535
19:56:00.725367 IP > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:56:00.731713 IP > LOCAL.PORT: R 910058965:910058965(0) win 10240
19:56:00.732075 IP > LOCAL.PORT: R 910071468:910071468(0) win 10240
19:56:00.736472 IP > LOCAL.PORT: R 910058971:910058971(0) win 10240
19:56:00.736840 IP > LOCAL.PORT: R 910071474:910071474(0) win 10240

19:57:01.850407 IP > LOCAL.PORT: S 2222769745:2222769745(0) win 65535
19:57:01.850485 IP LOCAL.PORT > S 2025320299:2025320299(0) ack 2222769746 win 65535
19:57:01.982241 IP > LOCAL.PORT: . ack 1 win 65535
19:57:01.993511 IP > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:57:01.999252 IP > LOCAL.PORT: R 2222769996:2222769996(0) win 10240
19:57:01.999618 IP > LOCAL.PORT: R 2222782499:2222782499(0) win 10240
19:57:02.003452 IP > LOCAL.PORT: R 2222770002:2222770002(0) win 10240
19:57:02.003816 IP > LOCAL.PORT: R 2222782505:2222782505(0) win 10240

EQUIVALENT BS LOGS (one for each attempt):
Upload from ("LimeWire/4.0.8") Processing request
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
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
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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 192.168.X.X.MYPORT: R 790145009:790145009(0) win 10240Upload from ("BearShare") Processing request
User-Agent: BearShare\r\n
Range: bytes=3932160-4194303\r\n
X-Gnutella-Content-URN: urn:sha1:PZWSAFKCQSRZ32CZSKXBUH4VCMMH7M2K\r\n
X-Connection-Type: Broadband\r\n
FP-1a: \r\n
Content-Disposition: inline; filename="somefile.mp3"\r\n
X-Features: browse/1.0, queue/0.1\r\n
X-Queue: 0.1\r\n
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

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.

Disneyland = 666 = Evil?

I am a Disneyland freak. I’m such an afficionado, I want to be burried there. I love cruising around the park and noticing all the little details. However, the greatest detail I’ve ever found is a dark one… an EVIL one. Take a look at this photo, taken from the parking structure down to the road below. Notice anything a bit … ummm… SATANIC?

Disneyland = 666 = Satan

The happiest place on earth? More like the EVILIST place on earth! Wait, is “evilist” even a word? 🙂

MRTG Error: gd-png: fatal libpng error: Invalid filter type specified

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/
[bash] ln -s /usr/local/lib/

Once this library hell was fixed, MRTG went back to operating as expected.