If I turn the P2P service off, this number falls to a few dozen. This seems to clog up my network connection by times.
The Setup Addresses are made up for clarity: TFTP Server (S): 1.1.1.1 TFTP Client (C): 2.2.2. We've also found conflicting information on the web as to whether "dropping packet" means that a real IP packet was dropped by iptables, or merely that an ip_conntrack table entry was dropped to make room for a NEW packet.When I'm not downloading/uploading anything, I have over 2000 connections registered in my router going to port 6881 (torrent port) which register as unreplied. The result is the that the router NATs the connection from the client to the server, sets up a translation rule for the return connection and happily waits for a return packet from the server with source port69 that never arrives. I have a few other issues that Im still trying to figure out since. Im a sys admin but I dont know why ddwrt is really confusing for me and even more because Im french so it adds difficulty haha. We're trying to find out what is causing these UNREPLIED entries, but have so far been unsuccessful. The port unreplied on 127.0.0.1 to 127.0.0.1 is 6053 if I remember correctly, Im actually on a phone and I cant check. We looked at the rest of our Splunk servers, and found one other where the ip_conntrack table was nearly full, but most of the indexers' ip_conntrack tables were closer to 10% of capacity, most of which were UNREPLIED entries for dport=9997. These entries were the vast majority of the ip_conntrack table entries. Found a large number of "UNREPLIED" tcp entries in /proc/net/ip_conntrack which had long time to live (up to five days), and had dport=9997, so were destined for the indexer. Ip_conntrack: table full, dropping packetĪ bit of research led to the _conntrack_max setting, which we doubled to eliminate the messages while we investigated.
One of our Splunk servers recently had several messages appear in dmesg like this:
0 kommentar(er)
