What's new

Every 15 minutes my RT-AC1900P is acting weird

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

road hazard

Regular Contributor
Been trying to troubleshoot an issue lately and wasn't sure if it's my cable modem, router or switch. What's happening is if I'm talking to somebody on my VoIP line (or using Teams for work) the audio gets distorted every 15 minutes for a few seconds. The problem will also manifest itself in another way.... if I'm watching a high def video stream on my Apple TV, every 15 minutes the quality shifts to SD for a few seconds then right back up to full HD.

I was on a conference call with Teams and opened up some terminals on my Linux box and was doing all these pings at the same time to a 2nd PC in my house, the cable modem, my router and Google DNS. (Everything is hardwired.) When I heard the audio distortion, pings from my workstation to another PC in my house and the cable modem were AOK:

Ping to cable modem:
Code:
64 bytes from 192.168.100.1: icmp_seq=387 ttl=63 time=1.74 ms
64 bytes from 192.168.100.1: icmp_seq=388 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=389 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=390 ttl=63 time=1.59 ms
64 bytes from 192.168.100.1: icmp_seq=391 ttl=63 time=1.74 ms
64 bytes from 192.168.100.1: icmp_seq=392 ttl=63 time=1.72 ms
64 bytes from 192.168.100.1: icmp_seq=393 ttl=63 time=1.73 ms
64 bytes from 192.168.100.1: icmp_seq=394 ttl=63 time=1.70 ms
64 bytes from 192.168.100.1: icmp_seq=395 ttl=63 time=1.83 ms
64 bytes from 192.168.100.1: icmp_seq=396 ttl=63 time=1.63 ms
64 bytes from 192.168.100.1: icmp_seq=397 ttl=63 time=1.71 ms
64 bytes from 192.168.100.1: icmp_seq=398 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=399 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=400 ttl=63 time=1.69 ms
64 bytes from 192.168.100.1: icmp_seq=401 ttl=63 time=1.85 ms
64 bytes from 192.168.100.1: icmp_seq=402 ttl=63 time=1.63 ms

Ping to another PC in my house:
Code:
64 bytes from 192.168.1.5: icmp_seq=354 ttl=64 time=0.168 ms
64 bytes from 192.168.1.5: icmp_seq=355 ttl=64 time=0.260 ms
64 bytes from 192.168.1.5: icmp_seq=356 ttl=64 time=0.356 ms
64 bytes from 192.168.1.5: icmp_seq=357 ttl=64 time=0.282 ms
64 bytes from 192.168.1.5: icmp_seq=358 ttl=64 time=0.278 ms
64 bytes from 192.168.1.5: icmp_seq=359 ttl=64 time=0.273 ms
64 bytes from 192.168.1.5: icmp_seq=360 ttl=64 time=0.309 ms
64 bytes from 192.168.1.5: icmp_seq=361 ttl=64 time=0.292 ms
64 bytes from 192.168.1.5: icmp_seq=362 ttl=64 time=0.338 ms
64 bytes from 192.168.1.5: icmp_seq=363 ttl=64 time=0.341 ms
64 bytes from 192.168.1.5: icmp_seq=364 ttl=64 time=0.332 ms
64 bytes from 192.168.1.5: icmp_seq=365 ttl=64 time=0.363 ms
64 bytes from 192.168.1.5: icmp_seq=366 ttl=64 time=0.353 ms
64 bytes from 192.168.1.5: icmp_seq=367 ttl=64 time=0.320 ms

Pings to my router and Google DNS spiked into the 2,000-3,000 range. This leads me to believe my switch isn't the problem nor is my cable modem. It really looks like my router is flaking out on me. I'm using FW v3.0.0.4.385_20633-g593a8ef. Does anyone else agree that the culprit is my router? If so, will switching to Merlin fix things or does it sound like a hardware problem?

