What's new
  • 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!

TheMegaMan

Occasional Visitor
I hope someone can point me at a few things what might help me with some network stability issues I seem to be having.

I'm running Asuswrt-Merln version 386.3_2 on the router.

Firstly, DNS.

I've been getting a few issues with web pages taking a long time to load, or failing completely. This used to be OK, but recently I often get an error page stating 'DNS_PROBE_STARTED', which then gets replaced with the page I was trying to see. Once I'm on a web site, pages load pretty quickly. So I think the problem is that DNS requests are taking are unpredictably slow, and sometimes timing out. The problem seems to be reduced if I manually configure the PC to use remote DNS servers (namely 8.8.8.8) directly, rather than going through the router.

Are there any known DNS issues with Asuswrt-Merlin on this router?

If not, what are sensible DNS settings to choose on the 'WAN - Internet Connection' tab, namely DNS rebind protection, DNSSEC support, etc?

The second issue is that my Sky box frequently fails to connect to the network. Probably related to this, I'm running a Fingbox on my network which often reports that DHCP isn't healthy. So...are there any known DHCP issues with the firmware/router?

I should probably also confess that my router is actually sitting behind another router/DSL modem supplied my by ISP so I have 2 levels of NAT, but the other router is configured such that all traffic is forwarded to the ASUS, which is set as an 'exposed host' (DMZ), and DHCP is turned off. This configuration seems to be generally working well (and I can check DSL line performance, etc), and I'm not sure it will have any effect on the DNS/DHCP issues I'm having.

Cheers!
Adam
 
Welcome to the forums @TheMegaMan.

You need to simplify and streamline your network to do proper troubleshooting.

In my experience, DMZ isn't the same experience as having the ISP router/modem in full Bridge mode.

To begin with where you are now,
after flashing to RMerlin firmware, have you fully reset the router to factory defaults?
Did you then perform a minimal and manual configuration of the router?
Without using any saved backup config files?
And without 'blindly' using old scripts, features, or options whose base functions may have changed with the latest changes RMerlin firmware brings?

Have you read the changelogs and adapted your customizations as necessary?

The following link (and the links within) may be helpful to get your router/network stable.

Fully Reset / Best Practice Setup / More
 
There are no known issues with DNS in Asuswrt-Merlin. That said, it is of course possible to mis-configure the DNS settings, but the default settings are normally the best: WAN DNS set to automatic and LAN/DHCP DNS left blank so that clients use the router's DNS server.

However, you said that you are behind another router. So it's likely that your Asus is using your DSL router as it upstream DNS server. You can check this by going to Network Map, clicking on the "Internet" globe and looking at the Internet status information.

If your router is using the DSL router as its upstream DNS server I suggest that you override that by setting the WAN DNS servers manually to 9.9.9.9 and 1.1.1.1 (or your preferred public server addresses).
 
Welcome to the forums @TheMegaMan.

You need to simplify and streamline your network to do proper troubleshooting.

In my experience, DMZ isn't the same experience as having the ISP router/modem in full Bridge mode.

To begin with where you are now,
after flashing to RMerlin firmware, have you fully reset the router to factory defaults?
Did you then perform a minimal and manual configuration of the router?
Without using any saved backup config files?
And without 'blindly' using old scripts, features, or options whose base functions may have changed with the latest changes RMerlin firmware brings?

Have you read the changelogs and adapted your customizations as necessary?

The following link (and the links within) may be helpful to get your router/network stable.

Fully Reset / Best Practice Setup / More

Thanks for the replies!

Yeah, I realised my setup isn't particularly 'clean', but it had been working well until this problem crept it. And as the DNS issue is not an obvious failure, I'm not quite sure exactly when it started and whether it was a firmware change that caused it, or something else.

My ISP initially told me that their router/modem (a FRITZ!Box 7530) doesn't offer a bridge mode, but it seems it can be configured in 'PPPoE Passthrough' mode, which seems effectively be a bridge mode. But I'd already configured the routers with nested NATs, so was reluctant to change it as it was working OK, and I was concerned that I'd lose the useful DSL line stats I get from the FRITZ!Box GUI.

Hence me asking whether there were any known issues before I spend a lot of time making big changes, and risking messing everything up completely! :eek:

Yes, I flashed RMerlin as soon as I got the Asus router (I had been running Merlin on a RT-AC68U for several years and liked the system, but that router was becoming unreliable with temperature), and it was set up from scratch, and not restored from a backup config. I've not used any scripts, and don't believe any updated features would affect my setup....but that's kind-of why I was asking whether there were any known issues.

