Asus RT-N66U Firmware version 3.0.0.4.376.3861

[wouterv]

It doesn't matter do you choose lower or higher channel, the problem is there as long as you have 802.11d+h.

It should not be like that.
802.11d+h involves DFS, which is only applicable to the channels above 48.

 

[wouterv]

...the things is do you have issue with default channel?
most people that have issue with 5ghz usually change channel to 40

As allready written: the default channel seems to be 48 in my case (not 36), which happens to be the same channel as my neighbors do use since some time.
Channel 36 failed 2 times (the signal simply disappeared), after which I changed to channel 40, this works well for a few days now.

 

[wouterv]

As allready written: the default channel seems to be 48 in my case (not 36), which happens to be the same channel as my neighbors do use since some time.
Channel 36 failed 2 times (the signal simply disappeared), after which I changed to channel 40, this works well for a few days now.

This morning the 5 GHz signal was gone again, no entry in the systemlog.
I changed channel selection back from 40 to Auto.
Although it selects channel 48 again, the same as the neighbors, I am curious if the signal at least stays alive.

 

[AJ_Toronto]

I signed up on this forum to share my experience on N66U, since I upgraded to 3.0.0.4.376.3861, I have issues on the 5Ghz band, connections drops after 2-3 days, I can switch to 2.4Ghz band or reboot router to get connectivity on the 5Ghz band.

