Asus RT A68U DNS and connection issues

[RMerlin]

DHCP and DNS are two totally different things. If you get a lot of DHCP renewals over wifi then it means your client is constantly disconnecting and reconnecting - that has nothing to do with DNS. You will need to troubleshoot your wifi network.

 

[ShadowRaven]

As I haven't found an easy way to run something like Wireshark on my phone I couldn't really troubleshoot on this level. Is there a way of making the router log all packets that pass thru it? I've tried Wireshark on 2 wireless Windows 10 devices but wasn't able to replicate my issue, which I'm actually fine with because that'd mean that at least not all devices are affected.
I did manage to capture one of those traffic drops on the router's traffic monitor which looks like this:

This was captured on the wireless 2.4 tab so orange are "Outgoing packets to wireless network".
Another thing I've noticed on the wireless log is that all 2.4 devices but my Xperia Z5 have the "T=STBC" flag. Did MIMO replace STBC? Because the Z5 is capable of MIMO and almost all other devices I own are older so I don't get why that "T" flag is missing here.

 

[ShadowRaven]

I don't want to rush anybody but the warranty on my phone expires in February and should be the phone being faulty here I'd like to return it.
Now what would be the best way to troubleshoot my issue? I guess logging all packet traffic on the network would be necessary but I haven't found a way to do this yet.
Would be nice if you could help me with some advice @RMerlin .

 

[ColinTaylor]

If your problem is the phone constantly disconnecting and reconnecting as Merlin suggested then logging packets won't help because there is nothing to see.

The "DNS" message is misleading because it's just a generic message meaning the device can't connect to the internet. Look at the System Log > Wireless Log and check the Connected time just after the problem occurs to confirm whether or not the device is indeed dropping the wireless connection.

 

[ShadowRaven]

I just tested this and the phone is not disconnecting. The Tx/Rx rates are even high at 144/144Mbps. The device entered powersave mode two times before it issue solved itself after about 20 seconds. The only thing I'm still wondering about is that all but my Z5 have the T=STBC flag. Could this be related maybe?

 

[ColinTaylor]

I just tested this and the phone is not disconnecting. The Tx/Rx rates are even high at 144/144Mbps. The device entered powersave mode two times before it issue solved itself after about 20 seconds.

Sounds like it might be a power save issue then. Try changing the Z5 sleep policy.

The only thing I'm still wondering about is that all but my Z5 have the T=STBC flag. Could this be related maybe?

I have a mixture of devices connected to my 2.4GHz band, some with STBC and some without, none of them experience any problems.

 

[ShadowRaven]

Sounds like it might be a power save issue then. Try changing the Z5 sleep policy.

I've tried that already including a factory reset, WiFi has always been on "always on". Also it's not like the device is having problems reconnecting after waking up from standby, it's more like scrolling thru a tumblr blog and then someone pulls the plug and nothing is loading anymore. As shown in the graph there is 0 transmission going on at that time but the connection itself stays up.

 

[deddc23efb]

As I haven't found an easy way to run something like Wireshark on my phone I couldn't really troubleshoot on this level. Is there a way of making the router log all packets that pass thru it? I've tried Wireshark on 2 wireless Windows 10 devices but wasn't able to replicate my issue, which I'm actually fine with because that'd mean that at least not all devices are affected.
I did manage to capture one of those traffic drops on the router's traffic monitor which looks like this:
View attachment 11602
This was captured on the wireless 2.4 tab so orange are "Outgoing packets to wireless network".
Another thing I've noticed on the wireless log is that all 2.4 devices but my Xperia Z5 have the "T=STBC" flag. Did MIMO replace STBC? Because the Z5 is capable of MIMO and almost all other devices I own are older so I don't get why that "T" flag is missing here.

tcpdump is available in the entware packages. You can run it from CLI on your router.

/dedd

 

[ShadowRaven]

First of all tank you for your suggestion. I was finally able to log the traffic while having the usual problem. As I'm not into this very much I can't tell what exactly is the problem but in this throughput graph it's quite obvious at which period the issue exists.

During this time of about 72 seconds there were 246 ARP (238 Bad TCP; ) requests all exactly like this:

However I still have no idea how to fix this so I'm happy about any suggestions.
This is the link to the whole capture file: https://1drv.ms/u/s!AneCn7LNarRNl0j0AdW8nUMwD4HS

 

[deddc23efb]

First of all tank you for your suggestion. I was finally able to log the traffic while having the usual problem. As I'm not into this very much I can't tell what exactly is the problem but in this throughput graph it's quite obvious at which period the issue exists.
View attachment 11656
During this time of about 72 seconds there were 246 ARP (238 Bad TCP; ) requests all exactly like this:
View attachment 11657

