What's new

ASUS RT-N66U Firmware version 3.0.0.4.376.3657

  • 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!

You started the problem description as follows:

I'm having some problems with this firmware on 5ghz. Sometimes data transfer stops for a few minutes without losing connection. When this happens nothing appears on the log.

Done reset after upgrade and introduced manually all settings.

Any suggestion?

Now you come up with this:

Seems like my network problems occurs in proximity with the following events in log
Dec 31 17:45:43 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
...
This entries appears every 24h approximately and it seems that the problems occurs nearby before and after.

Did the DNS messages start after the suggested actions or did you overlook those initially?

See this thread:
http://forums.smallnetbuilder.com/showthread.php?t=19304
 
I overlooked them because their timing didn't match perfectly. After that I realized that there was a pattern.
A few hours ago 2.4 GHz band stopped transmitting ssid and I lost connections on all computers. Wireless log showed computers as connected and no event in general log. After that decided to do the suggested clear NVRAM, did a reset and reconfigured everything manually. I'll come back to share result. Thanks.
 
After the startup entries, the General Log should normally stay quite empty.
With firmware 3657 all I see (just before every hour) is a log entry "ntp: start NTP update".
The rare other entries make sense to me depending on what goes on with the network or Internet connection.
In other words: any General Log entry should get your attention.
 
The entry "Maximum number of concurrent DNS queries reached"continues to appear approximately every 24h. Any suggestion on how to discover the reason for it? Can it be WAN related or only LAN related?
 
The entry "Maximum number of concurrent DNS queries reached"continues to appear approximately every 24h. Any suggestion on how to discover the reason for it? Can it be WAN related or only LAN related?

If you can recreate this on a Merlin build, you could add the 'log-queries' option to the dnsmasq.conf with a dnsmasq.conf.add file. It will generate a ton of info, including the ip that is generating each dns query.
 
The entry "Maximum number of concurrent DNS queries reached"continues to appear approximately every 24h. Any suggestion on how to discover the reason for it? Can it be WAN related or only LAN related?

You have something running on that computer that generates an insane amount of DNS lookups. First thing I would check is for any torrent client on that computer - make sure it's not configured to try to resolve all connected peers.

It could also potentially be a malware running on that computer that generates a lot of DNS lookups.
 
3.0.0.4.376.3657 Media Server not Auto-scanning when adding new files

Tried on 2 different RT-N66U routers but could only get it to scan when clicking Apply on Media Server settings page and not automatically when adding new files to the ext. 2TB HDD. Tried the same with an USB stick connected to the router USB port.
This used to work in the past. FAT32 formatted 2TB HDD, not having any other issues with it so I highly doubt it's a formatting issue (EXT3, NTFS,FAT32...)...
Anybody?
 
After the startup entries, the General Log should normally stay quite empty.
With firmware 3657 all I see (just before every hour) is a log entry "ntp: start NTP update".
The rare other entries make sense to me depending on what goes on with the network or Internet connection.
In other words: any General Log entry should get your attention.

You see almost nothing in the logs on stock because:

Asus firmware runs log_level 6

Merlin runs log_level 7

Whenever I run stock (testing) I change log_level to 7 as otherwise there is no logging of dhcp requests and some other things.
 
You have something running on that computer that generates an insane amount of DNS lookups. First thing I would check is for any torrent client on that computer - make sure it's not configured to try to resolve all connected peers.

It could also potentially be a malware running on that computer that generates a lot of DNS lookups.
There's no torrent client running and I've searched for malware and found nothing.
I'm now turning off devices one by one to find the cause but it may take a while because the problem only arises once a day.
 
Tried on 2 different RT-N66U routers but could only get it to scan when clicking Apply on Media Server settings page and not automatically when adding new files to the ext. 2TB HDD. Tried the same with an USB stick connected to the router USB port.
This used to work in the past. FAT32 formatted 2TB HDD, not having any other issues with it so I highly doubt it's a formatting issue (EXT3, NTFS,FAT32...#...
Anybody?

This is a known issue with stock ASUS firmware.....Merlin's firmware provides a fix. 376.48 Beta 2 or later.

- FIXED: minidlna is once again able to use inotify for updates.
A temporary workaround has been implemented where
minidlna will be staticly linked with a threadsafe
build of sqlite3, while BWDPI will continue to use
the shared non-threadsafe library. #Asus bug)
 
This is a known issue with stock ASUS firmware.....Merlin's firmware provides a fix. 376.48 Beta 2 or later.

- FIXED: minidlna is once again able to use inotify for updates.
A temporary workaround has been implemented where
minidlna will be staticly linked with a threadsafe
build of sqlite3, while BWDPI will continue to use
the shared non-threadsafe library. #Asus bug)

Thanks!
I'm not a major geek so I'm a bit worried I'll mess up things by using non Asus firmware...
 
This is a known issue with stock ASUS firmware.....Merlin's firmware provides a fix. 376.48 Beta 2 or later.

- FIXED: minidlna is once again able to use inotify for updates.
A temporary workaround has been implemented where
minidlna will be staticly linked with a threadsafe
build of sqlite3, while BWDPI will continue to use
the shared non-threadsafe library. #Asus bug)

BTW, Asus fixed it in the recent 378_37xx releases, by re-enabling safe-threading support in sqlite. I'd expect the fix to trickle down to the N66 once they release a new firmware based on 378_xxxx.
 
Seems like my network problems occurs in proximity with the following events in log
Dec 31 17:45:43 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:45:56 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:02 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:12 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:20 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:30 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
This entries appears every 24h approximately and it seems that the problems occurs nearby before and after.
Noticed today that data transfer stopped once again for a few minutes and no entry appeared on log.
 