Shame on Asus for still not fixing the problem, was thinking about switching back to 3.0.0.4.376.3754 but noticed in the change log of the recent ASUS WRT Merlin that they recognized the issues through user feedback and switched back the driver. I will be using that firmware since it seems more stable than ASUS (doesn't look like ASUS cares about issues, tells me not to buy their router next time maybe)

http://asuswrt.lostrealm.ca/changelog

 

[L&LD]

I signed up on this forum to share my experience on N66U, since I upgraded to 3.0.0.4.376.3861, I have issues on the 5Ghz band, connections drops after 2-3 days, I can switch to 2.4Ghz band or reboot router to get connectivity on the 5Ghz band.

Shame on Asus for still not fixing the problem, was thinking about switching back to 3.0.0.4.376.3754 but noticed in the change log of the recent ASUS WRT Merlin that they recognized the issues through user feedback and switched back the driver. I will be using that firmware since it seems more stable than ASUS (doesn't look like ASUS cares about issues, tells me not to buy their router next time maybe)

http://asuswrt.lostrealm.ca/changelog

Thanks for sharing your experience. But your conclusion seems predetermined and more than a little biased.

I am on the latest RMerlin 378.51 firmware and have a rock solid RT-N66U experience.

Blame Asus if you want. Threaten to not buy their products again. But if you want help to fix your issues or if you want others to be helped from similar issues; then give something more informative than just your conclusions.

Info like;
What does your network topology consist of?
What features of the router do you use?
What clients connect and how?
What firmware did you upgrade from?
What steps did you take to correct the issues?

The above will be more useful than blaming Asus for a problem they probably don't see on their end.

 

[RMerlin]

I signed up on this forum to share my experience on N66U, since I upgraded to 3.0.0.4.376.3861, I have issues on the 5Ghz band, connections drops after 2-3 days, I can switch to 2.4Ghz band or reboot router to get connectivity on the 5Ghz band.

Shame on Asus for still not fixing the problem, was thinking about switching back to 3.0.0.4.376.3754 but noticed in the change log of the recent ASUS WRT Merlin that they recognized the issues through user feedback and switched back the driver. I will be using that firmware since it seems more stable than ASUS (doesn't look like ASUS cares about issues, tells me not to buy their router next time maybe)

http://asuswrt.lostrealm.ca/changelog

The RT-AC66U is the only router for which I had to downgrade the driver. I'm still using the same driver since December 2014 for the RT-N66U.

 

[VANT]

I signed up on this forum to share my experience on N66U, since I upgraded to 3.0.0.4.376.3861, I have issues on the 5Ghz band, connections drops after 2-3 days, I can switch to 2.4Ghz band or reboot router to get connectivity on the 5Ghz band.

Shame on Asus for still not fixing the problem, was thinking about switching back to 3.0.0.4.376.3754 but noticed in the change log of the recent ASUS WRT Merlin that they recognized the issues through user feedback and switched back the driver. I will be using that firmware since it seems more stable than ASUS (doesn't look like ASUS cares about issues, tells me not to buy their router next time maybe)

http://asuswrt.lostrealm.ca/changelog

Do You raport issues to asus suport ? Without this asus never fix it.

 

[wouterv]

This morning the 5 GHz signal was gone again, no entry in the systemlog.
I changed channel selection back from 40 to Auto.
Although it selects channel 48 again, the same as the neighbors, I am curious if the signal at least stays alive.

After the change to Auto channel selection on 5 GHz it is rock solid again.
Weird to see how different the experiences and advises are.
My stable situation (since long time and many firmware versions) is:

• 2.4 GHz on a fixed bandwidth of 20 MHz and fixed manual selected channel (bandwitdth and channel selection to limit neigbor interference).

• 5 GHz on 20/40 MHz and Auto channel selection (Auto select channel including DFS channels = not checked).

Manual channel selection of one of the low, non DFS channels seems to cause the 5 GHz signal to random disappear.
I don't know what firmware introduced the 5 GHz channel selection issue, as I never tried it before. It won't surprise me if firmware 3.0.0.4.376.3602 or 3.0.0.4.376.3657 introduced the issue, together with introduction of the higher 5 GHz channels and the DFS fix.
For what it helps, I am in the Netherlands/Europe, the router shall respect ETSI rules.

 

[VANT]

The RT-AC66U is the only router for which I had to downgrade the driver. I'm still using the same driver since December 2014 for the RT-N66U.

AC66u and n66u uses same wifi driver ?

 

[RMerlin]

AC66u and n66u uses same wifi driver ?

No, they each have their own driver.

 

[Ormu]

This may be a dumb question, but is there any difference in how you reset the router? Several methods are described to reset it and/or clear the NVRAM, such as:

-While the router is on, press reset button for a few seconds.
-Turn off the router - press WPS button - power on while holding WPS button for ~10sec.
-Use the reset button in the web interface.
-Connect using telnet and enter a reset command.

Do all these just clear the NVRAM?

 

[johtaja]

Once I got some problems after fw upgrade when I had tried reset button and web interface reset, but after I cleared nvram via telnet I got rid of problems. So after that I have always cleared nvram via telnet. There must be some difference with different methods.

 

[wouterv]

The known ways to attempt to clear NVRAM are:

1. While the router is on, press reset button for a few seconds.
2. Turn off the router - press WPS button - power on while holding WPS button for ~10sec.
3. Select Factory default - Restore from the Web interface
4. Connect using telnet and enter a reset command: mtd-erase -d nvram

Theorethically all should be the same.
I agree with johtaja: clear NVRAM through the Telnet command seems to be best, I also had issues after Factory default - Restore from the Web interface.

 

[Ormu]

Ok, thanks. I used telnet and I think everything went fine.


However, this firmware version seems to have the same problem as I've had with RT-N56U - if firewall is configured to log dropped packets, the router slows down during ShieldsUP test:
http://www.snbforums.com/threads/rt-n56u-firewall-logging-causes-serious-slowdown.13766/

Does anyone know what could cause this? Just a guess; could it write the log to the NVRAM (flash memory) now, in addition to having it in RAM? It would be slower than having it in the RAM only...


edit: The client list on the main page seems to be glitchy too. Looks like sometimes it doesn't show all clients...

 

[wouterv]

Ok, thanks. I used telnet and I think everything went fine.


However, this firmware version seems to have the same problem as I've had with RT-N56U - if firewall is configured to log dropped packets, the router slows down during ShieldsUP test:
http://www.snbforums.com/threads/rt-n56u-firewall-logging-causes-serious-slowdown.13766/

Does anyone know what could cause this? Just a guess; could it write the log to the NVRAM (flash memory) now, in addition to having it in RAM? It would be slower than having it in the RAM only...


edit: The client list on the main page seems to be glitchy too. Looks like sometimes it doesn't show all clients...

The answer has not changed since your first report.
Did you send your concern to Asus?
If a policeman every day has to write a detailed report of every step he makes, every thing he sees and every word he says and hears, there will finally be no time left for his real duty.

 

[Baz8755]

I also seem to be getting issues with 3861 in that about once every week or 2 the DHCP seems to stop working and I have to reboot the router. I had a similiar problem with the previous release and I even tried a complete NVRAM clear and manual config.

 

[wouterv]

I also seem to be getting issues with 3861 in that about once every week or 2 the DHCP seems to stop working and I have to reboot the router. I had a similiar problem with the previous release and I even tried a complete NVRAM clear and manual config.

1. What exactly is the DHCP issue that you experience?
2. How many clients do connect to the router?
3. How many of these clients frequently disconnect and connect again to the router because they are carried away from home and return (e.g. mobile devices or laptops)?
4. Are there DHCP reservations configured in the router?
5. What have you configured in the DHCP Server Tab?

Anway it may not hurt to upgrade to 3.0.0.4.378.4850, this is quite a major upgrade from 3.0.0.4.376.x to 3.0.0.4.378.x with for sure numerous undocumented enhancements:
http://support.asus.com/Download.aspx?SLanguage=en&m=RT-N66U+(VER.B1)&p=11&s=2
Select OS = Others

 

[Baz8755]

1. What exactly is the DHCP issue that you experience?
2. How many clients do connect to the router?
3. How many of these clients frequently disconnect and connect again to the router because they are carried away from home and return (e.g. mobile devices or laptops)?
4. Are there DHCP reservations configured in the router?
5. What have you configured in the DHCP Server Tab?

Anway it may not hurt to upgrade to 3.0.0.4.378.4850, this is quite a major upgrade from 3.0.0.4.376.x to 3.0.0.4.378.x with for sure numerous undocumented enhancements:
http://support.asus.com/Download.aspx?SLanguage=en&m=RT-N66U+(VER.B1)&p=11&s=2
Select OS = Others

1. When powering up a Device (only noticed on wired ATM) be it printer or PC sometimes they will fail to get an IP address. All my devices are on fixed IPs as defined in the router MAC/IP mapping.
2. I have approximately 20 devices with a mixture of WI-FI & Wired.
3. 2 Phones, but as yet I have not seen the issue with these.
4. Yes, see point 1
5. IP pool starts @ ...240 and ends at ...255, Lease of 1 day, plus all my devices outside of pool.

 

[wouterv]

1. When powering up a Device (only noticed on wired ATM) be it printer or PC sometimes they will fail to get an IP address. All my devices are on fixed IPs as defined in the router MAC/IP mapping.
2. I have approximately 20 devices with a mixture of WI-FI & Wired.
3. 2 Phones, but as yet I have not seen the issue with these.
4. Yes, see point 1
5. IP pool starts @ ...240 and ends at ...255, Lease of 1 day, plus all my devices outside of pool.

The problem is related to your answer 5, the dynamic pool size and sort of bug in the firmware.
Also have a look here:
http://www.snbforums.com/threads/as...ion-3-0-0-4-376-3657.21047/page-3#post-166021

Your fix would be to extend the IP pool, even you are not using that much dynamic addresses.

 

[Baz8755]

The problem is related to your answer 5, the dynamic pool size and sort of bug in the firmware.
Also have a look here:
http://www.snbforums.com/threads/as...ion-3-0-0-4-376-3657.21047/page-3#post-166021

Your fix would be to extend the IP pool, even you are not using that much dynamic addresses.

So am I correct in assuming that merely extending my Pool to now be 200-254 and leaving my 20 or so fixed IP's below at 10-199 will fix the issue?