It seems I may well end up doing a full reset. I was hoping there was an easier route to fine-tune it before investing quite that much time in it.
 
There are no known issues with DNS in Asuswrt-Merlin. That said, it is of course possible to mis-configure the DNS settings, but the default settings are normally the best: WAN DNS set to automatic and LAN/DHCP DNS left blank so that clients use the router's DNS server.

However, you said that you are behind another router. So it's likely that your Asus is using your DSL router as it upstream DNS server. You can check this by going to Network Map, clicking on the "Internet" globe and looking at the Internet status information.

If your router is using the DSL router as its upstream DNS server I suggest that you override that by setting the WAN DNS servers manually to 9.9.9.9 and 1.1.1.1 (or your preferred public server addresses).

OK, I guess not quite what I was hoping to hear, but it means it's my problem to solve! At least I now know.

I had been letting DHCP clients point to the router, but I'd manually configured the Asus router to point to Google and my ISP's DNS servers (8.8.8.8 and 212.23.6.100). The 'Internet Status' field shows this, so it shouldn't be bouncing DNS off the ISP's router.

So I think I'd already got it set up to avoid this issue, but clearly something else is wrong somewhere. :confused:
 
There is no difference between using current stock firmware (even for years) and then flashing RMerlin firmware, or flashing RMerlin firmware the moment you power up the router.

A full reset is suggested for optimal (performance, security, stability) results.
 
Check the router's system log when you experience the problem just in case the router is crashing (a common problem with that model).

I had been letting DHCP clients point to the router, but I'd manually configured the Asus router to point to Google and my ISP's DNS servers (8.8.8.8 and 212.23.6.100). The 'Internet Status' field shows this, so it shouldn't be bouncing DNS off the ISP's router.
The way the router's DNS server works with its upstream servers is not obvious. Suffice it to say even though you are specifying two servers it will only be querying one at a time. So as an experiment remove the second WAN DNS server and just use 8.8.8.8.
 
There is no difference between using current stock firmware (even for years) and then flashing RMerlin firmware, or flashing RMerlin firmware the moment you power up the router.

A full reset is suggested for optimal (performance, security, stability) results.

How often are you suggesting a full reset needs to be performed?

I would argue there's a fairly significant difference given the older version of stock firmware when delivered, versus the latest RMerlin firmware available when I set the router up. My point was that I've not needed to update RMerlin that often since I did the clean setup and I don't recall seeing any comments in the release notes about doing a full reset on recent updates. I'm aware that this was advised on updates from some older versions.

It does seem the the ability to save a configuration file is rather redundant if it should never be used to restore the router configuration. However, I didn't have a pre-RMerlin configuration to restore, so it was effectively a full reset when I plugged it in, no?
 
Check the router's system log when you experience the problem just in case the router is crashing (a common problem with that model).


The way the router's DNS server works with its upstream servers is not obvious. Suffice it to say even though you are specifying two servers it will only be querying one at a time. So as an experiment remove the second WAN DNS server and just use 8.8.8.8.

I'd given the system a quick look, but hadn't seen anything obvious. What sort of thing would I see if the router *was* crashing? I wasn't aware of this being a problem with this router, so is exactly the reason I asked the questions. Does the router recover after these crashes, or does it need a restart/reboot?

Yeah, I had been using 8.8.8.8 as the primary DNS server for some time before the problem occurred (with 4.4.4.4 as the secondary server), but I swapped to using my ISP's server as the primary entry, thinking that maybe Google was getting overloaded and slow. But it didn't make any difference, and I restored Google to the primary server and my ISP as secondary. I assumed having a secondary server was likely to help if the primary server was slow, but I'm finding the same problem with any combination of two from Google's two servers (8.8.8.8 and 8.8.4.4), Cloudflare, my ISP, etc. I'll try a single server to see whether that makes any difference. Thanks for the suggestion.
 
I'd given the system a quick look, but hadn't seen anything obvious. What sort of thing would I see if the router *was* crashing? I wasn't aware of this being a problem with this router, so is exactly the reason I asked the questions. Does the router recover after these crashes, or does it need a restart/reboot?
It's something that effects some people but not others. The exact cause is still not fully understood. If you are suffering from this problem it's very obvious from looking at the system log. Either there is a process crash followed by a complete system reboot, or a process crash which produces lots of crash dump messages in the log but it carries on working.
 