Found the following events network related in Windows 8.1 machine:

Name resolution for the name wpad timed out after none of the configured DNS servers responded.

TCP/IP has chosen to restrict the congestion window for several connections due to a network condition. This could be related to a problem in the TCP global or supplemental configuration and will cause degraded throughput.

Does this help?
 
Found the following events network related in Windows 8.1 machine:

Name resolution for the name wpad timed out after none of the configured DNS servers responded.

TCP/IP has chosen to restrict the congestion window for several connections due to a network condition. This could be related to a problem in the TCP global or supplemental configuration and will cause degraded throughput.

Does this help?
Your problem is an overload of DNS requests to the router, going beyond the limit of 150.
DNS is Domain Name System, if you type in a URL e.g. http://smallnetbuilder.com, your computer needs an Internet address to really find that location, the request comes in to the router and the router forward the request to a DNS server on the Internet, which shall return with 198.41.207.237 as an address. The computer will finally try to reach that address to open the website.

Your router at some moment received over 150 DNS query requests and dnsmasq generates the error in the router log. Because the router cannot further handle DNS queries, your Windows computer waits too long for an address solution and gives an error in its log as well. You feel this error handling as slow down or even termination of Internet activity.

As said before: the problem is not your router, it is one (or more) devices on your local network.

The way forward is given and partly given by your self: find the cause of those extreme high numbers of DNS queries:
  • Scan for malware.
  • Use different tools to scan for malware.
  • Disable downloaders (e.g. torrents).
  • Shut down computers to try to isolate the issue.
  • Connect one computer at a time to try to find the culprit.
 
Last edited:
Found the following events network related in Windows 8.1 machine:

Name resolution for the name wpad timed out after none of the configured DNS servers responded.

TCP/IP has chosen to restrict the congestion window for several connections due to a network condition. This could be related to a problem in the TCP global or supplemental configuration and will cause degraded throughput.

Does this help?

wpad is Web Proxy Auto-detect. You can attempt to stop this from happening by turning off proxy auto-detect in the app/OS. Also, you could try adding the following line to your hosts file: I tried adding the locations of the hosts file but smallnetbuilder's CloudFlare protection wouldn't let me submit a file path in the post data, interesting service, but somewhat heavy handed.. :) Ahh nevermind I just noticed the "notice" at the top :)

look in windows->system32->drivers->etc->hosts .. or on OSX/Linux etc->hosts

Anyway.. add the following line

127.0.0.1 wpad
 
Last edited:
Running this firmware on my N66W and N66U and the 2.4GHz band is suffering significantly. I have a 150Mbps download connection from my ISP and on the 2.4GHz band the most I get is 45Mbps download. 5GHz band is fine.
 
Hang-ups and messages...

This firmware version hangs-up frequently over the previous version 3.0.0.4.376.3602. The router ceases to respond and will eventually clear itself. Has anyone here noticed this issue?

I also noticed many of these messages in the General Log: [date] kernel: printk: 166 messages suppressed.

They started to appear within the last two weeks and I don't know what they mean.
 
Seems like my network problems occurs in proximity with the following events in log
Dec 31 17:45:43 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:45:56 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:02 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:12 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:20 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
Dec 31 17:46:30 dnsmasq[350]: Maximum number of concurrent DNS queries reached (max: 150)
This entries appears every 24h approximately and it seems that the problems occurs nearby before and after.
This kind of entries in log were related with two computers, one with Windows 7 and another one with Windows 8.1. Upgraded router firmware to 3.0.0.4.376.3754 and they stopped appearing.

The central issue still remains after upgrading firmware, router stops transferring data for some minutes several times per day.
 
dhcp-lease-max not fixed ...

I don't use stock either but loaded 3657 to test as others may want to know.

dhcp-lease-max=253

I guess this means Asus fixed the issue.

Actually, there is still an issue - I am unsure of the full original issue, but I found this:

After spending a few hours chasing a home network bug which I finally tracked down as in the latest asus rt-n66u firmware and how it handles dhcp leases.

In short, I have allocated ranges for devices on my internal /24 subnet.
Range Type
1 - 31 Firewalls / Routers
32 - 63 Clients
64 - 95 DHCP Clients
96 - 127 Reserved
128 - 159 Devices
160 - 191 Reserved
192 - 223 Appliances
224 - 254 Servers


As I add devices, they originally show up under the unassigned dhcp, then I grab the MAC address and assign am IP address in the appropriate range. My ideal world has few available unassigned IP ranges since it makes it harder to get a lease if the wifi is cracked

With servers, media players, printers, consoles, phones, tablets, etc, my fixed dhcp table is in the region of 24 devices.

As nothing lives permanently in the unassigned dhcp range, it dropped it down to 8 addresses, which ran from 64 - 71. Obviously, I don't want the unassigned range to overlap with the assigned elements to reduce the risks of devices with duplicate ip numbers

After installing the recent firmware update, I kept running out of leases and having devices constantly bombarding the router for an address even though one was allocated.

Turns out that someone in their wisdom decided that the maximum number of dhcp leases (the setting on dhcp-lease-max in /etc/dnsmasq.conf) would equal the total range of the leases set for unallocated ip's, which in my case was 8 addresses.

Fixing is painful, as every reboot overwrites the settings in the file, so I increased the size of the unassigned ip range to 32 to solve.

But seriously - dumb bug, the engineer doing firmware for these routers should understand dhcp better than this. The manual says it supports 253 addresses in dhcp - honour that in the Max lease setting
 
Last edited:

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top