Ping to Google DNS:
Code:
64 bytes from 8.8.8.8: icmp_seq=135 ttl=115 time=17.8 ms
64 bytes from 8.8.8.8: icmp_seq=136 ttl=115 time=24.2 ms
64 bytes from 8.8.8.8: icmp_seq=137 ttl=115 time=23.4 ms
64 bytes from 8.8.8.8: icmp_seq=138 ttl=115 time=20.3 ms
64 bytes from 8.8.8.8: icmp_seq=139 ttl=115 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=140 ttl=115 time=4165 ms
64 bytes from 8.8.8.8: icmp_seq=141 ttl=115 time=3200 ms
64 bytes from 8.8.8.8: icmp_seq=142 ttl=115 time=2180 ms
64 bytes from 8.8.8.8: icmp_seq=143 ttl=115 time=1156 ms
64 bytes from 8.8.8.8: icmp_seq=144 ttl=115 time=132 ms
64 bytes from 8.8.8.8: icmp_seq=145 ttl=115 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=146 ttl=115 time=24.8 ms
64 bytes from 8.8.8.8: icmp_seq=147 ttl=115 time=18.10 ms
64 bytes from 8.8.8.8: icmp_seq=148 ttl=115 time=19.1 ms
64 bytes from 8.8.8.8: icmp_seq=149 ttl=115 time=17.7 ms

Ping to router:
Code:
64 bytes from 192.168.1.1: icmp_seq=360 ttl=64 time=0.239 ms
64 bytes from 192.168.1.1: icmp_seq=361 ttl=64 time=0.255 ms
64 bytes from 192.168.1.1: icmp_seq=362 ttl=64 time=0.254 ms
64 bytes from 192.168.1.1: icmp_seq=363 ttl=64 time=0.255 ms
64 bytes from 192.168.1.1: icmp_seq=364 ttl=64 time=0.238 ms
64 bytes from 192.168.1.1: icmp_seq=365 ttl=64 time=2517 ms
64 bytes from 192.168.1.1: icmp_seq=366 ttl=64 time=1493 ms
64 bytes from 192.168.1.1: icmp_seq=367 ttl=64 time=469 ms
64 bytes from 192.168.1.1: icmp_seq=368 ttl=64 time=0.224 ms
64 bytes from 192.168.1.1: icmp_seq=369 ttl=64 time=0.248 ms
64 bytes from 192.168.1.1: icmp_seq=370 ttl=64 time=0.241 ms
64 bytes from 192.168.1.1: icmp_seq=371 ttl=64 time=0.240 ms
64 bytes from 192.168.1.1: icmp_seq=372 ttl=64 time=0.236 ms
64 bytes from 192.168.1.1: icmp_seq=373 ttl=64 time=0.212 ms
64 bytes from 192.168.1.1: icmp_seq=374 ttl=64 time=0.204 ms
64 bytes from 192.168.1.1: icmp_seq=375 ttl=64 time=0.240 ms

If Merlin might be something to try.... I'm using 2 of these routers in a mesh setup. How will the firmware upgrade/replacement be handled? Like normal....just log into the "main" router and tell it to update to Merlin and the secondary (mesh) router will upgrade as well?

Or, should I just start looking for a new router/mesh setup?
 
Been trying to troubleshoot an issue lately and wasn't sure if it's my cable modem, router or switch. What's happening is if I'm talking to somebody on my VoIP line (or using Teams for work) the audio gets distorted every 15 minutes for a few seconds. The problem will also manifest itself in another way.... if I'm watching a high def video stream on my Apple TV, every 15 minutes the quality shifts to SD for a few seconds then right back up to full HD.

I was on a conference call with Teams and opened up some terminals on my Linux box and was doing all these pings at the same time to a 2nd PC in my house, the cable modem, my router and Google DNS. (Everything is hardwired.) When I heard the audio distortion, pings from my workstation to another PC in my house and the cable modem were AOK:

Ping to cable modem:
Code:
64 bytes from 192.168.100.1: icmp_seq=387 ttl=63 time=1.74 ms
64 bytes from 192.168.100.1: icmp_seq=388 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=389 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=390 ttl=63 time=1.59 ms
64 bytes from 192.168.100.1: icmp_seq=391 ttl=63 time=1.74 ms
64 bytes from 192.168.100.1: icmp_seq=392 ttl=63 time=1.72 ms
64 bytes from 192.168.100.1: icmp_seq=393 ttl=63 time=1.73 ms
64 bytes from 192.168.100.1: icmp_seq=394 ttl=63 time=1.70 ms
64 bytes from 192.168.100.1: icmp_seq=395 ttl=63 time=1.83 ms
64 bytes from 192.168.100.1: icmp_seq=396 ttl=63 time=1.63 ms
64 bytes from 192.168.100.1: icmp_seq=397 ttl=63 time=1.71 ms
64 bytes from 192.168.100.1: icmp_seq=398 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=399 ttl=63 time=1.68 ms
64 bytes from 192.168.100.1: icmp_seq=400 ttl=63 time=1.69 ms
64 bytes from 192.168.100.1: icmp_seq=401 ttl=63 time=1.85 ms
64 bytes from 192.168.100.1: icmp_seq=402 ttl=63 time=1.63 ms

Ping to another PC in my house:
Code:
64 bytes from 192.168.1.5: icmp_seq=354 ttl=64 time=0.168 ms
64 bytes from 192.168.1.5: icmp_seq=355 ttl=64 time=0.260 ms
64 bytes from 192.168.1.5: icmp_seq=356 ttl=64 time=0.356 ms
64 bytes from 192.168.1.5: icmp_seq=357 ttl=64 time=0.282 ms
64 bytes from 192.168.1.5: icmp_seq=358 ttl=64 time=0.278 ms
64 bytes from 192.168.1.5: icmp_seq=359 ttl=64 time=0.273 ms
64 bytes from 192.168.1.5: icmp_seq=360 ttl=64 time=0.309 ms
64 bytes from 192.168.1.5: icmp_seq=361 ttl=64 time=0.292 ms
64 bytes from 192.168.1.5: icmp_seq=362 ttl=64 time=0.338 ms
64 bytes from 192.168.1.5: icmp_seq=363 ttl=64 time=0.341 ms
64 bytes from 192.168.1.5: icmp_seq=364 ttl=64 time=0.332 ms
64 bytes from 192.168.1.5: icmp_seq=365 ttl=64 time=0.363 ms
64 bytes from 192.168.1.5: icmp_seq=366 ttl=64 time=0.353 ms
64 bytes from 192.168.1.5: icmp_seq=367 ttl=64 time=0.320 ms

Pings to my router and Google DNS spiked into the 2,000-3,000 range. This leads me to believe my switch isn't the problem nor is my cable modem. It really looks like my router is flaking out on me. I'm using FW v3.0.0.4.385_20633-g593a8ef. Does anyone else agree that the culprit is my router? If so, will switching to Merlin fix things or does it sound like a hardware problem?

Ping to Google DNS:
Code:
64 bytes from 8.8.8.8: icmp_seq=135 ttl=115 time=17.8 ms
64 bytes from 8.8.8.8: icmp_seq=136 ttl=115 time=24.2 ms
64 bytes from 8.8.8.8: icmp_seq=137 ttl=115 time=23.4 ms
64 bytes from 8.8.8.8: icmp_seq=138 ttl=115 time=20.3 ms
64 bytes from 8.8.8.8: icmp_seq=139 ttl=115 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=140 ttl=115 time=4165 ms
64 bytes from 8.8.8.8: icmp_seq=141 ttl=115 time=3200 ms
64 bytes from 8.8.8.8: icmp_seq=142 ttl=115 time=2180 ms
64 bytes from 8.8.8.8: icmp_seq=143 ttl=115 time=1156 ms
64 bytes from 8.8.8.8: icmp_seq=144 ttl=115 time=132 ms
64 bytes from 8.8.8.8: icmp_seq=145 ttl=115 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=146 ttl=115 time=24.8 ms
64 bytes from 8.8.8.8: icmp_seq=147 ttl=115 time=18.10 ms
64 bytes from 8.8.8.8: icmp_seq=148 ttl=115 time=19.1 ms
64 bytes from 8.8.8.8: icmp_seq=149 ttl=115 time=17.7 ms

