RT-AC68U fw384.14_2 Dual WAN catastrophic bug

[Teodor]

Hello Everyone!

After days of tests I draw the conclusion that my old RT-AC68U running Merlin's 384.14_x firmware (earlier versions too, most probable) has a catastrophic bug in handling Dual WAN / Load Balance connections.

Bug reproduction parameters:

• RT-AC68U router
• Merlin's 384.14_x firmware
• Dual WAN connection
• Load Balance dual WAN mode
• Ethernet or Wireless (2.4 or 5GHz) LAN connection
• Router's DHCP default parameters of the LAN connection
• Router's default routing rules (ESSENTIAL!!!)

Bug consequences: after a couple (or so) minutes of correct function, web browser connection requests to a web site times out almost always. In some cases, repeated "refresh page" requests manage to open the targeted web page; some other times connection is impossible. The same behaviour is observed in latest versions of MS Internet Explorer, MS Edge and Chrome, under MS Windows 10 on a desktop system. The same behaviour manifests in Samsung Browser under Android 8 on mobile devices. All the addressed websites were almost instantly accessible through alternative internet connections, not involving the ASUS router.

Bug circumventing:

• make the device obtain a FIXED internal IP address
• set Router -> WAN -> Dual WAN -> Routing rules to route the above address to either Primary WAN or Secondary WAN, both IN and OUT

or alternatively:

• allow router's DHCP to use a maximum range of 32 internal IP addresses to be assigned to the router's client devices
• in the dual WAN routing rules table, insert 32 pairs (IN and OUT) of routing rules for each of the above 32 internal IP addresses, to be routed towards either the Primary WAN or Secondary WAN (hence the 32 IP addresses limit: the table allows a maximum of 64 routing rules). NOTA BENE: using IP addresses ranges (192.168.0.0/29 or similar) in this table, although allowed by the router's entry form, is NOT functional (this may be another bug in the firmware!)

With the hope the above description contains all the necessary data, I look forward for a remedy for these bugs. Any further helping questions are welcome.

 

[martinr]

“....RT-AC68Urunning Merlin's 384.14_x firmware(earlier versions too, mostprobable) has a catastrophic bug....” Which firmware did you come from?

“NOTA BENE: using IP addresses ranges(192.168.0.0/29 or similar.....” I seem to remember that only the CIDR range /24 is acceptable. A feature rather than a bug.

 

[Teodor]

“....RT-AC68Urunning Merlin's 384.14_x firmware(earlier versions too, mostprobable) has a catastrophic bug....” Which firmware did you come from?

Just updated firmware from 384.14, so I know for sure I had connection problems under that version too. I use Merlin's firmware since the router purchase years ago, so I am not sure when the problem appeared for the very first time and I don't want to be a source of misleading information (all the computers I personally use are set with static IP addresses and routed to the fastest WAN, so I had no chance of observing the bug consequences: they became obvious only after lots of complaints from all the other users of my home network, who use the default routing rules on DHCP allocated dynamic IP addresses).

“NOTA BENE: using IP addresses ranges(192.168.0.0/29 or similar.....” I seem to remember that only the CIDR range /24 is acceptable. A feature rather than a bug.

You may be right, I pure and simple don't know. Unfortunatelly, such a rule would render usage of CIDR ranges almost unusable in this case, as /24 covers the whole subnet...

 

[martinr]

Just updated firmware from 384.14, so I know for sure I had connection problems under that version too. I use Merlin's firmware since the router purchase years ago, so I am not sure when the problem appeared for the very first time and I don't want to be a source of misleading information (all the computers I personally use are set with static IP addresses and routed to the fastest WAN, so I had no chance of observing the bug consequences: they became obvious only after lots of complaints from all the other users of my home network, who use the default routing rules on DHCP allocated dynamic IP addresses).


You may be right, I pure and simple don't know. Unfortunatelly, such a rule would render usage of CIDR ranges almost unusable in this case, as /24 covers the whole subnet...

And one thing I forgot: welcome to the forum.

By the way, at some stage you will have done à factory reset AFTER flashing new firmware followed by manually inputting all your settings; do you remember when exactly that was?

 

[Teodor]

And one thing I forgot: welcome to the forum.

By the way, at some stage you will have done à factory reset AFTER flashing new firmware followed by manually inputting all your settings; do you remember when exactly that was?

Thank you for the kind welcome!
I think the last time I did a factory reset was about 18 months ago, when I was trying to find a resolution to another problem (which finally proved NOT to be router-related). I updated the firmware at least 5-6 times since then... And again, due to the particular configuration of the devices I use directly, I couldn't observe the malfunction.
BTW, I forgot to mention another potentially important aspect: connections between ALL the devices in my LAN perform as expected (no delays, no time-outs).
Thank you for your patience!

 

[martinr]

Thank you for the kind welcome!
I think the last time I did a factory reset was about 18 months ago, when I was trying to find a resolution to another problem (which finally proved NOT to be router-related). I updated the firmware at least 5-6 times since then... And again, due to the particular configuration of the devices I use directly, I couldn't observe the malfunction.
BTW, I forgot to mention another potentially important aspect: connections between ALL the devices in my LAN perform as expected (no delays, no time-outs).
Thank you for your patience!

It’s good that you mention the factory reset in terms of firmware versions: it’s more meaningful than than in terms of time. Of course, we don’t know how big any jumps were between versions.

I think it would be a worthwhile exercise to factory reset again, now, and to do so using L&LD’s guide, of which you might not be aware. Follow it to the letter: there’s a good reason and hard-won experience behind every step.

https://www.snbforums.com/threads/n...l-and-manual-configuration.27115/#post-205573

You’ll then be starting from a known good state, which would make troubleshooting easier, and you’ll rule out one very obvious possible cause of your problems. It can only do good. Plus it pays to not let yourself get too rusty on how to do a reset properly.

 

[L&LD]

Agree with @martinr above. Time for another M&M Config and possibly even a Nuclear Reset too.

Please see my signature below for links to useful links to get your router back to a good/known state.

Also, make sure when manually setting up again to not simply change settings because you did so in the past. Things change and firmware more so! Use the suggested defaults in the guides and only change one option at a time to get your network running as you wish, testing thoroughly as you go.

 

[Teodor]

WOW! Your response to a problem I thought to be hardly solvable (if solvable at all) is impressive! And I do thank you very much for that!

I guess it is time for a new factory reset then... I hate setting the router again, but there's no gain without pain, I suppose...

I'll let you know if the factory reset solved the problem or not, but that will be in at least a couple of days from now!
In the meantime, thank you again for your kindness, patience and, of course, knowledgeable advices!