[BUG] 380.57 - Latency issues and packet drop WiFi to WiFi only

[Wilk]

Hello,

I encountered a strange problem using Asuswrt-Merlin 380.57 on a AC66U and N66U. I am experiencing connectivity issues between WiFi devices only.
So this is what happens when I ping on both routers, 2 Ghz or 5 Ghz WiFi:

Wireless Device -> Router IP: perfectly fine ✓
Wireless Device -> Device connected to router on Ethernet port (both 100M and 1000M): perfectly fine ✓
Wireless Device -> Internet IP: perfectly fine ✓
Router -> Wireless Device: perfectly fine ✓
...
Wireless Device -> Wireless Devices: Varying ping up to a few seconds including packet loss.
Results are: Unstable/slow connections

I am able to reproduce this on both routers using the following wireless devices which have been available:

Macbook Air 11" OSX 10.11.3, Macbook Air 13" OSX 10.11.3, Sony Xperia Z compact, iPhone 5S, Fire TV Stick.

Other Devices on the network:

ISP Router in bridge mode, Synology DS414 NAS, Nintendo Wii, Playstation 4, An Intel-chipset based PC, some HP Laserprinter, Zotac Z-Box.

What I already tried:

1) To preclude specific OS related problems I cross-pinged all devices. The result was always as above mentioned.

2) Turning the router off and on again

3) Disabling all network devices except for the two wireless ones to test

3) Resetting the router configuration

4) Reflashing the router and resetting the configuration

5) Changing WiFi channels (connection quality)

6) Changing NAT mode (screwed up NAT)

7) Disabling the firewall (maybe some routing thing?)

This has to be some kind of internal problem - so far, it cannot related to the devices themselves or quality of the wireless network.

I don't know whether the problem has been introduced recently or whether it has been existent all the time.
Could someone help me to narrow the cause for this down?
Is anyone else able to reproduce this?

 

[L&LD]

Try also new ssid's (or 'forget' and re-associate each and every device (or at least the ones you're testing).

You can use the same password, btw, if you decide (recommended) to use new ssid's on the router.

 

[Wilk]

Try also new ssid's (or 'forget' and re-associate each and every device (or at least the ones you're testing).

You can use the same password, btw, if you decide (recommended) to use new ssid's on the router.

Thank you for your reply. By resetting and reflashing the routers I have already changed the SSIDs. Still it seems to be a problem with the way the router directs the traffic from wireless device to wireless device. I don't know whether this is done within the radio chip or by the OS on the device and which steps the packets take until they get delivered. I do know how networking works, especially on unix-like systems - but wireless routers and their software a far beyond my knowledge. Digging into the source code and doing some debugging might help, but is usually a painful experience which I am trying to avoid (and also bricking my router).

Are you able to reproduce this problem on your device (if you own an ASUS)?

 

[jeff288]

N66U, 380.58alpha here and no packet loss with ~30ms ping to my other client, so no issue here. You've tried dis/enabling CTF (cut through forwarding)? Have you tried disabling all other wifi devices but a few so you have less interference? Do you have any wireless keyboards or other wireless devices that can interfere with the signal? Though you did try with 2.4ghz and 5ghz, I guess so I'm at a loss, then again I'm not very experience in wireless. Strange issue.

 

[A.D.]

I encountered a strange problem using Asuswrt-Merlin 380.57 on a AC66U and N66U. I am experiencing connectivity issues between WiFi devices only

I learned that the ASUS code base used for 380.57 may not fully support (at least) the RT-AC66U. It looks like ASUS developed the 380 for newer models first and may / will add backwards compatibility for other models later. The indication for this is that ASUS did not publish a 380 based firmware for the RT-AC66U yet. In my case, I noticed that the asuswrt-merlin 380.57 does not drive the LEDs of my RT-AC66U (HW B0) correctly.

This was enough of a reason for me to revert to asuswrt-merlin 378.56.2. This matches the version of the latest official ASUS firmware for the device, and it drives the LEDs correctly. I also just made a quick WiFi <-> WiFi iperf test which showed no anomalies.

I have decided to only use modified firmware which is based on ASUS code base which ASUS officially provides for the respecitve model.

 

[A.D.]

N66U, 380.58alpha here and no packet loss with ~30ms ping to my other client, so no issue here.

You're running 380 alpha and @Wilk runs release. In addition, e.g. at least two hardware variants of the RT-AC66U exist, with the more recent B0 providing at least one feature which the previous hardware did not support, such that the firmware must present different settings and drive the hardware differently. Therefore, sharing your experience is valuable, but conclusions should be drawn with caution.

I'll throw in my observation of a different (dysfunctional) traffic signalling behaviour of the RT-AC66U LEDs with the 380 merlin release as compared to the 378 official and merlin (functional), while LED initialisation itself looks okay with any of these.

Of course it's wild guessing, but I'm beginning to suspect that the 380 code base -- which was developed with newer devices in focus, -- may have some parts which are not well suited for the resource situation of the single core 600 MHz CPU based 66 devices (e.g. interrupt frequency / latencies).

 

[jeff288]

You're running 380 alpha and @Wilk runs release. In addition, e.g. at least two hardware variants of the RT-AC66U exist, with the more recent B0 providing at least one feature which the previous hardware did not support, such that the firmware must present different settings and drive the hardware differently. Therefore, sharing your experience is valuable, but conclusions should be drawn with caution.

I'll throw in my observation of a different (dysfunctional) traffic signalling behaviour of the RT-AC66U LEDs with the 380 merlin release as compared to the 378 official and merlin (functional), while LED initialisation itself looks okay with any of these.

Of course it's wild guessing, but I'm beginning to suspect that the 380 code base -- which was developed with newer devices in focus, -- may have some parts which are not well suited for the resource situation of the single core 600 MHz CPU based 66 devices (e.g. interrupt frequency / latencies).

As I understand it, it may be known already but to those who aren't aware, the base of the 380x firmware for the 66 devices are 37x binary blobs while Merlin has implemented all the compatible open source code from 380x. But even with 380.57 release, I had no issues wireless issues but of course it wouldn't hurt to downgrade to try to resolve it.

 

[Wilk]

Hello and thank you for your input.

@jeff288: Yes, I have already tried to play around with the CTF-option

I will try to apply a pre 380 release in order to confirm or refute a relation to 380-based firmware. I will update this thread once I reflashed the devices.