Ping to router:
Code:
64 bytes from 192.168.1.1: icmp_seq=360 ttl=64 time=0.239 ms
64 bytes from 192.168.1.1: icmp_seq=361 ttl=64 time=0.255 ms
64 bytes from 192.168.1.1: icmp_seq=362 ttl=64 time=0.254 ms
64 bytes from 192.168.1.1: icmp_seq=363 ttl=64 time=0.255 ms
64 bytes from 192.168.1.1: icmp_seq=364 ttl=64 time=0.238 ms
64 bytes from 192.168.1.1: icmp_seq=365 ttl=64 time=2517 ms
64 bytes from 192.168.1.1: icmp_seq=366 ttl=64 time=1493 ms
64 bytes from 192.168.1.1: icmp_seq=367 ttl=64 time=469 ms
64 bytes from 192.168.1.1: icmp_seq=368 ttl=64 time=0.224 ms
64 bytes from 192.168.1.1: icmp_seq=369 ttl=64 time=0.248 ms
64 bytes from 192.168.1.1: icmp_seq=370 ttl=64 time=0.241 ms
64 bytes from 192.168.1.1: icmp_seq=371 ttl=64 time=0.240 ms
64 bytes from 192.168.1.1: icmp_seq=372 ttl=64 time=0.236 ms
64 bytes from 192.168.1.1: icmp_seq=373 ttl=64 time=0.212 ms
64 bytes from 192.168.1.1: icmp_seq=374 ttl=64 time=0.204 ms
64 bytes from 192.168.1.1: icmp_seq=375 ttl=64 time=0.240 ms

If Merlin might be something to try.... I'm using 2 of these routers in a mesh setup. How will the firmware upgrade/replacement be handled? Like normal....just log into the "main" router and tell it to update to Merlin and the secondary (mesh) router will upgrade as well?

Or, should I just start looking for a new router/mesh setup?

One thought... remove the remote node to reset it, configure it from scratch to be your test/replacement router, and then test that... and test also with a PC wired direct to the router. If the problem persists, you could assume it's not your current router, not AiMesh, and not the intervening cabling and switch bits. Could be the ISP... what service type and speeds are you provisioned for... a miserly DSL connection is subject to both interference and bottle necking, but I guess that would not be so periodic.

OE
 
Last edited:
Whether changing firmware will make any difference is anyone's guess, esp. since we don't yet know the cause. But given it happens on a regular basis suggests it some other process that's kicking off every 15 minutes and overwhelming the CPU. Are you using any special features where this might be the case (e.g., an adblocker that's regularly updating itself)?
 
I wonder if the disruption is caused when your WAN IP lease expires and renews. Some ISPs have a short (15 or 30 minute) expiration. You could check by going into the gui and clicking the globe icon (WAN connection status).
 
I wonder if the disruption is caused when your WAN IP lease expires and renews. Some ISPs have a short (15 or 30 minute) expiration. You could check by going into the gui and clicking the globe icon (WAN connection status).

Now that sounds very plausible. And it's a ridiculous practice by such ISPs.
 
Whether changing firmware will make any difference is anyone's guess, esp. since we don't yet know the cause. But given it happens on a regular basis suggests it some other process that's kicking off every 15 minutes and overwhelming the CPU. Are you using any special features where this might be the case (e.g., an adblocker that's regularly updating itself)?

When the problem happens, the CPU/RAM load on the router is completely normal. No spikes anywhere. Not using any special features in it. Other than setting up the mesh stuff years ago, I keep the firmware up to date and everything else is factory default and I don't touch it.
 