However I still have no idea how to fix this so I'm happy about any suggestions.
This is the link to the whole capture file: https://1drv.ms/u/s!AneCn7LNarRNl0j0AdW8nUMwD4HS

There is a lot going in that pcap. I'm not sure what the problem is, but it looks like problems start happening around packet 1803. A TCP session is initiated by your handset that never gets established even though the receiver sends SYN/ACK. The handset continues to retransmit the SYN and eventually RSTs the session. Eventually at packet 2005, the handset starts ARPing for the router's MAC address fairly aggressively. I would think the large numbers of incoming retransmissions in this period are due to the fact that handset has a messed up (or flushed) ARP table and doesn't know how to send the response. It may not even be getting the packets if it's being dropped off the network.

Why is the handset suddenly ARPing? Is it disconnecting reconnecting a whole bunch at that time? Does this correlate with any ASUS logs (or handset notifications) about wireless drops? The ARPing along with the multicast query make me think these are behaviours at network connectreconnect time - again is the handset dropping on and off the network. (Is your neighbour running their high power microwave when you're doing this testing?)

Sorry I can't help much.

/dedd

 

[ShadowRaven]

I just can't belive in this being the result of any external influence. When I'm doing these tests I'm about 2 meters away from my router. Also I'm living in a detached house so the next router should be more than 20 meters away with at least 2 concrete walls in between. Also as this issue is rather easy to replicate in under half an hour at any time, I doubt that the source of it are interferences like microwaves (that microwave would have to be running a lot).

I'm guessing that I've got some faulty or at least not 100% compatible hardware. I've done multiple factory resets on both devices. If it is a hardwarefault, it'd be nice to know on which device so I can get a replacement. I tending to blame it on the Z5 as I can easily replicate the issue on it while I've only had it once on my Survace Pro.

 

[deddc23efb]

I just can't belive in this being the result of any external influence. When I'm doing these tests I'm about 2 meters away from my router. Also I'm living in a detached house so the next router should be more than 20 meters away with at least 2 concrete walls in between. Also as this issue is rather easy to replicate in under half an hour at any time, I doubt that the source of it are interferences like microwaves (that microwave would have to be running a lot).

I'm guessing that I've got some faulty or at least not 100% compatible hardware. I've done multiple factory resets on both devices. If it is a hardwarefault, it'd be nice to know on which device so I can get a replacement. I tending to blame it on the Z5 as I can easily replicate the issue on it while I've only had it once on my Survace Pro.

If you're seeing it on the Surface too, then it sounds like something central - perhaps the Z5 is more sensitive to the issue.
Now for total guesses.
Could it be an interaction with the ASUS Smart Control shunting the Z5 back and forth from 2.4Ghz to 5Ghz? Does your ASUS router support that and are you using it? Is there another similar wireless feature you're using that could do that? Do you ever see the issue on a hardwired (ethernet) connected device?

 

[ShadowRaven]

If you're seeing it on the Surface too, then it sounds like something central - perhaps the Z5 is more sensitive to the issue.

I'm not completely sure if it was this exact issue I saw on the Surface. It has only happened once so far and it might have been a different issue. But it could of course just as well be as you said, the Z5 being more sensitive to this.

Now for total guesses.
Could it be an interaction with the ASUS Smart Control shunting the Z5 back and forth from 2.4Ghz to 5Ghz? Does your ASUS router support that and are you using it? Is there another similar wireless feature you're using that could do that? Do you ever see the issue on a hardwired (ethernet) connected device?

I don't think the RT-AC87U supports that Smart Control but there is a Roaming assistent which I've never used. Also 2.4 and 5GHz have different names and autoconnect to the 5GHz is disabled on the Z5. The issue only appears on the 2.4GHz band. I've never seen it on 5GHz or Ethernet, that's how I've worked around this so far; by just not using the 2.4GHz band.
Here my 2.4GHz settings (which I've played around with alot but nothing helped):
WPS off; MAC-Filter on whitelist

 

[ShadowRaven]

I've also logged tcp streams on different devices and noticed that I've got incredibly high package loss rates of about 20% on all devices. I consider anything package loss that matches (tcp.analysis.lost_segment || tcp.analysis.retransmission). For this it doesn't matter if I'm 1 or 10 meters from the router, the result is always the same.
Even more interessting is, that the tcp streams differ alot between client and router. On the router, no matter what device or connection (wifi/ethernet), I always get package loss of 15-20%. When I run wireshark on my client at the exact same time I get package loss rates <2%.
Now as this is against all logic in my understanding, how is this possible and is this now normal or is there something seriously wrong with my network?

Edit:
Just found out most of the retransmissions are actually binary douplicates of packages. At some times almost every package is logged twice on the router but the client doesn't recive the duplicates. Not sure if I've got a layer 2 loop/issue, router issue or if that's just normal.
So the acutall loss/retransmission/out-of-order rates on clients are much lower (<5%).

Sadly this all still doesn't explain the issue I'm having

 

[deddc23efb]

I saw this other thread in reference to ASUS devices being hammered by chromecast. I recall your handset issuing a bunch of mDNS requests... is this your probelm?
https://www.snbforums.com/threads/chromecast-might-be-causing-connectivity-issues.43924/

 

[ShadowRaven]

I've noticed the same thing yesterday and was gonna put up something in the IP tables today as you can't really stop the devices from sending them without root access.
There were also alot of UDP TTL 1 packets from Firefox "tickling" the network which I could disable.

 

[ShadowRaven]

After alot of testing I couldn't find a config for the iptables that drops all MDNS packets.

iptables -I INPUT -p udp --dport 5353 -j DROP
iptables -I INPUT -d 224.0.0.251 -j DROP

I've tried these in all INPUT, OUTPUT and FORWARD but none did actually block all traffic.
iptables -L -nvx showed that there were hundrets of packets that matched these rules, but on wireshark I could still see two devices communicating over MDNS. CTF was disabled.

However I finnally updated my Google-Play-Services to the latest beta release and all that MDNS flood is gone.
I didn't have enough time to test if my original issue is gone now but I'll do so later.

 

[ShadowRaven]

Sadly this didn't fix my issue. To me it seems like that the Z5 has some issues receiving packets as it is still sending ARP packets which are answered by the router but the Z5 just keeps sending ARPs just as if it didn't get the answer. I don't think it's a router problem as other devices work flawlessly during the Z5 outage. I'll just send it to Sony to have a look at this, even though I doubt that they'll take the time to reproduce this. If I'll really lucky they'll send me a new one or at least change the wifi module.
This is the latest capture file where the issue comes up right at the beginning: https://1drv.ms/u/s!AneCn7LNarRNl0xwMx6EJi5d6PSW

 

[m4dm0nk3y]

Hi,

I've been on Merlin firmware for 3/4 years on my A68U and have always been very happy.
The device is running as a wireless router, with AiProtection (Parental Control / Time Scheduling, DNSFilter), firewall on, a bunch of IP adresses for my connected devices (wired & wireless), and one OpenVPN server from time to time. Nothing fancy really (no QoS, no IPTV, ...).

Everything has always been fine except the weird symptoms as the ones mentioned in this thread (don't remember when it started, maybe from day 1, I really can't tell anymore), on several devices: android mostly but also linux. It felt a lot to me like something was wrong with DNS. But nothing really stood out in logs. Another hicup I had was that the web interface was often very slow on some devices (android and iOS mostly, not linux). I applied official versions one after another up until 380.69, hoping that my issues would be fixed at some point, but unfortunately, they never did. So I concluded something was off in my network and stopped blaming the A68U or Merlin firmware for it.

And then AiMesh got my attention (I actually have two A68Us, the other one is mostly off, configured as a media bridge). As I had a few hours ahead, I took the plunge on my main router (clean install) hoping my issues would go away in the process. Nope, still same problems. After reading comments about AiMesh not being quite there yet, I switched back to a clean Merlin 380.69. Nope, same issues. Heck, I can give a shot at those alphas / betas out there. I tried all versions available at the time and the miracle happened with one of them: 382.3_alpha1-gb26683d. I don't know how or why, or it may just be a coincidence or something. But this version has been working flawlessly for a whole week. No more connection issues, web interface comes up instantly on all my devices. I also use the "Asus Router" app on android and iOS to grant/deny access to my children's devices. Everything works perfectly and is buttery smooth. For those wondering, there have been 0 changes in my network.

Hope this can help some of you guys out there (and that someone will be able to track down the issue).

tl;dr
I used to have such symptoms on my A68U. All fixed since I applied 382.3_alpha1-gb26683d.

 

[ShadowRaven]

...
tl;dr
I used to have such symptoms on my A68U. All fixed since I applied 382.3_alpha1-gb26683d.

So you had the same issue of no data transmission while the connection stays up?
Also which brand of clients are you using? In my network only Sony devices are affected.
I'm quite sure that this is a compatibility problem of certain WiFi chipsets. But thanks alot for the update, I'll install that firmware and see if it fixes my issue.