I am disappoint

That's my "oh FUCK IT" face right there.

As you know it's been a Very Bad Year for the hardware that populates DinkNET.  Not a single box that was running in January 2011 is still running in December 2011.  The one, tiny little bright spot in all this carnage was the fact that all the replacement hardware, a motley collection of refurbs and loss leader deals, came with 10/100/1000 NICs, making me think I could easily upgrade from my old 100Mbps and get some 21st century performance out of all this crap.  So I bought a (cheap) Gigabit unmanaged switch and jacked all the hardware into it, expecting to be dazzled by the sheer speed of it all.

But reality threw me a "Not so fast, sucker" on that plan.

One box, although it was "new enough" to have a 10/100/1000 NIC inside did not, in fact have one.  I had anticipated this and had ordered four of the cheapest gigabit NICs I could find.  Five bucks each, unbranded, which turned out to be generically packaged RealTek 8169s (shown below).

I was fine with RealTek, although I learned later that the brand was somewhat universally disliked by Linux driver developers.  Check out this comment:

The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is probably the worst PCI ethernet controller ever made, with the possible exception of the FEAST chip made by SMC. The 8139 supports bus-master DMA, but it has a terrible interface that nullifies any performance gains that bus-master DMA usually offers.

Srsly?  All I ever used were RTL8129s & RTL8139s (in the 90s I used a variety of NE2000 clones but let's not go there... the memories are too painful... and don't get me started on 3com 3C905s!).

Anyway, it was a Good Thing that I bought four of them because I ended up disabling every built-in 10/100/1000 NIC on the network.  They were all Broadcom, using the Linux tg2 (Tigon 2) driver.  After that, three out of four boxes talked to each other at full gigabit speed.

The slowpoke is the BOT House box, which is still running Debian 4.0r0, as it has been for nearly four years now.  The Windows 7 box I bought earlier this year did not have a Broadcom chipset (it was RealTek - go figure) and doesn't have a problem running full speed on the network now.

Enter The Fifth Box, my old WinXP dog.  Recently brought back from the dead to work on PoTTY 0.62, I installed the last $5 RealTek NIC to bring it up to speed.  No luck.  This is typical of the results I'm getting:

I get maybe 30 seconds of "near gigabit" speed and it immediately drops to 100 megabit-ish territory, regardless of being set to autonegotiate or 1Gbps/full duplex.

Considering that particular box is going back to the boneyard, it's probably not a Big Deal, but I'm still Mighty Pissed and Quite Disillusioned by the entire experience.

TCP Port 36081

Happy Annual Gift Day!

I woke up bleary-eyed this morning at around 3AM, disappointing the cats who thought it was breakfast time, and sat down at the computer and pulled up the proxy list. I was greeted with a smattering of new proxies on port 36081.

This struck me as unusual so I did a quick check of the database to see how long it's been going on.

And it's only been going on for the last five days (see also SANS data on 36081), but let me qualify that. I have been finding live, High Anon, CERN-ish proxies on this port for the last five days. Not SOCKS!

I had a smattering of hits in 2008 and 2010 on port 36081, nothing at all in 2009, and seven between January 1st and December 1st of this year (2011).

328 of them—96%—in the last five days. 100% are located on residential IPs in the US, making them useless for me, since I don't do US proxies, and they're spread out in 44 states pretty much by population with the top three states being Texas, California, and Ohio.

What's special about 36081, the number? Nothing. It falls in an "UNASSIGNED" IANA port range, which in itself is meaningful and probably not random. It's not prime. It's the Zip code of Troy (as in "Trojan"), Alabama. It's the part number of a popular surge protector.

Oh, GOODIE!

Something new and wonderful is happening!

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.