One thought... remove the remote node to reset it, configure it from scratch to be your test/replacement router, and then test that... and test also with a PC wired direct to the router. If the problem persists, you could assume it's not your current router, not AiMesh, and not the intervening cabling and switch bits. Could be the ISP... what service type and speeds are you provisioned for... a miserly DSL connection is subject to both interference and bottle necking, but I guess that would not be so periodic.

OE

I have cable internet (400/20). When I get some free time, I'll carry out your tests.
 
I wonder if the disruption is caused when your WAN IP lease expires and renews. Some ISPs have a short (15 or 30 minute) expiration. You could check by going into the gui and clicking the globe icon (WAN connection status).

I checked and it looks like my lease expires every 24 hours.
 
I have cable internet (400/20). When I get some free time, I'll carry out your tests.

That sounds like a reliable ISP. If you bang on it repeatedly with 10 or so wired browser speed tests, do they consistently come back solid? Also try wireless while watching the PC connection status link rate... it should remain steady, not flutter.

Maybe the reset and configuring the node from scratch to test it as router will make a difference. If so, you'll have to repeat same for the current router in case a long overdue reset makes the difference.

OE
 
As the problem is predicable (every 15 minutes) and easy to detect (ping router/google) it should be straight forward to analyse. Turn off all network devices (including switches and nodes) apart from one wired PC and the primary router. Test and then start adding devices back one at a time, waiting 15 minutes between each device.
 
That sounds like a reliable ISP. If you bang on it repeatedly with 10 or so wired browser speed tests, do they consistently come back solid? Also try wireless while watching the PC connection status link rate... it should remain steady, not flutter.

Maybe the reset and configuring the node from scratch to test it as router will make a difference. If so, you'll have to repeat same for the current router in case a long overdue reset makes the difference.

OE

Another experiment I just did..... I started a ping from my PC to the main router and the remote one at the same time and....

Ping to main router:
Code:
64 bytes from 192.168.1.1: icmp_seq=764 ttl=64 time=0.193 ms
64 bytes from 192.168.1.1: icmp_seq=765 ttl=64 time=0.237 ms
64 bytes from 192.168.1.1: icmp_seq=766 ttl=64 time=1314 ms
64 bytes from 192.168.1.1: icmp_seq=767 ttl=64 time=3069 ms
64 bytes from 192.168.1.1: icmp_seq=768 ttl=64 time=2068 ms
64 bytes from 192.168.1.1: icmp_seq=769 ttl=64 time=1053 ms
64 bytes from 192.168.1.1: icmp_seq=770 ttl=64 time=40.10 ms
64 bytes from 192.168.1.1: icmp_seq=771 ttl=64 time=0.262 ms
64 bytes from 192.168.1.1: icmp_seq=772 ttl=64 time=0.226 ms
64 bytes from 192.168.1.1: icmp_seq=773 ttl=64 time=0.236 ms

Ping to remote router:
Code:
64 bytes from 192.168.1.213: icmp_seq=763 ttl=64 time=0.232 ms
64 bytes from 192.168.1.213: icmp_seq=764 ttl=64 time=0.224 ms
64 bytes from 192.168.1.213: icmp_seq=765 ttl=64 time=0.238 ms
64 bytes from 192.168.1.213: icmp_seq=766 ttl=64 time=21.1 ms
64 bytes from 192.168.1.213: icmp_seq=767 ttl=64 time=17.4 ms
64 bytes from 192.168.1.213: icmp_seq=768 ttl=64 time=15.7 ms
64 bytes from 192.168.1.213: icmp_seq=769 ttl=64 time=12.5 ms
64 bytes from 192.168.1.213: icmp_seq=770 ttl=64 time=0.229 ms
64 bytes from 192.168.1.213: icmp_seq=771 ttl=64 time=0.235 ms
64 bytes from 192.168.1.213: icmp_seq=772 ttl=64 time=0.210 ms
64 bytes from 192.168.1.213: icmp_seq=773 ttl=64 time=0.225 ms

Looks like the main router really struggled again while the remote one was able to keep keep ping replies reasonable. Does this help point the finger at the main router? (I still plan on carrying out those tests you mentioned earlier.)

EDIT: Yes, speed tests are always the same.
 
As the problem is predicable (every 15 minutes) and easy to detect (ping router/google) it should be straight forward to analyse. Turn off all network devices (including switches and nodes) apart from one wired PC and the primary router. Test and then start adding devices back one at a time, waiting 15 minutes between each device.

Good idea. So my kids don't freak out about internet problems :) , I'll try and do this bright and early in the morning.
 
So this evening, I swapped the routers. Old setup:

Router A main one
Router B remote mesh node

to new setup

Router B is now the main one
Router A is now the remote mesh node

Did continuous pings to both and wouldn't you know it.... router -=B=- saw a spike of 2,000-3,000ms for a few seconds and router A was in the 20-30ms range for a few seconds then everything went back to normal.

So, from that experiment, it does not look like router A or B are at fault, correct? I'm leaning towards Colin's suggestion of something on my network is going off every 15 minutes and causing this. But when it happens, I don't see any spikes in the router's CPU or RAM and I can't think of anything that has changed recently. Oh, one thing I totally forgot to add to my original post is the router log. Hopefully it holds a clue.

The problems happened around 10:44am, 10:59:am and 11:14am.

Will attach router log file. One thing all those times have in common is the following error AROUND the time it happened:

Code:
Oct  9 10:43:13 syslog: WLCEVENTD wlceventd_proc_event(500): eth2: Auth 30:D9:D9:4C:2F:C3, status: Successful (0)
Oct  9 10:43:13 syslog: WLCEVENTD wlceventd_proc_event(529): eth2: Assoc 30:D9:D9:4C:2F:C3, status: Successful (0)
Oct  9 10:43:17 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 30:D9:D9:4C:2F:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Oct  9 11:00:39 kernel: DROP IN=eth0 OUT= MAC=9c:5c:8e:4a:1e:20:00:01:5c:7c:ec:46:08:00 SRC=IP removed DST=IP removed LEN=40 TOS=0x00 PREC=0x00 TTL=177 ID=60915 PROTO=TCP SPT=46168 DPT=3456 SEQ=4266783885 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Oct  9 11:00:41 syslog: WLCEVENTD wlceventd_proc_event(500): eth2: Auth 30:D9:D9:4C:2F:C3, status: Successful (0)
Oct  9 11:00:41 syslog: WLCEVENTD wlceventd_proc_event(529): eth2: Assoc 30:D9:D9:4C:2F:C3, status: Successful (0)
Oct  9 11:00:42 kernel: DROP IN=eth0 OUT= MAC=9c:5c:8e:4a:1e:20:00:01:5c:7c:ec:46:08:00 SRC=IP removed DST=IP removed LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=59673 PROTO=TCP SPT=40374 DPT=10022 SEQ=667343553 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Oct  9 11:00:44 kernel: DROP IN=eth0 OUT= MAC=9c:5c:8e:4a:1e:20:00:01:5c:7c:ec:46:08:00 SRC=IP removed DST=IP removed LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=62229 PROTO=TCP SPT=57986 DPT=5194 SEQ=2599089057 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Oct  9 11:00:45 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 30:D9:D9:4C:2F:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Oct  9 11:15:16 syslog: WLCEVENTD wlceventd_proc_event(466): eth2: Deauth_ind 4C:ED:FB:7D:3B:E4, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct  9 11:15:16 syslog: WLCEVENTD wlceventd_proc_event(500): eth2: Auth 4C:ED:FB:7D:3B:E4, status: Successful (0)
Oct  9 11:15:16 syslog: WLCEVENTD wlceventd_proc_event(510): eth2: ReAssoc 4C:ED:FB:7D:3B:E4, status: Successful (0)
Oct  9 11:15:28 kernel: DROP IN=eth0 OUT= MAC=9c:5c:8e:4a:1e:20:00:01:5c:7c:ec:46:08:00 SRC=IP removed DST=IP removed LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=54321 PROTO=TCP SPT=46371 DPT=443 SEQ=3790419838 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 
Oct  9 11:15:40 syslog: WLCEVENTD wlceventd_proc_event(500): eth2: Auth 30:D9:D9:4C:2F:C3, status: Successful (0)
Oct  9 11:15:40 syslog: WLCEVENTD wlceventd_proc_event(529): eth2: Assoc 30:D9:D9:4C:2F:C3, status: Successful (0)
Oct  9 11:15:53 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 30:D9:D9:4C:2F:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
 

Attachments

  • router log.txt
    40.9 KB · Views: 142
Is there a reason you are logging all packets in the firewall? That's generally not a good idea.

Presumably you've removed a lot of information from the log file, so what's left only really shows an Apple device connecting every 15 minutes.
 
Is there a reason you are logging all packets in the firewall? That's generally not a good idea.

Presumably you've removed a lot of information from the log file, so what's left only really shows an Apple device connecting every 15 minutes.

It's whatever the factory settings were in the router. I'll try turning logging off and see if that makes a difference. Also, I disconnected the iPhone from the internal network and the problem continues. Along with disabling FW logging, I think I'm going to remove the network cable from the remote mesh router that it uses for back haul. (Just throwing stuff at the wall to see what sticks :)
 
Another update.... turning off the router's firewall logging and removing the cat5 back haul cable didn't fix the problem. Powered the remote node off didn't fix the problem. I found another thread that describes my issue exactly:


....with no resolution. :(

Going to try turning on DoS protection and maybe switching the firmware to Merlin? Since the problem affects either router when it's the "primary" one, maybe it's a firmware bug? Also, if I try Merlin, which firmware do I use for my RT-AC1900P? The one meant for the AC68U? And, if I -do- update to Merlin....since I'm using a mesh network, will the remote node switch to Merlin as well or do remote nodes need handled differently?
 
Have you tried what I previously suggested in post #10?


I found another thread that describes my issue exactly:
....with no resolution. :(
In later posts he said it was caused by him logging accepted packets in the firewall which in turn caused his router's log to rotate every 15 minutes. He could see the router's CPU spiking when the log was rotated.
 
Last edited:
Have you tried what I previously suggested in post #10?

Not yet. Got sidetracked with things this morning and tomorrow morning will be busy too and through the week I'm just to busy to mess with this. Will try next weekend (if I get up early enough because no joke, my kids are all about getting online and playing with their friends and no internet means they're constantly asking "when is the internet coming back up?) :)

Figure I'll disable wireless on the router and wait 15 minutes. If the spike is still there, wireless isn't the problem then I'll power up my VoIP box, wait.... then power up the switch, wait..... etc., etc. Probably take me a few hours to get through all of it.
 
Figure I'll disable wireless on the router and wait 15 minutes. If the spike is still there, wireless isn't the problem then I'll power up my VoIP box, wait.... then power up the switch, wait..... etc., etc. Probably take me a few hours to get through all of it.
As per the update on my previous post, try monitoring the CPU usage on the router (Network Map > System Status > Status) and see if it's spiking in the same way.
 
As per the update on my previous post, try monitoring the CPU usage on the router (Network Map > System Status > Status) and see if it's spiking in the same way.

When this happens, I don't see any corresponding spike in CPU or RAM usage on the router's status page.

Another crazy update.......... now, when I see the lag spikes, I -DO- see the same spikes when pinging the cable modem where as originally, pinging other devices on my network and the cable modem did NOT show the spikes at the same time....only to the router and Google DNS. I think I'm approaching a scorched earth resolution because of how frustrating this is...... might just buy a new cable modem, new router and new switch.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top