Conntrack table problem

Discussion in 'Tomato Firmware' started by Kisch, Oct 3, 2015.

  1. Samuelheng

    Samuelheng Addicted to LI Member

    sorry to reconfirm one more time, to other R7000 users can reconfirm had this of problem on their router ? this not happen in my other router asus rt-n66u. i still miss my qos graphs gui if want to maintain correct count. the conntrack aways broken too many conntrack missing count when view some qos graphs gui in long time thk.
  2. Planiwa

    Planiwa Network Guru Member

    Both RT-N66U and RT-AC66U have this problem. Never enabled QOS. Did enable BW Limiter.
    No problem with RT-N16.
    Samuelheng likes this.
  3. theirongiant

    theirongiant Networkin' Nut Member

    Reviving an old thread...

    kckangaro, thank you VERY much for the suggestion to check /proc/slabinfo.

    I've been having this exact problem with my Asus RT-AC68P/U B1, which is running TomatoUSB Shibby 1.28 build 140 for ARMv7. QoS is enabled, and I have max connections set to 15,960.

    There is a major discrepancy on my router at the moment between nf_conntrack_count and the number of connections in ip_conntrack. The GUI also reports a fairly low connection count similar to ip_conntrack. I ran "netstat -np tcp" on several computers and came up with a total of ~400 connections. Far lower than the numbers reported.

    root@router:/proc/17671/net# cat /proc/sys/net/netfilter/nf_conntrack_count
    root@router:/proc/17671/net# cat /proc/slabinfo | grep conntrack
    nf_conntrack_c0433abc   3786   4720    248   16    1 : tunables    0    0    0 : slabdata    295    295      0
    root@router:/proc/17671/net# cat /proc/net/ip_conntrack | wc -l
    As you can see, 3764 is quite a bit more than 335. This is after just 36 hours of uptime. If I let this go for a few days more, it will hit 15960. At that point, the entire network is impacted. Some connections get through, some don't. Even ICMP starts to fail, and I would not be able to telnet into the router.

    One very quick solution is to restart the conntrack service. This breaks all open connections, but it takes less than two seconds and is a lot less disruptive than a full reboot:

    service ctnf restart
    In my case, I have about 15 active devices on the network, a mixture of wired and Wi-Fi. There is one computer running torrents (a Mac with "Transmission"), and QoS is enabled on the router. Among many of the rules, I have one that says "Src IP = (torrent box) and Src Port = (torrent port) shall be classified as Bulk." This is to ensure that other services like HTTPS, or the CrashPlan backup client (dst ports: 4282, 4287 + Dst IP get priority on the network, but torrents would get full speed when the network is not busy, such as times when we are asleep or away from home. This has worked very, very well for a long time.

    My transmission client has a max connection limit set to 2048. Additionally, these options are enabled by default in Transmission:
    • Use peer exchange (PEX) for public torrents
    • Use distributed hash table (DHT) for public torrents
    • Use local peer discovery for public torrents

    According to the BitTorrent protocol, DHT sends out UDP connections. See "KRPC protocol" in this article:

    If I quit Transmission on the Mac, the number reported by "nf_conntrack_count" does not decrease significantly. If I restart Transmission, the connection count goes up even more.

    I'll put my money on "memory leak."
    Last edited: Mar 5, 2018
    Samuelheng likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice