Packets dropped - problems with streaming - RT-N66U 178.15

[col2k3]

Hello, first of all thank you Merlin for your software, dedication and time spent.

I've been using your 178.15 version for some days (I use wireless for a cell phone through 2.4GHZ and I use ethernet for my pc, sitting just a couple of feet next to the router).

Last night while trying to watch some videos from youtube on my pc I noticed that halfway through the video it stopped playing, assumed It was an error, reloaded and tried to play from the part where it stopped working, this went on for a couple of times, didn't pay much attention to it.

Today I went back to doing the same and I noticed the same behaviour; I decided to check the Asus system log and found that packets were being dropped. I tried rebooting the router and also disabling the asus firewall just to check but the problem remained; (This didn't happen anymore when I tried skipping the router and plugging the ethernet directly the cable modem to the pc for some reason)

I'm really sorry since I've been a wired user most of my life and don't have much experience with this so I don't know what kind of information I would need in order to be easier to help me identify the problem or what's causing it, or any additional tests or proccedures I should perform, so please tell me if I need to add/do anything else; for now here's the part of the log that I think could be interesting, let me know if I should remove/add/do anything else:

Sep 6 18:15:23 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=17.172.232.141 DST=201.185.151.110 <1>LEN=77 TOS=0x00 PREC=0x00 TTL=43 ID=48786 DF PROTO=TCP <1>SPT=5223 DPT=52849 SEQ=4132384475 ACK=1164965254 WINDOW=8008 RES=0x00 ACK PSH URGP=0
Sep 6 18:15:23 miniupnpd[606]: received signal 15, good-bye
Sep 6 18:15:23 syslog: SNet version started
Sep 6 18:15:23 miniupnpd[616]: HTTP listening on port 39975
Sep 6 18:15:23 miniupnpd[616]: Listening for NAT-PMP traffic on port 5351
Sep 6 18:15:26 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=199.47.219.149 DST=201.185.151.110 <1>LEN=219 TOS=0x00 PREC=0x00 TTL=52 ID=7064 DF PROTO=TCP <1>SPT=80 DPT=50778 SEQ=1617341534 ACK=2764185150 WINDOW=63784 RES=0x00 ACK PSH URGP=0
Sep 6 18:15:26 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=176.34.110.202 DST=201.185.151.110 <1>LEN=124 TOS=0x00 PREC=0x00 TTL=40 ID=5849 DF PROTO=TCP <1>SPT=5223 DPT=35601 SEQ=932068050 ACK=1872094027 WINDOW=122 RES=0x00 ACK PSH URGP=0 OPT (0101080A223C67600058ED78)
Sep 6 18:15:36 dnsmasq-dhcp[500]: DHCPREQUEST(br0) 192.168.1.13 00:37:6d:fd:93:9c
Sep 6 18:15:36 dnsmasq-dhcp[500]: DHCPACK(br0) 192.168.1.13 00:37:6d:fd:93:9c android-4cbf963ae2ea93f0
Sep 6 18:15:49 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.1.154 DST=201.185.151.110 <1>LEN=81 TOS=0x00 PREC=0x00 TTL=58 ID=42464 DF PROTO=TCP <1>SPT=443 DPT=53474 SEQ=451751504 ACK=211240277 WINDOW=62780 RES=0x00 ACK PSH URGP=0
Sep 6 18:15:50 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.1.154 DST=201.185.151.110 <1>LEN=81 TOS=0x00 PREC=0x00 TTL=58 ID=42465 DF PROTO=TCP <1>SPT=443 DPT=53474 SEQ=451751504 ACK=211240277 WINDOW=62780 RES=0x00 ACK PSH URGP=0
Sep 6 18:16:07 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=50.22.210.136 DST=201.185.151.110 <1>LEN=73 TOS=0x00 PREC=0x00 TTL=50 ID=3786 DF PROTO=TCP <1>SPT=443 DPT=49372 SEQ=2384867304 ACK=159694981 WINDOW=65535 RES=0x00 ACK PSH URGP=0
Sep 6 18:16:07 crond[512]: time disparity of 885555 minutes detected

Sep 6 18:18:07 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=74.125.139.125 DST=201.185.151.110 <1>LEN=66 TOS=0x00 PREC=0x00 TTL=46 ID=47055 PROTO=TCP <1>SPT=5222 DPT=49206 SEQ=3591152779 ACK=1419792720 WINDOW=41266 RES=0x00 ACK PSH URGP=0
Sep 6 18:18:12 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=74.125.139.125 DST=201.185.151.110 <1>LEN=66 TOS=0x00 PREC=0x00 TTL=46 ID=47056 PROTO=TCP <1>SPT=5222 DPT=49206 SEQ=3591152779 ACK=1419792720 WINDOW=41266 RES=0x00 ACK PSH URGP=0
Sep 6 18:18:15 dnsmasq-dhcp[500]: DHCPINFORM(br0) 192.168.1.160 00:1d:7d:01:8a:3a
Sep 6 18:18:15 dnsmasq-dhcp[500]: DHCPACK(br0) 192.168.1.160 00:1d:7d:01:8a:3a Jkmilo-PC
Sep 6 18:18:23 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.34.15 DST=201.185.151.110 <1>LEN=1500 TOS=0x00 PREC=0x00 TTL=60 ID=29895 DF PROTO=TCP <1>SPT=80 DPT=56591 SEQ=14875844 ACK=3466516992 WINDOW=14600 RES=0x00 ACK URGP=0
Sep 6 18:18:33 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.34.15 DST=201.185.151.110 <1>LEN=1500 TOS=0x00 PREC=0x00 TTL=60 ID=29896 DF PROTO=TCP <1>SPT=80 DPT=56591 SEQ=14875844 ACK=3466516992 WINDOW=14600 RES=0x00 ACK URGP=0
Sep 6 18:21:31 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.34.15 DST=201.185.151.110 <1>LEN=1500 TOS=0x00 PREC=0x00 TTL=60 ID=4037 DF PROTO=TCP <1>SPT=80 DPT=56660 SEQ=1699685063 ACK=111056978 WINDOW=14600 RES=0x00 ACK URGP=0
Sep 6 18:21:41 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.34.15 DST=201.185.151.110 <1>LEN=1500 TOS=0x00 PREC=0x00 TTL=60 ID=4038 DF PROTO=TCP <1>SPT=80 DPT=56660 SEQ=1699685063 ACK=111056978 WINDOW=14600 RES=0x00 ACK URGP=0
Sep 6 18:21:50 dnsmasq-dhcp[500]: DHCPRELEASE(br0) 192.168.1.160 00:1d:7d:01:8a:3a
Sep 6 18:21:51 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=190.248.34.15 DST=201.185.151.110 <1>LEN=1500 TOS=0x00 PREC=0x00 TTL=60 ID=4039 DF PROTO=TCP <1>SPT=80 DPT=56660 SEQ=1699685063 ACK=111056978 WINDOW=14600 RES=0x00 ACK URGP=0
Sep 6 18:21:51 dnsmasq-dhcp[500]: DHCPDISCOVER(br0) 192.168.1.160 00:1d:7d:01:8a:3a
Sep 6 18:21:51 dnsmasq-dhcp[500]: DHCPOFFER(br0) 192.168.1.160 00:1d:7d:01:8a:3a
Sep 6 18:21:51 dnsmasq-dhcp[500]: DHCPREQUEST(br0) 192.168.1.160 00:1d:7d:01:8a:3a
Sep 6 18:21:51 dnsmasq-dhcp[500]: DHCPACK(br0) 192.168.1.160 00:1d:7d:01:8a:3a Jkmilo-PC
Sep 6 18:23:06 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=99.13.117.177 DST=201.185.151.110 <1>LEN=99 TOS=0x00 PREC=0x00 TTL=111 ID=7077 PROTO=UDP <1>SPT=16423 DPT=17546 LEN=79
Sep 6 18:24:48 kernel: DROP <4>DROPIN=eth0 OUT= MAC=10:bf:48:d3:fa:a0:00:24:c4:27:67:da:08:00 <1>SRC=24.41.145.162 DST=201.185.151.110 <1>LEN=95 TOS=0x00 PREC=0x00 TTL=114 ID=8740 PROTO=UDP <1>SPT=45835 DPT=17546 LEN=75

 

[RMerlin]

Those DROP log entries are packets being dropped by your firewall from outsiders trying to connect to your network - this has nothing to do with your wireless or the stability of your connection.

If you have wireless or Internet stability issues you will have to start by looking at the usual: channel, interference, etc...

 

[col2k3]

Those DROP log entries are packets being dropped by your firewall from outsiders trying to connect to your network - this has nothing to do with your wireless or the stability of your connection.

If you have wireless or Internet stability issues you will have to start by looking at the usual: channel, interference, etc...

Oh, thank you so much, sorry for the misunderstanding; I assumed they were related to the internet stability since they showed up when I was having issues with youtube losing connection and forcing me to reload videos from a specific time point.
There's no channel interference, I'm about the only one on my neighborhood using channel 1, and besides the problem happened while using ethernet out of the router too.

Any ideas of what else could I check that could be causing this?

 

[RMerlin]

Next time check the traffic monitor on the router to see if the traffic is capped or actually drops.

Also if you aren't, make sure you use your ISP's DNS and not third party ones like OpenDNS or Google. Using your ISP's DNS will ensure that you get access to the closest Youtube server, which might be different from the one returned by a public DNS.

 

[col2k3]

Next time check the traffic monitor on the router to see if the traffic is capped or actually drops.

Also if you aren't, make sure you use your ISP's DNS and not third party ones like OpenDNS or Google. Using your ISP's DNS will ensure that you get access to the closest Youtube server, which might be different from the one returned by a public DNS.

Happened again and I was browsing the traffic monitor in real time, here's what happened:
Loaded youtube video, I could see the grey progress bar moving at normal speed then when it was around halfway it appeared like everything had loaded instantly; checked the traffic monitor and indicated that traffic stopped abruptly (check pic) and when the youtube playback reached that moment (where it stopped loading normally) playback would stop; it's like the connection drops for a milisecond, I've noticed it with online games too

"Connect to DNS Server automatically" is set to yes, so I assume it's getting the DNS from my ISP.

Any ideas, or any other info/data I could gather/provide ? Sorry for the inconvience.

 

[RMerlin]

I doubt it's an issue with the router itself, since you are connecting your PC using Ethernet. One thing to check is that the Ethernet cable you are using is marked as either Cat 5e or Cat 6 along its length - this is required for stable gigabit connections between the router and the PC.

One way to see if the issue is between the PC and the router is to do a constant ping stream while playing a video. Open two command prompts on your PC, and have each of them run these commands:

ping -n 999 192.168.1.1
ping -n 999 www.google.com

(assuming your router is still on the default 192.168.1.1 IP)

Then start playing a video. During playback keep an eye on both window. If one of them starts giving you time outs, then you will know if the issue is local (between PC and router) or beyond that (somewhere between the router, modem and your ISP).

 

[col2k3]

I doubt it's an issue with the router itself, since you are connecting your PC using Ethernet. One thing to check is that the Ethernet cable you are using is marked as either Cat 5e or Cat 6 along its length - this is required for stable gigabit connections between the router and the PC.

One way to see if the issue is between the PC and the router is to do a constant ping stream while playing a video. Open two command prompts on your PC, and have each of them run these commands:

ping -n 999 192.168.1.1
ping -n 999 www.google.com

(assuming your router is still on the default 192.168.1.1 IP)

Then start playing a video. During playback keep an eye on both window. If one of them starts giving you time outs, then you will know if the issue is local (between PC and router) or beyond that (somewhere between the router, modem and your ISP).

Thank you so much for the feedback, I do know it's strange that it would give me trouble since I'm using ethernet, but the problem dissapears when I skip the router and go from cable modem to pc.



I just did the ping stream watching both windows while playing Steve Kardynal's Call Me Maybe. The one tracing google gave me constant timeouts (even after the video stopped playing) at least once every 15 seconds or so but sometimes around 4. The one directed to my address gave me none.




HUGE EDIT: Alright, it seems like your instincts were right . Here's what I did, I had tested for an entire day no router, modem straight to pc, and internet apparently worked without issues, youtube and online gaming gave me no problems, but that was more of an eye test, so I just unplugged the router again, hooked modem straight to pc and did a ping stream to google.com. And albeit it didn't give me as many timeouts as when using the router, it still did, and this time a youtube video fracked up too.

Wish I had known about that command before , it appears the problem is with my isp, right????? so I'll call and bitch at them on monday, thanks for the help, sorry for the time loss.

 

[RMerlin]

Try a prolonged power cycle of your modem (keep it turned off for 5-10 mins), then plug it back in. This will ensure that it will re-negotiate its channels with the ISP. If it still doesn't help, contact your ISP so they can have a look at the signal. Could be the modem, wiring, or something at their end.