The problem ended up being the cable [1]; nothing a little recrimping couldn't fix.
I did however, run LaBrea on the working port last night, and have a full twelve hours of data, from 00:00:00 (Eastern) to 11:59:59, and the results are rather amusing. 55,331 port connections on hold, from 1,743 unique IP (Internet Protocol) addresses. And the only surprising thing is the low number of scans for SMTP (Simple Mail Transfer Protocol).
Table: Ports captured during a Labrea run of twelve hours Port # Port description # connections ------------------------------ 135 Microsoft-RPC (Remote Procedure Call) service 30,218 445 Microsoft-DS (Directory Service?) Service 11,813 139 NetBIOS (Basic Input/Output System) Session Service 5,934 4899 Remote Administration [2] 2,412 80 Hypertext Transport Protocol 1,692 22 Secure Shell Login 1,190 6129 Dameware remote administration software [3] 486 1080 W32.Mydoom.F@mm worm [4] 404 2100 Oracle XDB FTP (File Transfer Protocol) Services 377 4444 W32.Blaster.Worm [5] 372 1433 Microsoft SQL (Standard Query Language) Server 258 15118 Dipnet/Oddbob Worm [6] 140 5000 Microsoft Universal Plug-n-Play 13 2745 Bagle/Beagle/Tanx viruses [7] 10 25 Simple Mail Transport Protocol 7 47707 unknown 5
And it seems, from these results, that simply blocking the ports used by Microsoft Windows will stop 87% of these scans (and for our particular run, if I just blocked 216.82.207.49 I would have stopped 35% of all the scans—that was a particularly persistent computer).
I may not have been properly tarpitting the connections [8].
[3] http://www.linklogger.com/TCP6129.htm
[4] http://securityresponse.symantec.com/avcenter/venc/data/w32.mydoom.f@mm.html
[5] http://securityresponse.symantec.com/avcenter/venc/data/detecting.traffic.due.to.rpc.worms.html
[6] http://www.lurhq.com/dipnet.html