Conntrack table problem

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

  1. Kisch

    Kisch LI Guru Member

    I have Netgear R7000 with Shibby´s 1.28.0000 -131 K26ARM USB VPN-64K. Today my internet connection became strangely slow, problem was with new connections. In log I discovered this messages:

    kern.warn kernel: nf_conntrack: table full, dropping packet

    But, I have maximum connections se to 16384 and total connections count was below 500. I set max. connections to 32768 and problem was gone. But I feel, this is not correct solution. Did anyone encounter this behaviour?
     
    Last edited: Oct 4, 2015
  2. Planiwa

    Planiwa Network Guru Member

    I suppose that kind of thinking is what prompted Asus to advertise "300,000 Sessions, Stable Download" for the RT-N16.

    It seems to go like this:

    I have observed 500 connections.
    The message says I exceeded 16000 connections.
    I don't think so, but I guess I better double my connection limit.

    What is a correct solution? That depends on who is asking.

    Some users say: I just want a quick fix. I don't want to understand or learn anything. Tell me an easy thing to do.

    Other users say: Why does the computer say I exceeded 16,000 connections, when I only saw 500?
    What is going on here? How can I act responsibly?

    Some sys admins say: How can I prevent some reckless users from making the whole network unusable?

    My advice to users who want to understand and act responsibly is to ask:

    How many connections do I need?
    How do connections change over time?
    How can I limit the connections I use, in the configuration of the programs I use?
    What are NAT Connection Storms?

    For sysadmins, consider:

    1. BW Limiter -- severely limit connections as well as connection (attempt) rate per second.
    2. Conntrack timeouts: drastically reduce futile connection attempts.
    3. If you really want to see what's going on, monitor Conntrack Table Count every 3 seconds.
    -- If you only monitor every minute you may miss the Connection Storms.
    -- If you need to know how, feel free to ask me. You could try something like:
    Code:
    N=1;while sleep 3; do case $N in 1|*001)echo;date +%y%m%d_%H%M;N=1;;*[02468]1)echo;;esac;echo -n "$(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count) ";N=$((N+1));done
    
     
    Last edited: Oct 5, 2015
  3. Kisch

    Kisch LI Guru Member

    Thx very much for answer. I got quite different numbers:

    in Netgear R7000 GUI: 192 connections currently tracked

    same time: cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count: 20137

    What is happening?
     
  4. Planiwa

    Planiwa Network Guru Member

    Why not run the program I gave for an hour and post the results?
     
  5. Kisch

    Kisch LI Guru Member

    Result of 45 min running:
    151005_1952
    20361 20361 20366 20358 20335 20339 20344 20343 20336 20311 20314 20319 20318 20319 20312 20309 20307 20312 20310 20318
    20328 20331 20331 20346 20348 20351 20350 20342 20333 20323 20326 20322 20314 20315 20316 20309 20310 20310 20308 20298
    20294 20297 20296 20297 20300 20297 20298 20298 20295 20280 20280 20273 20272 20268 20269 20267 20266 20267 20280 20286
    20289 20292 20293 20278 20285 20284 20276 20263 20263 20254 20251 20251 20258 20256 20255 20256 20253 20255 20254 20257
    20256 20249 20246 20243 20242 20246 20242 20241 20239 20240 20256 20261 20261 20258 20261 20262 20264 20261 20245 20218
    20210 20209 20209 20206 20201 20201 20202 20215 20211 20213 20208 20199 20200 20203 20205 20201 20195 20183 20178 20168
    20167 20170 20166 20165 20167 20165 20170 20172 20175 20170 20168 20175 20180 20176 20177 20172 20178 20184 20183 20180
    20179 20169 20176 20175 20177 20181 20178 20179 20173 20178 20174 20169 20164 20160 20154 20152 20153 20147 20146 20150
    20149 20148 20150 20150 20152 20153 20158 20155 20154 20157 20160 20157 20153 20157 20156 20149 20152 20151 20147 20144
    20142 20143 20139 20140 20138 20141 20141 20143 20144 20139 20138 20142 20140 20143 20144 20140 20137 20133 20131 20129
    20127 20130 20129 20128 20127 20127 20129 20135 20133 20137 20136 20136 20130 20132 20133 20141 20140 20144 20142 20137
    20140 20144 20141 20139 20142 20141 20140 20137 20138 20136 20129 20130 20134 20140 20139 20141 20142 20144 20146 20152
    20149 20151 20149 20149 20147 20151 20152 20151 20147 20150 20154 20151 20148 20147 20142 20142 20139 20144 20147 20141
    20138 20140 20145 20142 20138 20143 20140 20142 20147 20151 20141 20138 20137 20137 20138 20137 20134 20134 20134 20132
    20131 20135 20142 20145 20146 20148 20151 20148 20154 20154 20151 20148 20141 20142 20142 20142 20143 20138 20139 20135
    20133 20135 20135 20140 20140 20139 20136 20129 20133 20137 20150 20150 20152 20152 20154 20151 20150 20144 20145 20135
    20134 20136 20137 20130 20128 20130 20131 20130 20129 20136 20139 20133 20137 20135 20136 20134 20133 20132 20131 20132
    20129 20125 20127 20126 20129 20129 20127 20125 20127 20127 20123 20122 20120 20120 20121 20121 20122 20116 20115 20117
    20114 20114 20109 20110 20109 20115 20113 20113 20109 20112 20112 20110 20110 20110 20105 20107 20103 20105 20106 20104
    20103 20102 20106 20104 20104 20101 20100 20098 20102 20102 20101 20101 20099 20101 20101 20099 20097 20097 20102 20108
    20111 20114 20115 20116 20116 20119 20121 20122 20121 20118 20112 20110 20113 20111 20107 20105 20107 20102 20101 20097
    20099 20098 20101 20110 20111 20111 20109 20109 20109 20111 20117 20116 20119 20119 20122 20122 20125 20125 20124 20122
    20122 20119 20116 20112 20112 20111 20106 20104 20105 20105 20100 20102 20105 20105 20105 20112 20110 20114 20116 20121
    20121 20121 20121 20125 20125 20120 20113 20110 20111 20109 20117 20119 20118 20118 20119 20124 20124 20125 20125 20124
    20122 20127 20128 20126 20124 20127 20128 20124 20124 20134 20133 20130 20132 20130 20126 20125 20126 20122 20117 20118
    20118 20121 20117 20122 20126 20126 20125 20127 20126 20120 20121 20123 20120 20116 20121 20121 20120 20119 20123 20128
    20132 20131 20127 20127 20132 20133 20133 20135 20139 20133 20134 20137 20140 20139 20141 20135 20140 20148 20145 20143
    20139 20138 20135 20142 20141 20143 20142 20142 20144 20149 20150 20151 20155 20158 20161 20159 20158 20151 20150 20149
    20149 20147 20139 20131 20134 20133 20132 20132 20133 20128 20126 20131 20130 20128 20123 20124 20127 20133 20136 20133
    20129 20131 20129 20133 20133 20134 20134 20133 20137 20137 20141 20141 20139 20141 20136 20132 20128 20126 20123 20122
    20126 20120 20119 20114 20120 20123 20126 20128 20131 20137 20138 20139 20141 20140 20134 20133 20153 20158 20157 20150
    20152 20151 20144 20144 20147 20141 20127 20138 20135 20136 20134 20134 20132 20129 20132 20135 20124 20123 20122 20123
    20124 20131 20131 20131 20131 20136 20141 20139 20133 20133 20141 20141 20143 20142 20139 20137 20138 20135 20143 20136
    20134 20131 20134 20142 20145 20140 20139 20133 20136 20136 20134 20131 20123 20124 20123 20130 20138 20142 20145 20147
    20149 20157 20153 20156 20153 20148 20144 20141 20137 20140 20136 20132 20137 20137 20140 20142 20143 20144 20143 20143
    20148 20145 20150 20153 20149 20146 20147 20147 20147 20151 20146 20143 20143 20142 20148 20148 20137 20140 20137 20138
    20140 20139 20136 20135 20135 20137 20130 20135 20141 20145 20141 20144 20144 20142 20138 20138 20137 20129 20128 20132
    20129 20128 20132 20132 20130 20131 20136 20142 20139 20140 20134 20134 20138 20141 20139 20139 20133 20126 20129 20131
    20134 20130 20124 20128 20126 20130 20127 20130 20120 20122 20121 20123 20129 20133 20130 20126 20128 20126 20134 20134
    20129 20130 20136 20134 20135 20132 20141 20138 20137 20132 20132 20122 20122 20122 20121 20116 20112 20112 20115 20113
    20110 20105 20107 20110 20113 20112 20112 20112 20110 20108 20106 20102 20106 20105 20110 20106 20104 20101 20101 20100
    20104 20096 20100 20095 20096 20096 20097 20095 20095 20095 20097 20095 20093 20097 20094 20094 20097 20095 20093 20096
    20100 20100 20105 20102 20105 20100 20103 20103 20104 20107 20105 20111 20113 20114 20114 20117 20120 20122 20125 20125
    20117 20117 20118 20119 20116 20117 20118 20118 20117 20114 20115 20115 20114 20115 20114 20120 20119 20119 20120 20118
    20118 20116 20120 20118 20114 20113 20112 20111 20111 20110 20111 20114 20115 20120 20126 20126 20122 20123 20124 20125
    20122 20123 20123 20119 20115 20117 20122 20128 20129 20127 20126 20125 20127 20133 20135 20138 20135 20142 20139 20136
    20135 20140 20140 20141 20143 20152 20190 20200 20204 20207 20203 20211 20215 20216 20218 20211 20196 20208 20231 20233
    20230 20230 20236 20232 20228 20228 20225 20210 20205 20208 20211 20221 20222 20223 20219 20218
     
  6. Planiwa

    Planiwa Network Guru Member

    Thanks!
    This is not what I expected.
    Just to be sure, can you please do:

    Code:
    echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    echo
    awk '
    {T["TOTAL"]++}
    $1=="tcp" {T[$1 " " $4]++ ; next}
    /udp.*UNREPLIED/ {T[$1 " UNREPLIED"]++; next}
    /udp.*ASSURED/   {T[$1 " ASSURED"]++; next}
    /udp/ {T[$1 " limbo"]++; next}
    {T[$1 " ?"]++}
    END {for (i in T) printf("%6s %s\n", T[i], i)}
    ' /proc/net/ip_conntrack |sort -nr
    echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    echo $(cat /proc/net/ip_conntrack |wc -l) lines counted
    
     
    Last edited: Oct 6, 2015
  7. kckangaro

    kckangaro Network Newbie Member

    Do you have large amount of connections in ESTABLISHED state?
    $ grep -c ESTABLISHED /proc/net/ip_conntrack

    If so, you might have packet loss problem where FIN packets weren't received correctly and connection stays in the hash table. There is a TCP timeout for established connection, but the default is 432000 (5 days).
     
  8. Planiwa

    Planiwa Network Guru Member

    Really?
    Code:
    # cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
    1200
    # 
    [code]
     
    Techie007 likes this.
  9. Kisch

    Kisch LI Guru Member

    Planiwa

    Tried it, this is result:

    root@Netgear-R7000:/tmp/home/root# echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    Conntrack Count: 20026
    root@Netgear-R7000:/tmp/home/root# echo

    root@Netgear-R7000:/tmp/home/root# awk '
    > {T["TOTAL"]++}
    > $1=="tcp" {T[$1 " " $4]++ ; next}
    > /udp.*UNREPLIED/ {T[$1 " UNREPLIED"]++; next}
    > /udp.*ASSURED/ {T[$1 " ASSURED"]++; next}
    > /udp/ {T[$1 " Total"]++; next}
    > {T[$1 " ?"]++}
    > END {for (i in T) printf("%6s %s\n", T, i)}
    > ' /proc/net/ip_conntrack |sort -nr
    echo $(cat /proc/net/ip_conntrack |wc -l) lines counted 59 TOTAL
    48 tcp ESTABLISHED
    7 udp ASSURED
    2 udp UNREPLIED
    1 unknown ?
    1 tcp TIME_WAIT
    root@Netgear-R7000:/tmp/home/root# echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    Conntrack Count: 20026
    root@Netgear-R7000:/tmp/home/root# echo $(cat /proc/net/ip_conntrack |wc -l) lines counted
    63 lines counted

    Did I do it right?
     
  10. BikeHelmet

    BikeHelmet Addicted to LI Member

    On my RT-N66U running some form of v0506

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    386

    Quite sure that someone is torrenting, too. This is a MIPS router, possibly running older firmware than yourselves? The good news is, as a fellow 256MB router owner, you can brute force a solution if the answer proves elusive.

    Good luck. Watching this thread since I'm quite curious about what the answer proves to be.

    -BikeHelmet
     
  11. pegasus123

    pegasus123 Addicted to LI Member

    hmm, that cant be right both of these should be the same

    Code:
    root@unknown:/proc/sys# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    120
    root@unknown:/proc/sys# cat /proc/net/ip_conntrack | wc -l
    120
     
  12. Kisch

    Kisch LI Guru Member

    pegasus123

    root@Netgear-R7000:/tmp/home/root# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    20046
    root@Netgear-R7000:/tmp/home/root# cat /proc/net/ip_conntrack | wc -l
    55
     
  13. pegasus123

    pegasus123 Addicted to LI Member

    Not sure if these is a bug on arm builds. Let's wait for someone to look it up.
     
  14. Planiwa

    Planiwa Network Guru Member

    Thanks for running this. At first I thought it was a connection storm, but the first script showed that something peculiar was going on. That's why I offered the second script, which provides information similar to Advanced : Conntrack/Netfilter.

    The results show that

    /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    and probably
    /proc/sys/net/netfilter/nf_conntrack_count

    are corrupted.
     
  15. Kisch

    Kisch LI Guru Member

    Ok, thank you very much Planiwa and others for help. I rebooted router and now result is:

    root@Netgear-R7000:/tmp/home/root# awk '
    > {T["TOTAL"]++}
    > $1=="tcp" {T[$1 " " $4]++ ; next}
    > /udp.*UNREPLIED/ {T[$1 " UNREPLIED"]++; next}
    > /udp.*ASSURED/ {T[$1 " ASSURED"]++; next}
    > /udp/ {T[$1 " Total"]++; next}
    > {T[$1 " ?"]++}
    > END {for (i in T) printf("%6s %s\n", T, i)}
    > ' /proc/net/ip_conntrack |sort -nr
    49 TOTAL
    31 tcp TIME_WAIT
    11 udp ASSURED
    3 tcp CLOSE
    2 udp UNREPLIED
    1 unknown ?
    1 tcp ESTABLISHED
    root@Netgear-R7000:/tmp/home/root# echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    Conntrack Count: 49
    root@Netgear-R7000:/tmp/home/root# echo $(cat /proc/net/ip_conntrack |wc -l) lines counted
    49 lines counted

    It seems ok now. Router was only 11 days online. Thx again.
     
  16. pegasus123

    pegasus123 Addicted to LI Member

    Good. Set max connection lower you don't need to set it up too high
     
  17. Kisch

    Kisch LI Guru Member

    Yep. Going back to default.
     
  18. Planiwa

    Planiwa Network Guru Member

    Yes. A lower limit means that you become aware of problems sooner and can address them. Unless you _need_ many connections because of connection-hungry applications, 1000 should be quite sufficient.

    If you do need many connections for P2P applications, it is best to ask yourself how many connections you actually need, and then to limit connections (and connection attempts) and connection rates, preferably in the application configuration.

    Some applications can be quite reckless with resources, and your router could be doing useful work, rather than madly trying to set up thousands of connections that never go anywhere or do anything.
     
  19. BikeHelmet

    BikeHelmet Addicted to LI Member

    In my opinion, it's cheaper to differ dealing with such things to a router than to handle it myself. I eat food, after all. Anything that takes time costs food. Since I won't be fixing the firmware, my fixes would just be temporary ones like rebooting. (Which is a disruption itself.) If the router can avoid the problem just by having a larger hash table, then that's clearly the headache-free answer. Anything other than fixing the source of the corruption (The firmware?) or bumping up the hash table size will leave it open to recurrence.

    I suspect that 1000 connections could easily be hit. I'd say if you have the RAM, make that hash table enormous. Hash tables are fast, except when they are full and have numerous hash collisions, so if yours is too small you'll take a massive performance hit. RAM is close to free when you've got 256MB of it... might as well use some of it to avoid glitches, even if the glitches are technically elsewhere. That's proper usage of resources to mitigate issues. Pay your router $0.50 extra in CPU/electricity per year to handle it, rather than spending your time on it. If you must, then do a proper fix by tackling the firmware. Don't just patch/duct-tape it with reboots when it goes wonky. ;)

    If you must know when it's glitching out, get your router to log the results from that command periodically - but do also have the hash table large enough to avoid disruptions for your users.

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

    -BikeHelmet
     
  20. Kisch

    Kisch LI Guru Member

    So, I tried to run Planiwa´s script tonight:

    root@Netgear-R7000:/tmp/home/root# awk '
    > {T["TOTAL"]++}
    > $1=="tcp" {T[$1 " " $4]++ ; next}
    > /udp.*UNREPLIED/ {T[$1 " UNREPLIED"]++; next}
    > /udp.*ASSURED/ {T[$1 " ASSURED"]++; next}
    > /udp/ {T[$1 " limbo"]++; next}
    > {T[$1 " ?"]++}
    > END {for (i in T) printf("%6s %s\n", T, i)}
    > ' /proc/net/ip_conntrack |sort -nr
    echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    echo $(cat /proc/net/ip_conntrack |wc -l) lines counted 261 TOTAL
    212 udp ASSURED
    19 udp limbo
    13 tcp ESTABLISHED
    8 tcp TIME_WAIT
    3 udp UNREPLIED
    3 tcp SYN_SENT
    2 tcp SYN_RECV
    1 unknown ?
    root@Netgear-R7000:/tmp/home/root# echo Conntrack Count: $(cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count)
    Conntrack Count: 375
    root@Netgear-R7000:/tmp/home/root# echo $(cat /proc/net/ip_conntrack |wc -l) lines counted
    251 lines counted

    Seems problem is not gone.
     
  21. Planiwa

    Planiwa Network Guru Member

    Indeed. This information may be helpful, as it seems that the problem is pervasive, and therefore easier to see and track down.

    BTW, Kish, If you paste the script into System : Tools, or of you create a file (e.g. ct), make it executable (chmod +x ct), and then just run it, you will get clean output, similar to the edited report above.

    If you do run P2P apps that use lots and lots of connections, you may start up the first script before starting the app, and observe the dynamics of the # of connections. The results may astonish you. (Of course the bug complicates matters.)

    Perhaps I'll make you a script to run in Scheduler to sound an alarm when conntrack_count starts getting seriously wrong.
     
  22. Kisch

    Kisch LI Guru Member

    Planiwa, thx, clean output is now:

    Conntrack Count: 350

    236 TOTAL
    148 udp ASSURED
    24 tcp TIME_WAIT
    22 tcp ESTABLISHED
    17 udp limbo
    17 tcp CLOSE
    5 udp UNREPLIED
    2 tcp SYN_SENT
    1 unknown ?
    Conntrack Count: 350
    236 lines counted

    I will watch it, maybe I will set auto reboot once a week. I used scheduled reboot on Asus RT-N66 and RT-N16 before. And will wait for new tomato release. But I just wanted to test stability. But some sort of "alarm script" would be nice, if you would be so kind. And sorry for my English, not my born language.
     
  23. Planiwa

    Planiwa Network Guru Member

    I would schedule this every hour:
    Code:
    CCC="cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count"
    CTF="/proc/net/ip_conntrack"
    set -- $($CCC) $(wc -l < $CTF) $($CCC)
    D1=$(($2-$1))
    D2=$(($3-$2))
    case "$D1$D2" in
    -*-*) ;; # fall
    *-*)  if [ $D1 -gt 10 ] && [ $D2 -lt -10 ]
          then ALERT="Connection PEAK"
          fi
          ;; # peak
    -*)   if [ $D1 -lt -10 ] && [ $D2 -gt 10 ]
          then ALERT="Connection ALARM #####"
          fi
          ;; # nadir
    *)    ;; # rise
    esac
    logger -t Monitor "Conntrack Count: $1 $2 $3 $D1 $D2 $ALERT"
    
     
    Last edited: Oct 7, 2015
  24. BikeHelmet

    BikeHelmet Addicted to LI Member

    I have new information:

    They don't match for mine either! That said, my uptime is quite high, and I have auto-reboots turned off. (Except for QOS and DDNS; they restart daily, as instructed to in the scheduler section.) I did a restart on both just now via PUTTY, but the totals are still slightly off.


    Just tossing it out there, but could it be something silly like one reporting WAN connections only and the other br0 connections?

    -BikeHelmet
     
  25. Planiwa

    Planiwa Network Guru Member

    It is useful to know that this problem also affects Asus routers.

    These are NAT connections, or, especially during a potentially catastrophic "(NAT) Connection Storm", NAT connection _attempts_. conntrack_count was provided in Tomato to make it easier to monitor connection storms, without having to read the conntrack table (twice!). Yes, that was a third contribution of mine: the discovery that wc, grep and other commands, with /proc pseudo-files as command line arguments, would give grossly wrong results. The correct way was to use cat first and pipe that into the command.

    I wonder if there are (m)any here who remember all that. :)
     
  26. pegasus123

    pegasus123 Addicted to LI Member

    I have Asus rtn12 old router. I'll check it in the couple of days :p
    Mine is running 24x7 as well and have like 15 clients active at anyone time.

    I also wonder whether setting timeouts low will help. I'm in toastman build and I like the way timeouts set to low by default, I'm hardly hitting 800 connections. So my maximum 2048 is never even nearly reached.
     
  27. Planiwa

    Planiwa Network Guru Member

    I definitely advocate small timeouts to limit the damage from reckless P2P applications.
    (Perhaps I should mention that Advanced : Conntrack/Netfilter counts UDP "connections"
    confusingly. "Unreplied" is Unreplied + what I have called limbo -- without a state designation.)

    Also, I do not give priority to small packets that may be part of the recklessness.
    Many applications default to irresponsible settings, such as unlimited connections.

    Or video streamers that default to "best"quality HD.

    And most users are unaware of the settings, their implications, and the resources they consume.
    I have found that if I ask people to be responsible, many will ignore it or resent it. Perhaps partly
    because they don't understand the concepts and don't want to learn. I used to register every
    device and give it an IP address tied to its owner. Nowadays I simply limit the most excessive
    devices. I don't need to know who owns them, and the owners don't seem to notice.

    I use BWM, IP-Traffic, Static IP, and BW Limiter.
     
    Last edited: Oct 7, 2015
  28. pegasus123

    pegasus123 Addicted to LI Member

    Planiwa That's exactly what I'm doing :) except I tied every device to an Ip address and names, so I know who is connected.
     
    Last edited: Oct 7, 2015
  29. kckangaro

    kckangaro Network Newbie Member

  30. kckangaro

    kckangaro Network Newbie Member

    It's easy to see if there is a true memory leak or just a counter leak. Please run the following:

    Code:
    cat /proc/slabinfo | grep nf_conntrack
    Every nf_conntract has a corresponding kmem_cache object. If kernel slab info also show high value in allocated nf_conntrack objects, then it is likely there is a genuine leak in conntrack. Otherwise, it is just a counter leak.
     
  31. Kisch

    Kisch LI Guru Member

    Result:

    nf_conntrack_c0423a7c 166 448 248 16 1 : tunables 0 0 0 : slabdata 28 28 0

    I have 200/20 mbps line and I have mostly only 2 users (me and my wife), sometimes daughter and rarely phones of my friends. So I dont need control traffic. But I use QoS, because of FTP server (Synology DS214) for my friends. I use reserved DHCP for my home devices and some free IPs for visitors (on guest wifi).

    Planiwa

    Thank you very much for script. I really appreciate your effort.
     
  32. Planiwa

    Planiwa Network Guru Member

    I've updated the Scheduler script to be smarter at catching Conntrack Count discrepancies.
     
  33. BikeHelmet

    BikeHelmet Addicted to LI Member

    Does this mean anything to you?

    -BikeHelmet
     
  34. pegasus123

    pegasus123 Addicted to LI Member

    Planiwa i think you mentioned you are not prioritizing small packets, im just wondering where all this small packets will go to if you do not prioritized them, is it the default class?

    im using the default, prioritized icmp, fin, syn, rst. The ack is unchecked.
     
  35. BikeHelmet

    BikeHelmet Addicted to LI Member

    I prioritize ICMP, because strangely enough certain things depend upon it being somewhat accurate. Have the rest unticked. Can't remember what I used to do on 3mbit. Now it doesn't matter thanks to having a much faster connection. I just use QOS to stop bulk downloads/torrents from choking my VOIP, gaming, and other important things.

    -BikeHelmet
     
  36. Planiwa

    Planiwa Network Guru Member

    Let's start with ICMP. It may seem sensible to give it highest priority. But is it really sensible?
    Do I want the shortest ping times possible, because pings are privileged?
    Or do I want to get a realistic picture of the latency that real traffic can expect?

    You may have learned in the news how VW programmers gave "priority" to emissions tests.
    Well, that's in essence what happens when you give priority to ICMP:
    The test results end up being falsified, and look much better than reality!

    Next, let's look at malware.
    I regard most P2P as reckless malware.
    I think Toastman agrees.

    Look at the results that BikeHelmet posted. Notice the Syn_Sent's?
    Why are there so many? Are they actual "connections"? Or just nuisances?
    These are not good things. You want to terrorize them, not encourage them.

    In an honest network, yes, you want treat signals preferentially.
    But when malware abuses signals to sabotage your network, the last thing you want to do is give priority to the saboteurs.

    You ask what class. These thingies tend to be classless. Unclassified. :)

    But I don't use QOS.

    QOS is good for a mutually respectful, cooperative group such as a family or a company. But with independent students, essentially competing for the same limited resources, fairness is more important than optimized traffic throughput.

    What's more "important" -- a HD Skype call with parents, a Netflix video, a software update? I practice net neutrality. Devices that us excessive resources get restricted.

    There are other perspectives, of course. :)
     
    Toastman and BikeHelmet like this.
  37. pegasus123

    pegasus123 Addicted to LI Member

    Thanks BikeHelmet and Planiwa for your insight, ill experiment with it :)
     
  38. Kisch

    Kisch LI Guru Member

    Thx, I´m using it. Difference is below 200 till now, but rising slowly. I set scheduled reboot at Mondays 4:00 a.m.
     
  39. kckangaro

    kckangaro Network Newbie Member

    The format for the most important fields are:
    name, in-use-objects, total-alloc-objs, size-of-object, ...

    At the time of the data collection, 166 kernel conntract objects were in use. They seems totally reasonable. Although the difference between ip_conntrack_count and ip_conntrack dump were also small. So it's inconclusive.

    Before your scheduled reboot, please grab stats from Planiwa's script and the kernel slabinfo (cat /proc/slabinfo | grep nf_conntrack).
     
  40. Planiwa

    Planiwa Network Guru Member

    It's better to use:
    Code:
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    egrep '^#|conn' /proc/slabinfo
    
    Some results:

    Thu Oct 8 11:08:33 EDT 2015
    Asus RT-N16
    63
    63
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : slabdata 0 0 0
    nf_conntrack_expect 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : slabdata 0 0 0

    Thu Oct 8 11:08:38 EDT 2015
    Asus RT-AC66U
    78
    78
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : slabdata 0 0 0
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : slabdata 0 0 0
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : slabdata 0 0 0

    Thu Oct 8 11:08:45 EDT 2015
    Asus RT-AC66U
    65
    73
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : slabdata 0 0 0
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : slabdata 0 0 0
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : slabdata 0 0 0

    As you can see, on those routers, slabinfo is of no use at all.

    HOWEVER -- the discrepancy (8) is there on the AC66U now.
     
    Last edited: Oct 30, 2015
  41. Planiwa

    Planiwa Network Guru Member

    Another little bug:

    The 2nd of the 3 routers above is an N66U, not AC66U:

    Thu Oct 8 11:35:51 EDT 2015
    + nvram find model_name
    t_fix1=RT-AC66U
    t_model_name=Asus RT-AC66U
    + dmesg
    + grep ^Build
    Build_for__asus_n66u_2011-10-27_U86_r187446_b122
    + set +x
    85
    85
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : slabdata 0 0 0
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : slabdata 0 0 0
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : slabdata 0 0 0
     
  42. Planiwa

    Planiwa Network Guru Member

    Sigh. Looks like the N66U and AC66U are both called AC66U in NVRAM.
    And in dmesg, they are both called n66u.
    I have found no way to distinguish the two, in Shibby Tomato 131.
    (Are others getting these same results?)

    Here is the real AC66U:

    Thu Oct 8 12:26:01 EDT 2015
    + nvram find model_name
    t_model_name=Asus RT-AC66U
    + dmesg
    + grep ^Build
    Build_for__asus_n66u_2011-10-27_U86_r187446_b122
    + set +x
    103
    111
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : sla
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : s
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : sl
     
    Last edited: Oct 9, 2015
  43. kckangaro

    kckangaro Network Newbie Member

    What is this firmware? dd-wrt? It doesn't look like it comes from shibby 131 build.
     
  44. Planiwa

    Planiwa Network Guru Member

    Code:
    date
    nvram get os_version
    dmesg|grep '^Build'
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    egrep '^#|conn' /proc/slabinfo|awk '{print substr($0,1,80)}'
    
    Thu Oct 8 21:19:03 EDT 2015
    1.28.0000 MIPSR2-131 K26AC USB AIO-64K
    Build_for__asus_n66u_2011-10-27_U86_r187446_b122
    73
    73
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : sla
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : s
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : sl
     
  45. Monk E. Boy

    Monk E. Boy Network Guru Member

    Perhaps you're running an AC66 firmware on your N66?

    # nvram find model_name
    t_model_name=Asus RT-N66U
     
  46. Planiwa

    Planiwa Network Guru Member

    Hm. Thanks!

    N66U:
    Thu Oct 8 21:38:15 EDT 2015
    1.28.0000 MIPSR2-131 K26AC USB AIO-64K
    Build_for__asus_n66u_2011-10-27_U86_r187446_b122

    AC66U:
    Thu Oct 8 21:38:56 EDT 2015
    1.28.0000 MIPSR2-131 K26AC USB AIO-64K
    Build_for__asus_n66u_2011-10-27_U86_r187446_b122

    dmesg says n66u for both.


    Shibby's website, http://tomato.groov.pl/?page_id=164

    seems to say uses the same firmware:
    • K26RT-AC – MIPSR2 – SDK6.x, special builds for RT-N66U, RT-AC66U and Tenda W1800R only
    But now I see N66U elsewhere *too*:
    • K26RT-N – MIPSR2 – special builds for E4200, RT-N10U, RT-N12B1/C1, RT-N15U, RT-N53, RT-N66U, WNR3500Lv2 and newer Linksys E-series routers
    Maybe the inclusion of N66U under K26RT-AC is an error. After all, N66U isn't AC.

    UPDATE:

    I've now concluded that N66U under K26RT-AC is an error.
    This seems to be the correct firmware:

    N66U: tomato-K26USB-1.28.RT-N5x-MIPSR2-131-AIO-64K.trx
    AC66U: tomato-RT-AC66U_RT-AC6x--131-AIO-64K.trx

    I'll now reflash the N66U.
     
    Last edited: Oct 9, 2015
  47. Monk E. Boy

    Monk E. Boy Network Guru Member

    To be fair I'm running a Toastman N66 build on the N66 I queried there.

    I don't even show anything for "Build" in dmesg, though admittedly I just skimmed it since I've been saddled with cleaning someone's malware infested system tonight. Grr.
     
  48. BikeHelmet

    BikeHelmet Addicted to LI Member

    No build for me either on Toastman firmware. Must be a Shibby thing.

    -BikeHelmet
     
  49. Kisch

    Kisch LI Guru Member

    My result from today:

    Fri Oct 9 10:23:42 CEST 2015
    1.28.0000 -131 K26ARM USB VPN-64K
    Build_for__ASUS_PRODUCTS_003_lke_8.9.0_r225078_b43
    35
    1013
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack_c0423a7c 1035 1536 248 16 1 : tunables 0 0 0 :

    I used RT-N66 with K26RT-AC build (1.28.0000 -128 K26ARM USB VPN-64K) for about year without problem. If I remember correctly, AC and N builds for RT-N66 have only different wifi drivers.
     
  50. Planiwa

    Planiwa Network Guru Member

    This is a little more robust:
    Code:
    date
    nvram get router_name
    nvram get os_version
    nvram find model
    wl ver
    
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    egrep '^#|conn' /proc/slabinfo|awk '{print substr($0,1,80)}'
    
    Fri Oct 9 10:30:40 EDT 2015
    SpaAC66U131Shi
    1.28.0000 MIPSR2-131 K26AC USB AIO-64K
    model=RT-AC66U
    t_model=44
    t_model_name=Asus RT-AC66U
    6.30 RC102.9
    wl0: Sep 23 2013 11:46:29 version 6.30.102.9 (r366174)
    26
    35
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : sla
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : s
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : sl
     
    Last edited: Oct 9, 2015
  51. Planiwa

    Planiwa Network Guru Member

    On closer examination, it turns out that that "Build" was for the USB driver . . .
     
  52. Kisch

    Kisch LI Guru Member


    Result:

    Fri Oct 9 16:34:24 CEST 2015
    Netgear R7000
    1.28.0000 -131 K26ARM USB VPN-64K
    6.37 RC14.73
    wl0: Nov 17 2014 11:28:42 version 6.37.14.86 (r456083)
    198
    1176
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack_c0423a7c 1199 1536 248 16 1 : tunables 0 0 0 :
     
  53. Planiwa

    Planiwa Network Guru Member

    Here is a more robust, more sensitive Conntrack Count discrepancy checker for Scheduler.
    Might want to run this every hour.
    If you run it very frequently, the log file /var/log/CC may grow large.

    Code:
    BIG=10                                                 
    CTF="/proc/net/ip_conntrack"                           
    CCC="cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count"
    set -- $($CCC) $(wc -l < $CTF) $($CCC)
    D1=$(($2-$1))
    D2=$(($3-$2))
    C123="$*"     
    case "$D2$D1" in                             
    ?*-*) if [ $D1 -le -$BIG ] && [ $D2 -ge $BIG ]
          then ALERT="Big Discrepancy #####"
          else                 
               touch /var/log/CC           
               set -- $(tail -1 /var/log/CC)
               if [ "$D2$D1" == "$6$5" ]
               then ALERT="Consistent Small Discrepancy"
               fi                                   
          fi   
          echo "$(date +%y%m%d_%H%M) $C123 $D1 $D2" >>/var/log/CC
          ;;                                                   
    esac   
    logger -t Conntrack "$C123 $D1 $D2 $ALERT"
    
     
    Last edited: Oct 11, 2015
  54. Kisch

    Kisch LI Guru Member

    Planiwa, you really do like making scripts. :) I´m afraid, if nvram will has enough space after few pages of this thread and few script upgrades. :) :) But thank you very much, of course.
     
  55. Planiwa

    Planiwa Network Guru Member

    Code:
    nvram show |tail -1
    
    :)
     
  56. kckangaro

    kckangaro Network Newbie Member

    This showed that ip_conntrack_count is consistent with kernel in-use object allocation (1176 vs 1199, close enough). There are two possibilities:

    (1) kernel conntrack memory leak. If so, this also indicates a real leak, rather than a counter leak.
    (2) /proc/net/ip_conntrack dumps incomplete connection list.

    On my router, I have 6 days uptime and these are the stats:

    770
    770
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack_c0423a7c 787 1072 248 16 1 : tunables 0 0 0 :

    It seems fine. So I wonder if the problem is specific to a particular configuration.
     
  57. Planiwa

    Planiwa Network Guru Member

    Code:
    date
    uptime
    nvram get router_name
    nvram get os_version
    nvram find model
    wl ver
    
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    egrep '^#|conn' /proc/slabinfo|awk '{print substr($0,1,80)}'
    
    l /var/log
    
    grep -i Conntrack: /var/log/messages
    
    [EDIT: Small changes to make it more robust]

    Sat Oct 10 01:02:34 EDT 2015
    01:02:34 up 8 days, 3:21, load average: 0.00, 0.00, 0.00
    SpaAC66U131Shi
    1.28.0000 MIPSR2-131 K26AC USB AIO-64K
    model=RT-AC66U
    t_model=44
    t_model_name=Asus RT-AC66U
    6.30 RC102.9
    wl0: Sep 23 2013 11:46:29 version 6.30.102.9 (r366174)
    33
    42
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack:help 0 0 268 14 1 : tunables 54 27 0 : sla
    nf_conntrack_expect 0 0 148 26 1 : tunables 120 60 0 : s
    nf_conntrack:basic 0 0 236 16 1 : tunables 120 60 0 : sl
    -rw-r--r-- 1 root root 1260 Oct 10 00:57 CC
    -rw-r--r-- 1 root root 1869 Oct 9 14:14 apcupsd.events
    -rw-r--r-- 1 root root 12330 Oct 10 01:02 messages
    -rw-r--r-- 1 root root 51231 Oct 9 16:29 messages.0
    Oct 9 16:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 16:42:00 ROUTER user.notice Monitor: Conntrack Count: 77 68 77 -9 9 Consistent Small Discrepancy
    Oct 9 16:47:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 16:57:00 ROUTER user.notice Monitor: Conntrack Count: 72 63 72 -9 9 Consistent Small Discrepancy
    Oct 9 17:02:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 17:12:01 ROUTER user.notice Monitor: Conntrack Count: 56 47 56 -9 9 Consistent Small Discrepancy
    Oct 9 17:17:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 17:27:00 ROUTER user.notice Monitor: Conntrack Count: 143 134 142 -9 8
    Oct 9 17:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 17:42:00 ROUTER user.notice Monitor: Conntrack Count: 129 122 131 -7 9
    Oct 9 17:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 17:57:00 ROUTER user.notice Monitor: Conntrack Count: 37 28 37 -9 9
    Oct 9 18:02:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 18:12:00 ROUTER user.notice Monitor: Conntrack Count: 183 174 181 -9 7
    Oct 9 18:17:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 18:27:01 ROUTER user.notice Monitor: Conntrack Count: 61 52 61 -9 9
    Oct 9 18:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 18:42:00 ROUTER user.notice Monitor: Conntrack Count: 195 186 195 -9 9 Consistent Small Discrepancy
    Oct 9 18:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 18:57:00 ROUTER user.notice Monitor: Conntrack Count: 132 123 132 -9 9 Consistent Small Discrepancy
    Oct 9 19:02:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 19:12:00 ROUTER user.notice Monitor: Conntrack Count: 140 131 140 -9 9 Consistent Small Discrepancy
    Oct 9 19:17:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 19:27:00 ROUTER user.notice Monitor: Conntrack Count: 69 60 69 -9 9 Consistent Small Discrepancy
    Oct 9 19:32:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 19:42:01 ROUTER user.notice Monitor: Conntrack Count: 71 62 71 -9 9 Consistent Small Discrepancy
    Oct 9 19:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 19:57:00 ROUTER user.notice Monitor: Conntrack Count: 40 31 40 -9 9 Consistent Small Discrepancy
    Oct 9 20:02:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 20:12:00 ROUTER user.notice Monitor: Conntrack Count: 180 171 180 -9 9 Consistent Small Discrepancy
    Oct 9 20:17:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 20:27:00 ROUTER user.notice Monitor: Conntrack Count: 68 59 68 -9 9 Consistent Small Discrepancy
    Oct 9 20:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 20:42:00 ROUTER user.notice Monitor: Conntrack Count: 40 31 40 -9 9 Consistent Small Discrepancy
    Oct 9 20:47:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 20:57:01 ROUTER user.notice Monitor: Conntrack Count: 196 187 196 -9 9 Consistent Small Discrepancy
    Oct 9 21:02:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 21:12:00 ROUTER user.notice Monitor: Conntrack Count: 33 24 33 -9 9 Consistent Small Discrepancy
    Oct 9 21:17:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 21:27:00 ROUTER user.notice Monitor: Conntrack Count: 14 5 14 -9 9 Consistent Small Discrepancy
    Oct 9 21:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 21:42:00 ROUTER user.notice Monitor: Conntrack Count: 16 7 16 -9 9 Consistent Small Discrepancy
    Oct 9 21:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 21:57:00 ROUTER user.notice Monitor: Conntrack Count: 32 23 32 -9 9 Consistent Small Discrepancy
    Oct 9 22:02:02 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 22:12:01 ROUTER user.notice Monitor: Conntrack Count: 38 29 38 -9 9 Consistent Small Discrepancy
    Oct 9 22:17:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 22:27:00 ROUTER user.notice Monitor: Conntrack Count: 24 15 24 -9 9 Consistent Small Discrepancy
    Oct 9 22:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 22:42:00 ROUTER user.notice Monitor: Conntrack Count: 22 13 22 -9 9 Consistent Small Discrepancy
    Oct 9 22:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 22:57:00 ROUTER user.notice Monitor: Conntrack Count: 22 13 22 -9 9 Consistent Small Discrepancy
    Oct 9 23:02:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 23:12:00 ROUTER user.notice Monitor: Conntrack Count: 14 5 14 -9 9 Consistent Small Discrepancy
    Oct 9 23:17:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 23:27:01 ROUTER user.notice Monitor: Conntrack Count: 11 2 11 -9 9 Consistent Small Discrepancy
    Oct 9 23:32:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 23:42:00 ROUTER user.notice Monitor: Conntrack Count: 10 1 10 -9 9 Consistent Small Discrepancy
    Oct 9 23:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 9 23:57:00 ROUTER user.notice Monitor: Conntrack Count: 11 2 11 -9 9 Consistent Small Discrepancy
    Oct 10 00:02:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 10 00:12:00 ROUTER user.notice Monitor: Conntrack Count: 12 3 12 -9 9 Consistent Small Discrepancy
    Oct 10 00:17:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 10 00:27:00 ROUTER user.notice Monitor: Conntrack Count: 13 4 13 -9 9 Consistent Small Discrepancy
    Oct 10 00:32:01 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 10 00:42:01 ROUTER user.notice Monitor: Conntrack Count: 53 44 53 -9 9 Consistent Small Discrepancy
    Oct 10 00:47:00 ROUTER user.notice root: Monitor: BWM ok 0
    Oct 10 00:57:00 ROUTER user.notice Monitor: Conntrack Count: 32 23 32 -9 9 Consistent Small Discrepancy
    Oct 10 01:02:01 ROUTER user.notice root: Monitor: BWM ok 0

    So, slabinfo seems useless for N66U and AC66U.
    And yes, sure looks like memory leak.
    I'm not sure whether there is a suggestion that

    wc -l < /proc/net/ip_conntrack
    might return a different result from
    cat /proc/net/ip_conntrack | wc -l

    Certainly 6 years ago this was the case, and it was I who first discovered and documented this.
    But it is no longer the case.

    Today,
    wc -l < /proc/net/ip_conntrack
    is perfectly safe.
     
    Last edited: Oct 11, 2015
  58. Planiwa

    Planiwa Network Guru Member

    I've now reflashed the N66U to the first one of these two:

    N66U: tomato-K26USB-1.28.RT-N5x-MIPSR2-131-AIO-64K.trx
    N66U, AC66U: tomato-RT-AC66U_RT-AC6x--131-AIO-64K.trx

    Apparently some folks like to use the older SDK v 5 (N) for the N66U,
    rather than the SDK v6 (AC) for both N66U and AC66U.

    Apparently Tomato Firmware doesn't understand AC, so it treats both routers the same.

    Apparently there really is no way to tell them apart, other than by looking at the physical device.
     
  59. Kisch

    Kisch LI Guru Member

    Code:
    date
    uptime
    nvram get router_name
    nvram get os_version
    nvram find model
    wl ver
    
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    egrep '^#|conn' /proc/slabinfo|awk '{print substr($0,1,80)}'
    
    l /var/log
    
    grep Monitor /var/log/*es
    Sun Oct 11 08:32:31 CEST 2015
    08:32:31 up 4 days, 19:50, load average: 0.00, 0.01, 0.04
    Netgear R7000
    1.28.0000 -131 K26ARM USB VPN-64K
    6.37 RC14.73
    wl0: Nov 17 2014 11:28:42 version 6.37.14.86 (r456083)
    150
    1877
    # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack_c0423a7c 1902 2112 248 16 1 : tunables 0 0 0 :
    -rw-r--r-- 1 root root 1341 Oct 11 08:07 CC
    -rw-r--r-- 1 root root 11 Oct 10 21:42 commit_ret
    drwx------ 4 root root 80 Jan 1 1970 cores/
    lrwxrwxrwx 1 root root 33 Oct 9 07:03 messages -> /tmp/mnt/FLASH_1GB/Log/syslog.txt*
    -rw-r--r-- 1 root root 0 Jan 1 1970 nmbd.log
    -rw-r--r-- 1 root root 0 Jan 1 1970 smbd.log
    /var/log/messages:Oct 7 22:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 234 46 234 -188 188
    /var/log/messages:Oct 7 23:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 205 16 205 -189 189
    /var/log/messages:Oct 8 00:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 198 9 198 -189 189
    /var/log/messages:Oct 8 01:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 200 11 200 -189 189
    /var/log/messages:Oct 8 02:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 199 10 199 -189 189
    /var/log/messages:Oct 8 03:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 195 6 195 -189 189
    /var/log/messages:Oct 8 04:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 195 6 195 -189 189
    /var/log/messages:Oct 8 05:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 195 6 195 -189 189
    /var/log/messages:Oct 8 06:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 204 15 204 -189 189
    /var/log/messages:Oct 8 07:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 212 23 212 -189 189
    /var/log/messages:Oct 8 08:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 242 53 242 -189 189
    /var/log/messages:Oct 8 09:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 242 53 242 -189 189
    /var/log/messages:Oct 8 10:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 240 51 240 -189 189
    /var/log/messages:Oct 8 11:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 200 11 200 -189 189
    /var/log/messages:Oct 8 12:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 199 10 199 -189 189
    /var/log/messages:Oct 8 13:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 224 35 224 -189 189
    /var/log/messages:Oct 8 14:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 221 32 221 -189 189
    /var/log/messages:Oct 8 15:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 199 10 199 -189 189
    /var/log/messages:Oct 8 16:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 203 14 203 -189 189
    /var/log/messages:Oct 8 17:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 595 406 595 -189 189
    /var/log/messages:Oct 8 18:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 244 23 244 -221 221
    /var/log/messages:Oct 8 19:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 428 95 428 -333 333
    /var/log/messages:Oct 8 20:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 575 71 575 -504 504
    /var/log/messages:Oct 8 21:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1140 446 1140 -694 694
    /var/log/messages:Oct 8 22:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1126 232 1126 -894 894
    /var/log/messages:Oct 8 23:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 985 19 985 -966 966
    /var/log/messages:Oct 9 00:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 972 6 972 -966 966
    /var/log/messages:Oct 9 01:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 974 8 974 -966 966
    /var/log/messages:Oct 9 02:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 972 6 972 -966 966
    /var/log/messages:Oct 9 03:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1015 49 1015 -966 966
    /var/log/messages:Oct 9 04:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 976 10 976 -966 966
    /var/log/messages:Oct 9 05:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 972 6 972 -966 966
    /var/log/messages:Oct 9 06:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 983 17 983 -966 966
    /var/log/messages:Oct 9 06:52:32 Netgear-R7000 user.notice Monitor: Conntrack Count: 1002 36 1002 966 ALARM #######################
    /var/log/messages:Oct 9 07:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1059 81 1059 -978 978
    /var/log/messages:Oct 9 08:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1034 56 1034 -978 978
    /var/log/messages:Oct 9 09:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1029 51 1029 -978 978
    /var/log/messages:Oct 9 10:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 999 21 999 -978 978
    /var/log/messages:Oct 9 11:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 998 20 998 -978 978
    /var/log/messages:Oct 9 12:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 993 15 993 -978 978
    /var/log/messages:Oct 9 13:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 993 15 993 -978 978
    /var/log/messages:Oct 9 14:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 994 16 994 -978 978
    /var/log/messages:Oct 9 15:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 994 16 994 -978 978
    /var/log/messages:Oct 9 16:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 997 19 997 -978 978
    /var/log/messages:Oct 9 17:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1042 36 1042 -1006 1006
    /var/log/messages:Oct 9 18:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1088 24 1088 -1064 1064
    /var/log/messages:Oct 9 19:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1106 38 1106 -1068 1068
    /var/log/messages:Oct 9 20:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1111 26 1111 -1085 1085
    /var/log/messages:Oct 9 20:36:52 Netgear-R7000 user.notice Monitor: Conntrack Count: 1123 35 1123 -1088 1088 Big Discrepancy #####
    /var/log/messages:Oct 9 21:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1355 267 1355 -1088 1088 Big Discrepancy #####
    /var/log/messages:Oct 9 22:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1257 147 1256 -1110 1109 Big Discrepancy #####
    /var/log/messages:Oct 9 23:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1157 45 1157 -1112 1112 Big Discrepancy #####
    /var/log/messages:Oct 10 00:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1118 5 1118 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 01:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1118 5 1118 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 02:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1119 6 1119 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 03:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1119 6 1119 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 04:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1118 5 1118 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 05:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1118 5 1118 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 06:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1118 5 1118 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 07:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1138 25 1138 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 08:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1129 16 1129 -1113 1113 Big Discrepancy #####
    /var/log/messages:Oct 10 09:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1308 175 1308 -1133 1133 Big Discrepancy #####
    /var/log/messages:Oct 10 10:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1455 162 1455 -1293 1293 Big Discrepancy #####
    /var/log/messages:Oct 10 11:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1788 283 1788 -1505 1505 Big Discrepancy #####
    /var/log/messages:Oct 10 12:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 2026 311 2026 -1715 1715 Big Discrepancy #####
    /var/log/messages:Oct 10 13:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1905 182 1905 -1723 1723 Big Discrepancy #####
    /var/log/messages:Oct 10 14:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1902 178 1902 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 15:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1922 198 1922 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 16:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1961 237 1961 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 17:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1937 213 1937 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 18:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1966 242 1966 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 19:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1959 235 1959 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 20:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1944 220 1944 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 21:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1932 208 1932 -1724 1724 Big Discrepancy #####
    /var/log/messages:Oct 10 22:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1917 191 1917 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 10 23:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1837 111 1837 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 00:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1762 36 1762 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 01:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1746 20 1746 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 02:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1734 8 1734 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 03:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1762 36 1762 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 04:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1734 8 1734 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 05:07:01 Netgear-R7000 user.notice Monitor: Conntrack Count: 1736 10 1736 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 06:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1805 79 1805 -1726 1726 Big Discrepancy #####
    /var/log/messages:Oct 11 07:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1807 80 1807 -1727 1727 Big Discrepancy #####
    /var/log/messages:Oct 11 08:07:00 Netgear-R7000 user.notice Monitor: Conntrack Count: 1848 121 1848 -1727 1727 Big Discrepancy #####


    Rising slow, but still.
     
  60. ChefJoe

    ChefJoe Connected Client Member

    I'm by no means an expert on what you're trying to do, but I spent some time looking at the advanced-vlan source in shibby's RT-AC branch as well as how tvlz has been editing the detection of these two routers. These two routers return the same "boardtype" hex value but should/?do? respond to t_model_name differently.

    Here's the code where tvlz uses that to fix some port numbering differences between those models in advanced-vlan.
    https://app.box.com/s/45a87641237557490213
    http://www.linksysinfo.org/index.php?threads/can-vlan-gui-port-order-be-corrected.70160/#post-248582

    Best of luck.
     
  61. Planiwa

    Planiwa Network Guru Member

    Hm.
    http://www.linksysinfo.org/index.php?threads/conntrack-table-problem.71756/#post-266938
    When I ran the AC firmware on the N66U it seemed to look the same.

    But tvlz's link suggests this:

    nvram find board

    and that shows a difference, although I can't verify it since I'm now running
    1.28.0000 MIPSR2-131 K26 USB AIO-64K on the N66U.

    Here's what I get:
    Code:
    nvram find board
    nvram get router_name
    nvram get os_version
    nvram find model
    wl ver
    
    boardflags2=0x00000000
    boardflags=0x00000110
    boardnum=00
    boardrev=0x1100
    boardtype=0xF5B2
    pci/1/1/boardflags2=0x00100000
    pci/1/1/boardflags=0x80001200
    pci/1/1/boardvendor=0x14E4
    pci/2/1/boardflags2=0x00200000
    pci/2/1/boardflags=0x90000200
    pci/2/1/boardvendor=0x14E4
    BruN66U131Shi
    1.28.0000 MIPSR2-131 K26 USB AIO-64K
    t_model=44
    t_model_name=Asus RT-N66U
    5.110 RC27.20012
    wl0: Jan 23 2013 14:32:57 version 5.110.27.20012

    boardflags2=0x00000000
    boardflags=0x00000110
    boardnum=00
    boardrev=0x1100
    boardtype=0xF5B2
    pci/1/1/boardflags2=0x00100000
    pci/1/1/boardflags=0x00003200
    pci/1/1/boardvendor=0x14E4
    pci/2/1/boardflags2=0x00300002
    pci/2/1/boardflags3=0x0
    pci/2/1/boardflags=0x10000000
    pci/2/1/boardnum=21059
    pci/2/1/boardrev=0x1305
    pci/2/1/boardtype=0x621
    pci/2/1/boardvendor=0x14e4
    SpaAC66U131Shi
    1.28.0000 MIPSR2-131 K26AC USB AIO-64K
    model=RT-AC66U
    t_model=44
    t_model_name=Asus RT-AC66U
    6.30 RC102.9
    wl0: Sep 23 2013 11:46:29 version 6.30.102.9 (r366174)

    [As I write this, I ask myself why am I still using that old N66U at all? The radio become quite unstable a year ago.]
    [And it seems that the AC66U doesn't really do AC at all with Tomato, so it's just a more expensive N66U. Sigh.]
     
  62. tvlz

    tvlz LI Guru Member

    There are differences, but Tomato only uses the boardtype to set the router id - in this case (boardtype=0xF5B2).
    It should with the AC builds, I'm sure there would have been complains if it didn't work.
     
  63. Planiwa

    Planiwa Network Guru Member

    *Should*, but does it?

    There is no 802.11AC anywhere, and if I set Channel width to 80, it actually ends up being 20.

    What am I doing wrong?
     
  64. PetervdM

    PetervdM Network Guru Member

    i have an ac66u and have ac.
    maybe you didn't do anything wrong, but getting ac is a bit tricky. this is what i had to do:
    • clear nvram and reboot. i did it from the command line: nvram erase; sync; reboot
    • flash new software, tick "erase all data"
    • leave the router alone for half an hour. i believe this is the most important part.
    • reboot the router by switching the router off, wait 15 seconds, and switch it back on.
    • wait for 5 minutes
    • configure the router by hand. don't restore a backup.
    • in basic wireless i set channel width=80, control sideband=lower, security=wpa2 personal and encryption=aes only, no tkip!
    • in advanced wireless, 5 ghz section i left everything default except: region=singapore, 802.11n preamble=greenfield, transmit power=0, wmm=enabled
    right now i am connected at 702 mbps using an intel 7260 card in my laptop.

    edit:
    i'm using channel 52 right now, and use different ssid's for 2.4 and 5 GHz. i have no apple devices available for test, but different ssid's enable me to force a system to use an 5 GHz ac connection instead of a 2.4 GHz n connection.
     
    Last edited: Oct 14, 2015
  65. Planiwa

    Planiwa Network Guru Member

    Well, I'm willing to try this exactly as described. How about other settings -- channel?
    I noticed that changing Channel from default 36 to 100 already raises connect rate from 144 to 300 and actually uses the 80Mhz channel width. How about using same SSID for 2 and 5 GHz -- any reason not to? (They say Apple devices connect to what looks like the best network, not just the one with the stronger signal.)

    More later . . .
     
  66. Kisch

    Kisch LI Guru Member

    Yesterday I inslalled with hope new Shibby 1.32 vpn version. But problem persists:

    Conntrack Count: 1798 872 1797 -926 925 Big Discrepancy #####

    :(
     
  67. kckangaro

    kckangaro Network Newbie Member

    The change log for v132 doesn't include anything related to conntrack. So no, I don't think v132 would fix the bug you are experiencing.
     
  68. Kisch

    Kisch LI Guru Member

    I know, but I hoped.
     
  69. Planiwa

    Planiwa Network Guru Member

    So, I installed 132 using this precise procedure.

    What setting should I select for 5 GHz Wireless Network Mode?

    Auto, N only, or A only?

    NB: The Sagemcom offers: Auto, N, or AC.

    Does AC and A mean exactly the same, in this context?

    NB: A only forces a Channel Width of 20 MHz.
     
  70. PetervdM

    PetervdM Network Guru Member

    you should leave 5GHz wireless to auto ( at least i did ). ac is not the same as a, they refer to the standards 802.11ac, describing the technologies used to obtain networking speeds up to 1.1 Gb/s and 802.11a, describing the technologies used to obtain network speeds up to 54 Mb/s.
    both are currently only available on the 5GHz band. as the 802.11a specifications does not include wideband, 20MHz is the maximum available with the "a" setting.
     
  71. Planiwa

    Planiwa Network Guru Member

    Thanks! So, here is my concern. On 5Ghz:

    Sagemcom offers: Auto, a only, n only, ac only.
    ..... Tomato offers: Auto, A Only, N Only.

    I am concerned that Tomato does not offer "AC (Only)".
    There seems to be no mention of AC, or indication that Tomato is AC-aware.
     
  72. Planiwa

    Planiwa Network Guru Member

    I'm happy to report that I have been able to determine that, under my circumstances, Shibby Tomato does 802.11AC, and that it reaches 50% further and gives 50% more "speed".
     
    Last edited: Oct 26, 2015
  73. PetervdM

    PetervdM Network Guru Member

    maybe forcing AC under circumstances can lead to a lower connection speed than N. it didn't seem unlogical to me to not be able to "lock" to the higher standard. Anyway, it works for me.
     
  74. Samuelheng

    Samuelheng Networkin' Nut Member

    it this happen on ARM-Router only ?? currently using netgear-r7000 i had this problem and my other router asus rtn66u doesn't had this kind of problem.aways had netgear-r7000 router reboot every 2 or 3 day later and i check log aways show nf_conntrack: table full, dropping packet.
     
  75. Planiwa

    Planiwa Network Guru Member

    No. Happens to RT-N66U and RT-AC66U on recent Shibby, but not N16 on Shibby 115

    Run these two commands:

    Code:
    nvram find os_version
    wl ver
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    
    If the two numbers are different, you have the bug.

    The bug is that the pseudofile /proc/sys/net/ipv4/netfilter/ip_conntrack_count contains false data.

    1.28.0000 MIPSR2-132 K26AC USB AIO-64K AC66U -- bug
    1.28.0000 MIPSR2-131 K26 USB AIO-64K N66U -- bug
    1.28.0000 MIPSR2-115 K26 USB AIO N16 -- no bug
     
    Last edited: Oct 30, 2015
  76. Samuelheng

    Samuelheng Networkin' Nut Member

    thk for reply. done running those code

    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    1084
    9243

    how to solve this kind of problem ?? change FW ?? it only happen in netgear-r7000
    i am using this FW tomato-R7000-ARM--132-AIO-64K.trx.
     
  77. Planiwa

    Planiwa Network Guru Member

    Has anyone experienced this problem with FW other than Shibby?
    Has anyone looked at the code that produces the value for /proc/sys/net/ipv4/netfilter/ip_conntrack_count ?
     
  78. pegasus123

    pegasus123 Addicted to LI Member

    Code:
    os_version=1.28.0000 MIPSR2-132 K26 USB TendaN60
    5.110 RC27.20012
    wl0: Jan 23 2013 14:32:57 version 5.110.27.20012
    128
    131 
    I noticed mine has now a 3 count gap. i wonder if yours started with a connection that is not being track properly same with mine with that missing 3 conntrack.

    It goes up and down with 3 count gap
     
    Last edited: Oct 31, 2015
  79. Samuelheng

    Samuelheng Networkin' Nut Member


    ya at the beginning the connection track properly after some time , the conntrack is missing a lot when running torrent and other connection.for temporary fix i raise some Maximum Connections conntrack or reboot a router. this not happen in my other router asus-rtn66u.

    Code:
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    1123
    18598
     
  80. pegasus123

    pegasus123 Addicted to LI Member

    I cant understand any in the source code :p
    http://repo.or.cz/tomato.git/blob/9.../linux/net/ipv4/netfilter/ip_conntrack_core.c
     
  81. Samuelheng

    Samuelheng Networkin' Nut Member

  82. Samuelheng

    Samuelheng Networkin' Nut Member

    ady run other FW still the same. try by reset to default ,erase nvram and reconfigure back by hand. i think only happen when i start using torrent and the ip_conntrack start missing a lot later.I have maximum connections set to 16384 and total connections count was below 800-1000 and ip_conntrack_count say i ady max the connection.reboot the router and ip_conntrack became normal back.

    Toastman ARM build
    1.28.9002 with updated miniunpnpd -two numbers are different
    1.28.9002 without updated miniunpnpd - two numbers are different

    Code:
    
    re test
    
    6.37 RC14.73
    wl0: Nov 17 2014 11:28:42 version 6.37.14.86 (r456083)
    992
    7265
    
    Sun Nov  1 00:35:18 UTC 2015
    00:35:18 up  6:18,  load average: 0.19, 0.18, 0.15
    NETGEAR-R7000
    1.28.0000 -132 K26ARM USB VPN-64K
    6.37 RC14.73
    wl0: Nov 17 2014 11:28:42 version 6.37.14.86 (r456083)
    895
    7923
    # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
    nf_conntrack_c0423a7c   7940   8144    248   16    1 : tunables    0    0    0 :
    -rw-r--r--    1 root     root            11 Oct 31 21:49 commit_ret
    drwx------    4 root     root            80 Oct 31 18:19 cores/
    -rw-r--r--    1 root     root          1485 Nov  1 00:33 messages
    -rw-r--r--    1 root     root         51245 Oct 31 22:00 messages.0
    -rw-r--r--    1 root     root             0 Oct 31 18:19 nmbd.log
    -rw-r--r--    1 root     root             0 Oct 31 18:19 smbd.log 

    edit

    had anyone try reboot the router and had qos turn off , and try running those code ??
    it seems turn off qos ip_conntrack_count normal again after reboot.

    Code:
    nvram find os_version
    wl ver
    wc -l < /proc/net/ip_conntrack
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    mine see better than before
    6.37 RC14.73
    wl0: Nov 17 2014 11:28:42 version 6.37.14.86 (r456083)
    396
    396


    running around 5-10 min with no missing conntrack count.
     
    Last edited: Nov 1, 2015
  83. pegasus123

    pegasus123 Addicted to LI Member

    after 2 days uptime, mine is still 3 count gap. Kind of stable in this case.
     
  84. Samuelheng

    Samuelheng Networkin' Nut Member

    turn off qos and reboot router almost 1 day. seems stable and no count gap anymore. if i try turn on qos the conntrack count gap starting missing a lot when start using torrent. dun know y??
     
  85. pegasus123

    pegasus123 Addicted to LI Member

    hmm wow, not sure but i always enabled qos thats why maybe i have a gap? how about your timeout settings?

    did you set it low? you have a high tcp/udp conntrack, unless you have so many devices connected.

    Maybe setting it to low will help.

    In my case, im really not paying attention to this anymore. seems stable to me at least.

    [​IMG]

    A screenshot with many devices connected. No torrent currently.

    [​IMG]
     
  86. Samuelheng

    Samuelheng Networkin' Nut Member


    this is my setting

    qos.jpg
     
  87. pegasus123

    pegasus123 Addicted to LI Member

    backup it and try mine. this is actually the default Toastman conntrack timeout, i dont usually hit 1000 connections on any given time due to this even with torrent on.
     
  88. Samuelheng

    Samuelheng Networkin' Nut Member

    ok i will try using toastman ARM FW 1 more time.
    do you also using scripts in firewall like limit udp or tcp ??

    edit
    Toastman build only got two version
    1.28.9002 with updated miniunpnpd
    1.28.9002 without updated miniunpnpd
     
  89. pegasus123

    pegasus123 Addicted to LI Member

    No, you can use your current firmware and set the timeouts.

    For firewall, no i didnt set any limiting script to udp/tcp. However i have a scheduler every night to stop my QOS
    in Administrator > Scheduler. This is usually the time i do torrent download

    every 1 am
    nvram set qos_enable="0"
    service qos stop

    every 8am
    nvram set qos_enable="1"
    service qos restart
     
  90. Samuelheng

    Samuelheng Networkin' Nut Member

    ok i will try later time to see any different.
     
  91. Planiwa

    Planiwa Network Guru Member

    Just a few data points:

    1. my systems never use QOS.
    2. my systems never use torrent.
    3. both N66U and AC66U have this bug.
    4. I doubt that it is a matter of the Conntrack table missing "connections".
    Instead, I think it's the _count_ pseudovariable failing to count properly.
     
  92. Samuelheng

    Samuelheng Networkin' Nut Member

    ya i also think so,ady try few ARM FW like toastman,shibby,advance tomato on netgear-r7000 and conntrack count easy hit to max and begin show nf_conntrack: table full, dropping packet when torrent running ,but i only hit around 600-1000 connection running on netgear r7000. but my other router asus RT-N66U din have this kind of problem even i had turn on qos and running multiple torrent together with conntrack count gap not miss a lot only few count only and it seems stable to me at least.
     
  93. Planiwa

    Planiwa Network Guru Member

    Also, the slabinfo nf_conntrack data is missing for Asus RT-N16, RT-N66U, and RT-AC66U.

    Also, there is exactly one place where ip_conntrack_count is incremented, and one place where it is decremented.
    ISTM that either it is incremented too often or not decremented enough. (I suspect the latter.)

    It is also possible that it is adjusted properly, but connections are either not created in the table when they should be, or they are mistakenly destroyed. (I consider that less probable).
     
  94. kckangaro

    kckangaro Network Newbie Member

    RT-N16, RT-N66U, and RT-AC66U all has mips based CPU. The firmware is compiled with 2.6.22 kernel source tree. In that version of kernel, conntrack struct is embedded inside socket buffer.

    RT-AC68U and Netgear R7000 has ARM cpu and the firmware uses kernel source 2.6.36. In that version, conntrack struct was split out into its own slab cache and I suspect there is a bug somewhere when it was pulled out of socket buffer.
     
  95. Planiwa

    Planiwa Network Guru Member

    Please read carefully:

    1.28.0000 MIPSR2-132 K26AC USB AIO-64K AC66U -- bug
    1.28.0000 MIPSR2-131 K26 USB AIO-64K N66U -- bug
    1.28.0000 MIPSR2-115 K26 USB AIO N16 -- no bug
     
  96. Samuelheng

    Samuelheng Networkin' Nut Member

    For all Netgear R7000 Users, can anyone confirm having this kind of problem or only some have it ??
    thk.
     
  97. pegasus123

    pegasus123 Addicted to LI Member

    i have not been torrenting for a few days already. gap is still 3 counts

    Code:
     12:18:14 up 5 days, 23:21, load average: 0.00, 0.02, 0.00 
    131 
    134
     
    Samuelheng likes this.
  98. Samuelheng

    Samuelheng Networkin' Nut Member

    edit:somehow i playing the router conntrack setting with qos turn off and on setting , i find out the conntrack count begin broken when i click the qos gui graph open with torrent running. i also try reboot again this time i try not to open qos gui graph and been running running stable around 1 hour with no broken conntrack count and Qos is turn on thk.

    Code:
    6.37 RC14.73
    wl0: Nov 17 2014 11:28:42 version 6.37.14.86 (r456083)
    841
    841 
    tested many time ady ,confirm when view some graphs from qos gui the conntrack count start to broken after tht.(reset&erase nvram and configure back from default still the same on netgear r7000)
     
    Last edited: Nov 7, 2015
  99. Kisch

    Kisch LI Guru Member

    Interesting, seems it behave same in my case.
     
  100. Samuelheng

    Samuelheng Networkin' Nut Member

    Ya it seems so.for me temporary solution is stay away from qos graphs gui if you want maintain conntrack correct count, with this I manage stay uptime near 1 week with stable conntrack count thk.

    note: maybe conntrack count only broken when you open qos graphs gui on internet browser and leave it open. when you close the qos graphs gui again. the missing count seems stop.
     
    Last edited: Nov 10, 2015
  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