The tracker itself is running on multiple ports, and all works fine. (..) attacking a tracker port 3434
Is this related to your thread
Port redirecting? I mean, are you still running two trackers or did you get "REDIRECT --to-port 6969" going? if you did, could you post your firewall script?
As soon as I start the tracker on 3434, it once again consumes the full 15Mbps and causes timeouts etc.
Did you have any logged problems with iptables? Would it be possible to try this again and you logging the socketstates for the connections?
The firewall has been modified so that the incoming connections are not tracked by contrack /at least I think this is the case)
Why would you want to turn iptables into an stateless firewall?
What I need to do is identify the problematic packets or IP's and block them from the server.
Yes, cuz I saw some stupid remarks about "Mongo being under investigation for having bad torrents stuck at 99%". I ran your pcaps through Snort and inspected them with Ethereal. Nothing out of the ordinary to report except some packet data wasn't captured in full. Anyway. Here's your top-10 problematic subnets + count from pcaps:
128.108.111 247
128.108.113 130
64.62.170 99
128.108.211 98
128.108.112 80
128.108.114 60
204.11.219 14
38.113.239 12
The majority of which are on the Cogentco.com /Peak Web Hosting route in
ASN33529 , which doesn't seem to have
these ranges listed, which is weird.
Do clients from these ranges connect to the other tracker port?:
128.108.111 - 128.108.114, 128.108.211,
204.11.216, 204.11.217, 204.11.219, 204.11.223,
38.113.239, 38.113.245,
64.62.170, 64.62.179 .
Do you have some way to match Bittorrent client User_AGENT strings to IP addresses?
You don't have P0f running by any chance, right?