NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Losing WAN connectivity frequently
We have been running this FVS336Gv2 for quite some time with no trouble.
Recently, the ISP changed the modem and, since then, we've been losing connectivity.
The only solution so far is to reboot the router.
I see this in the log:
[FVS336Gv2]Sat May 30 00:52:36 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] HTB: quantum of class 10001 is big. Consider r2q change.
[FVS336Gv2]Sat May 30 00:52:36 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] HTB: quantum of class 11024 is big. Consider r2q change.
[Connectivity remained lost at this time]
�ulpNodeFree+0x0/0x90 [vipsec]
[FVS336Gv2]Sat May 30 00:52:52 2020((GMT-0800)) [FVS336Gv2][System][NIMF] Link Status of WAN1 is LINK UP
[FVS336Gv2]Sat May 30 00:52:52 2020((GMT-0800)) [FVS336Gv2][System][NIMF] Restarting WAN1 for IPv4
[FVS336Gv2]Sat May 30 00:52:53 2020((GMT-0800)) [FVS336Gv2][System][NIMF] nimfAdvOptSetWrap: NIMF table is NimfStatus
[FVS336Gv2]Sat May 30 00:52:59 2020((GMT-0800)) [FVS336Gv2][System][NIMF] Link Status of WAN1 is LINK UP
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_destroy(tp a8000000046fb400),p a8000000046fb380
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_walk(tp a8000000046fb400,walker a80000000308bd30),p a8000000046fb380
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_delete(tp a8000000046fb400,arg 0xa8000000046fb308),p a8000000046fb380,f 0000000000000000
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] HTB init, kernel part version 3.17
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_init(tp a8000000046fb400)
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_get(tp a8000000046fb400,handle 0x00000000)
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_change(tp a8000000046fb400,handle 0x00000000,tca a800000007c0b500,arg a800000003243920),opt a8000000057e1030,p a8000000046fb380,r 0000000000000000,*arg 0x0
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] tcindex_dump(tp a8000000046fb400,fh 0x0,skb a80000000580b800,t a80000000605d010),p a8000000046fb380,r 0000000000000000,b a80000000605d038
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] p->perfect 0000000000000000 p->h a8000000056cc000
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] HTB: quantum of class 10001 is big. Consider r2q change.
[FVS336Gv2]Sat May 30 00:53:56 2020((GMT-0800)) [FVS336Gv2][Kernel][KERNEL] HTB: quantum of class 11024 is big. Consider r2q change.
[Connectivity was lost at about this time]
I have no idea what "Consider r2q change" refers to or how to accomplish that.
I have read that changing MTU from 1500 to 1492 has helped some with this same kind of problem. I don't like doing that without some assurance that it won't break things completely.
Any info / suggestions?
3 Replies
I have read that changing MTU from 1500 to 1492 has helped some with this same kind of problem. I don't like doing that without some assurance that it won't break things completely.
Changing the MTU from 1500 to 1492 won't break your FVS336Gv2. Kindly read the response of GopherGuy (Message 14 of 15) on this old forum thread here.
Regards,
DaneA
NETGEAR Community Team
OK. Thanks.
[NB: I have seen this type of change drastically affect communications in the past. That's why I asked. I didn't mean would it "break" the FVS336Gv2, just that the communication might be stopped.]
I did change the MTU from 1500 to 1492. It appears there are no ill effects in interoperation.
However, the dropouts of internet service continue.
We have instrumented this carefully and find the router to be the center of failure.
A reboot of the router fixes the problem when it persists.
Intermittent connection failures continue.
We are *still* logging:
HTB: quantum of class 11024 is big. Consider r2q change.
But have no idea what this means or what action is possible to "fix" it if that's a reasonable term. It does appear to be connected with the internet connectivity. But, that's not a conclusive determination.
Any ideas?
Let me share this old community post here. The same logs showing "HTB: quantum of class 11024 is big. Consider r2q change" was experienced by the community member 'WANAO' and he shared the solution he did to resolve it. The solution posted might work for you as well. Kindly try it.
Regards,
DaneA
NETGEAR Community Team
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