How often are you suggesting a full reset needs to be performed?
As needed. Beginning with the original flashing of RMerlin firmware on the router.


I would argue there's a fairly significant difference given the older version of stock firmware when delivered, versus the latest RMerlin firmware available when I set the router up. My point was that I've not needed to update RMerlin that often since I did the clean setup and I don't recall seeing any comments in the release notes about doing a full reset on recent updates. I'm aware that this was advised on updates from some older versions.

No, not necessarily.


It does seem the the ability to save a configuration file is rather redundant if it should never be used to restore the router configuration.
It should be used to to restore to the exact same router and same firmware it was created on.

However, I didn't have a pre-RMerlin configuration to restore, so it was effectively a full reset when I plugged it in, no?

No, it is not.
 
It's something that effects some people but not others. The exact cause is still not fully understood. If you are suffering from this problem it's very obvious from looking at the system log. Either there is a process crash followed by a complete system reboot, or a process crash which produces lots of crash dump messages in the log but it carries on working.

OK, nothing referencing crash dumps in my logfile. It looks pretty neutral, mostly just reports of MAC authentications and DHCP renewals. There are lots of 'callbacks suppressed' messages, but no indications of anything sinister. So hopefully this isn't the issue I'm getting.
 
As needed. Beginning with the original flashing of RMerlin firmware on the router.

Such as after a 'significant' firmware update, when the release notes state you should? If that's all, then I've followed that.

TheMegaMan said:
> However, I didn't have a pre-RMerlin configuration to restore, so it was effectively a full reset when I plugged it in, no?

No, it is not.

Why not? I've not attempted to upload any configuration files that would set anything illegally, so all configuration options were set through the GUI.

Anyway, this is distracting from the issue. If the router needs me to spend an hour or so manually going through all the config pages and resetting everything (including quite a few Manual IP Assignments) from scratch every few weeks when I do firmware updates, then I've clearly bought the wrong router (or shouldn't be using RMerlin). I like the features and capabilities, but I do need it to 'just work' and not need this much time to keep it running.
 
You're misunderstanding everything I've said (obviously).

Did you read the link in post 2 at all?
 
You're misunderstanding everything I've said (obviously).

Did you read the link in post 2 at all?

A fair point. I did follow the first link, but as it seemed to be a set of nested links to other posts, I admit I didn't follow everything. I have now read around a bit more, and see where you're coming from. Apologies for not appreciating your attempt to share your expertise and experiences with me.

I was aware of the basic guidance on when a full reset was essential, but I was obviously looking for other options first, to avoid having to go through the process if it wasn't absolutely necessary. But I guess I really should just bite the bullet and get on with it. My original questions have been answered - there are no known DNS or DHCP issues with the RT-AC86U, so I need to fix the problem myself.

I just hope I won't need to repeat this very often. Kind of makes me reluctant to do any more firmware updates, to avoid risking going through it all again.
 
What we put into 'anything' is what we get out of it.

Not doing updates as they're available is not an option. Security first. Convenience last.

My experience with my and my customers routers is that if they are properly reset and configured at the beginning (of ownership) then they can be 'dirty' upgraded for a long time without experiencing issues.

For example, my two RT-AX86U's have not been reset again since they were when bought at the beginning of the year. :)

Customers that like to fiddle with the options and features don't seem to last that long, without needing a full reset to get back to a good/known state again.
 
I just hope I won't need to repeat this very often. Kind of makes me reluctant to do any more firmware updates, to avoid risking going through it all again.
Before you do any update make sure you take a backup of your current settings and JFFS partition as well as downloading a copy of your current firmware. Then if things go pear shaped it's trivial to go back to where you were before.
 
An update...

So I configured the Fritz!Box router to allow the Asus router to make it's own PPPoE connection to my ISP, and knobbled the Fritz!Box login details so it couldn't connect itself. That seems to be the closest thing to a bridge mode that the Fritz!Box supports. But this didn't directly improve anything.

So I (reluctantly) followed @L&LD 's advice, and did a full factory reset and clean reconfiguration.

And I now seem to have quick DNS responses back, and I've not yet observed any DHCP issues reported from Fing...so it seems that has indeed solved the problem.

I'm still a bit disappointed that this was necessary. Seems a shame that the route seems to have got itself into a state where it wasn't working efficiently...but I guess that's the cost of a very versatile and configurable complex device.

So big thanks to @L&LD for directing me to take it on the chin and fix the problem! :)
 

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