N66U: Is there any way to test custom/old firmwares without breaking warranty

[carn1x]

After much reading online, I'm coming to the conclusion that my N66U's inability to maintain a WAN connection is software related. I'd like to test this by using either some custom firmwares, or maybe try some older firmwares.

Is there any way to test custom firmwares without breaking warranty? I would suppose not, but I've not seen the question asked so I thought I might.

In addition, I would like to try some older firmwares, starting from 3.0.0.3.178 and earlier, as some people reported WAN connectivity issues on firmware's after that point. Is there an ASUS hosted archive of old firmwares? I've tried guessing the download link based on the filename such as http://dlcdnet.asus.com/pub/ASUS/wireless/RT-N66U_B1/FW_RT_N66U_3003178.zip however this does not work.

Would there be issues with trying to flash an older firmware similar to custom firmware? Is it possible that I have a newer hardware revision (bought Dec 22 2013) which could prevent older firmware flashing anyway, or even worse, brick my router?

Thanks for any pointers


EDIT: OK looks like they are hosted at softpedia: http://drivers.softpedia.com/dyn-se...upd_filter=0&results_per_page=20&sort_field=0

I don't see the exact firmware I'm looking for, but I do see older versions. One obvious point however is the Ver.B1, is this hardware or software related? It's even mentioned in the model on Asus site: http://support.asus.com/download.aspx?slanguage=en&m=RT-N66U+(VER.B1)&os=8 however there appears to be no way to search for firmware for any other variation of the N66U which leads me to believe there's really only one model?

 

[wouterv]

The "RT-N66U B1" is the first production model (technically identical to the RT-N66W, the white model).
Mid 2013 Asus introduced a new flash ROM type in the RT-N66U, the model name stayed unchanged (I don't think there is a way to identify your model without opening it).
The new flash ROM requires newer firmware, this newer firmware is backward compatible with the old flash ROM and can be used in "any" RT-N66U.

Asus firmware version 3.0.0.4.270 and older is ONLY for the older flash ROM models.

Asus firmware 3.0.0.4.276 is the first version "3.0.0.4.2xx series" newer firmware, and compatible with older and newer RT-N66U.

Asus firmware 3.0.0.4.374.xx is also compatible with older and newer RT-N66U (I believe actually halfway the 3.0.0.4.372.xx series firmware compatibility with the new flash ROM was introduced).

Asus firmware 3.0.0.4.374.720 and 3.0.0.4.374.979 use SDK6 wireless drivers, which for many users solves wireless problems introduced with version 3.0.0.4.354 (wireless problems are still reported though and the wireless range is known to be decreased for everyone compared to the older SDK5 wireless drivers).

PPPoE issues can be either firmware or ISP related as far as known now.
To try to solve WAN / PPPoE issues either Asus version 3.0.0.4.276 or Merlin version 3.0.0.4.374.36 Beta 1 is advised.

Flashing Asus stock firmware versions does to my opinion not void warranty.
Most stable for everyone seems to be Asus version 3.0.0.4.276.

 

[carn1x]

The "RT-N66U B1" is the first production model (technically identical to the RT-N66W, the white model).
Mid 2013 Asus introduced a new flash ROM type in the RT-N66U, the model name stayed unchanged (I don't think there is a way to identify your model without opening it).
The new flash ROM requires newer firmware, this newer firmware is backward compatible with the old flash ROM and can be used in "any" RT-N66U.

Asus firmware version 3.0.0.4.270 and older is ONLY for the older flash ROM models.

Asus firmware 3.0.0.4.276 is the first version "3.0.0.4.2xx series" newer firmware, and compatible with older and newer RT-N66U.

Asus firmware 3.0.0.4.374.xx is also compatible with older and newer RT-N66U (I believe actually halfway the 3.0.0.4.372.xx series firmware compatibility with the new flash ROM was introduced).

Asus firmware 3.0.0.4.374.720 and 3.0.0.4.374.979 use SDK6 wireless drivers, which for many users solves wireless problems introduced with version 3.0.0.4.354 (wireless problems are still reported though and the wireless range is known to be decreased for everyone compared to the older SDK5 wireless drivers).

PPPoE issues can be either firmware or ISP related as far as known now.
To try to solve WAN / PPPoE issues either Asus version 3.0.0.4.276 or Merlin version 3.0.0.4.374.36 Beta 1 is advised.

Flashing Asus stock firmware versions does to my opinion not void warranty.
Most stable for everyone seems to be Asus version 3.0.0.4.276.

Thanks, I'll try the downgrade tonight to 4.276. I have a strange feeling it was 4.276 when I first opened it up, but I can't be sure until I get home.

It seems that people only really mention the Merlin FW on here. As I understand it there are other solutions too, such as Tomato, should I be wary of others for some reason?

EDIT: Oh I see that Merlin can be flashed via the existing firmware, does that mean it avoids breaking warranty? Why is it that Merlin can use this easy method where others like Tomato have failed?

 

[wouterv]

To my knowledge there is the following firmware for the RT-N66U:

• AsusWRT stock: https://www.asus.com/Networking/RTN66U/#support
• AsusWRT-Merlin: http://www.lostrealm.ca/tower/node/79 - build on the Asus stock GPL source code, with additional features and bug fixes.
• Tomato by Shibby: http://tomato.groov.pl/ - Based on the original Tomato, support seems a bit weak.
• DD-WRT: http://dd-wrt.com/wiki/index.php/Asus_RT-N66U - Fairly wide spread firmware code, customised for many routers, many features, good support cummunity, the release strategy is confusing (finding a version that is suitable for your router can be hard). Throroughly read the above link for file version and installation instructions (K3 branded builds seems the way to go).

The safest to my opinion are the Merlin versions, going back and forward between stock versions and Merlin versions is no problem because the source codes are very similar.

Sending in a router for RMA with other than stock firmware may raise questions.

No matter what firmware you install, it is strongly advised to revert to factory defaults and manual configure the router when you change versions (the saved backup file is not allways compatible). Make notes of YOUR configuration settings other then default and make one change at a time to see the result.

 

[RMerlin]

Thanks, I'll try the downgrade tonight to 4.276. I have a strange feeling it was 4.276 when I first opened it up, but I can't be sure until I get home.

It seems that people only really mention the Merlin FW on here. As I understand it there are other solutions too, such as Tomato, should I be wary of others for some reason?

EDIT: Oh I see that Merlin can be flashed via the existing firmware, does that mean it avoids breaking warranty? Why is it that Merlin can use this easy method where others like Tomato have failed?

That's because my firmware is a modified version of Asus's, and I make sure to retain near 100% backward and forward compatibility with it (the only exception at this time are OpenVPN keys, as Asus don't encode them before saving them to nvram).

You won't void your warranty by flashing a third party firmware. Asus themselves even promote DD-WRT on their website as a compatible firmware for some of their routers.

http://promos.asus.com/US/ASUS_DD-WRT/

 

[carn1x]

Looks like the 36b1 doesn't really solve the problem, still getting fairly regular disconnects, here's a log of such an occurrence:

Jan  4 14:31:32 pppd[643]: LCP terminated by peer
Jan  4 14:31:32 pppd[643]: Connect time 53.0 minutes.
Jan  4 14:31:32 pppd[643]: Sent 50451259 bytes, received 2558950378 bytes.
Jan  4 14:31:32 miniupnpd[680]: Failed to get IP for interface ppp0
Jan  4 14:31:32 miniupnpd[680]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jan  4 14:31:32 dnsmasq[693]: read /etc/hosts - 5 addresses
Jan  4 14:31:32 dnsmasq[693]: using nameserver 192.168.8.1#53
Jan  4 14:31:33 WAN Connection: Fail to connect with some issues.
Jan  4 14:31:33 stop_nat_rules: apply the redirect_rules!
Jan  4 14:31:35 dnsmasq[693]: exiting on receipt of SIGTERM
Jan  4 14:31:35 dnsmasq[740]: started, version 2.67 cachesize 1500
Jan  4 14:31:35 dnsmasq[740]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth
Jan  4 14:31:35 dnsmasq[740]: warning: interface ppp1* does not currently exist
Jan  4 14:31:35 dnsmasq[740]: asynchronous logging enabled, queue limit is 5 messages
Jan  4 14:31:35 dnsmasq-dhcp[740]: DHCP, IP range 192.168.1.2 -- 192.168.1.254, lease time 1d
Jan  4 14:31:35 dnsmasq[740]: read /etc/hosts - 5 addresses
Jan  4 14:31:35 dnsmasq[740]: using nameserver 192.168.8.1#53
Jan  4 14:31:35 pppd[643]: Connection terminated.
Jan  4 14:31:35 pppd[643]: Sent PADT
Jan  4 14:31:35 pppd[643]: Modem hangup
Jan  4 14:31:45 kernel: vlan1: received packet with  own address as source address
Jan  4 14:31:45 pppd[643]: PPP session is 825 (0x339)
Jan  4 14:31:45 pppd[643]: Connected to 00:30:88:01:bd:81 via interface eth0
Jan  4 14:31:45 pppd[643]: Using interface ppp0
Jan  4 14:31:45 pppd[643]: Connect: ppp0 <--> eth0
Jan  4 14:31:46 pppd[643]: PAP authentication succeeded
Jan  4 14:31:46 pppd[643]: peer from calling number 00:30:88:01:BD:81 authorized
Jan  4 14:31:46 miniupnpd[680]: Failed to get IP for interface ppp0
Jan  4 14:31:46 miniupnpd[680]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jan  4 14:31:46 miniupnpd[680]: Failed to get IP for interface ppp0
Jan  4 14:31:46 miniupnpd[680]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jan  4 14:31:46 miniupnpd[680]: Failed to get IP for interface ppp0
Jan  4 14:31:46 miniupnpd[680]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jan  4 14:31:46 pppd[643]: local  IP address 1.65.20.155
Jan  4 14:31:46 pppd[643]: remote IP address 112.118.215.254
Jan  4 14:31:46 pppd[643]: primary   DNS address 218.102.60.110
Jan  4 14:31:46 pppd[643]: secondary DNS address 218.102.62.71
Jan  4 14:31:46 dnsmasq[740]: read /etc/hosts - 5 addresses
Jan  4 14:31:46 dnsmasq[740]: using nameserver 218.102.62.71#53
Jan  4 14:31:46 dnsmasq[740]: using nameserver 218.102.60.110#53
Jan  4 14:31:46 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Jan  4 14:31:46 dnsmasq[740]: exiting on receipt of SIGTERM
Jan  4 14:31:46 dnsmasq[768]: started, version 2.67 cachesize 1500
Jan  4 14:31:46 dnsmasq[768]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth
Jan  4 14:31:46 dnsmasq[768]: warning: interface ppp1* does not currently exist
Jan  4 14:31:46 dnsmasq[768]: asynchronous logging enabled, queue limit is 5 messages
Jan  4 14:31:46 dnsmasq-dhcp[768]: DHCP, IP range 192.168.1.2 -- 192.168.1.254, lease time 1d
Jan  4 14:31:46 dnsmasq[768]: read /etc/hosts - 5 addresses
Jan  4 14:31:46 dnsmasq[768]: using nameserver 218.102.62.71#53
Jan  4 14:31:46 dnsmasq[768]: using nameserver 218.102.60.110#53
Jan  4 14:31:46 rc_service: ip-up 750:notify_rc stop_upnp
Jan  4 14:31:46 rc_service: ip-up 750:notify_rc start_upnp
Jan  4 14:31:46 miniupnpd[783]: HTTP listening on port 56317
Jan  4 14:31:46 miniupnpd[783]: Listening for NAT-PMP traffic on port 5351
Jan  4 14:31:50 WAN Connection: WAN was restored.

For some idea of how often this happens:

Jan  4 14:31:32 pppd[643]: Connect time 53.0 minutes.
Jan  4 14:31:50 WAN Connection: WAN was restored.

Jan  4 15:27:45 pppd[643]: Connect time 56.0 minutes.
Jan  4 15:28:03 WAN Connection: WAN was restored.

Jan  4 16:41:00 pppd[643]: Connect time 73.1 minutes.
Jan  4 16:41:15 WAN Connection: WAN was restored.

Jan  4 17:03:44 pppd[643]: Connect time 22.6 minutes.
Jan  4 17:04:43 WAN Connection: WAN was restored.

Jan  4 17:19:17 pppd[643]: Connect time 14.6 minutes.
Jan  4 17:19:34 WAN Connection: WAN was restored.

Jan  4 17:35:31 pppd[643]: Connect time 16.0 minutes.
Jan  4 17:35:46 WAN Connection: WAN was restored.

Jan  4 18:46:24 pppd[643]: Connect time 70.7 minutes.
Jan  4 18:46:42 WAN Connection: WAN was restored.

Jan  4 19:17:48 pppd[643]: Connect time 31.2 minutes.
Jan  4 19:18:04 WAN Connection: WAN was restored.

Jan  4 19:37:33 pppd[643]: Connect time 19.6 minutes.
Jan  4 19:37:48 WAN Connection: WAN was restored.

Jan  4 20:15:49 pppd[643]: Connect time 38.1 minutes.
Jan  4 20:16:05 WAN Connection: WAN was restored.

Jan  4 21:07:45 pppd[643]: Connect time 51.7 minutes.
Jan  4 21:08:49 WAN Connection: WAN was restored.

Jan  4 21:19:00 pppd[643]: Connect time 10.3 minutes.
Jan  4 21:19:21 WAN Connection: WAN was restored.

Whilst the gaps appear to be for only 15 seconds, I experience probably a few minutes of downtime whenever this occurs. This only happens using the N66U, and does not occur with the Cisco EA2700 at all using the same PPPoE method.

 

[wouterv]

This is something for Asus or Merlin to look into.
It seems you run into a known but unsolved PPoE problem.
What is your ISP?

You may try DD-WRT, for that it is the best to really check user experiences, then load the advised K3 build (dd-wrt.v24-21676_NEWD-2_K3.x_mega_RT-N66U.trx) as suggested before...of course...at your own risk.
http://dd-wrt.com/wiki/index.php/Asus_RT-N66U#New_K3.X_Builds

 

[CooCooCaChoo]

Somebody else on this board was reporting frequent disconnects as well. Their problem was cabling...

 

[carn1x]

This is something for Asus or Merlin to look into.
It seems you run into a known but unsolved PPoE problem.
What is your ISP?

You may try DD-WRT, for that it is the best to really check user experiences, then load the advised K3 build (dd-wrt.v24-21676_NEWD-2_K3.x_mega_RT-N66U.trx) as suggested before...of course...at your own risk.
http://dd-wrt.com/wiki/index.php/Asus_RT-N66U#New_K3.X_Builds

Thanks, I'll look into that. Why is DD-WRT advised? Is it just another thing to try or has it helped with PPPoE for others?

Somebody else on this board was reporting frequent disconnects as well. Their problem was cabling...

I read that too, and I tried a few cat5e cables to seemingly no difference. I suppose it's possible they are all bad. None are longer than 1m though. Is there any way to test whether my cat5e's are good enough?

 

[wouterv]

I suggested DD-WRT because it is not based on Asus stock firmware code and it is widely used with a broad user and support community.
You can check the DD-WRT forum for PPPoE and RT-N66U related posts:
http://dd-wrt.com/phpBB2/viewforum.php?f=1&sid=11d9b324f43e2362b898aa8fcd1fd2d9

I have no PPPoE, so for me there is no reason to change to DD-WRT. In the past I had a Linksys router for long time running DD-WRT, currently I have a Linksys box running DD-WRT as Client-Bridge. It is well developped and robust.

Cat5 should be good enough. Try to wiggle the connectors once seated in the router and modem, see if that breaks the connection.
The lenght of 1 m should be ok.
Cables can be tested with a dedicated cable tester or use a mulimeter and check the resistance from one end to the other. I doubt that you run into a bunch of bad cables.

Was your PPPoE connection ever stable, with the RT-N66U or another router?
Did your ISP change something?

 

[carn1x]

Hi, OK I'll look into DD-WRT, thanks.

My ISP is PCCW on the 100Mbit VDSL plan, in Hong Kong, probably one of the most popular internet plans in the country. It's interesting that 374.720 lists the following fix:

2. Fixed HK ISP DHCP connection issue.

I can swap out the N66U for my Cisco EA2700 now and experience perfect internet with no disconnections, using all the same cables. Unfortunately the EA2700 has problems with Wifi which is my reason for purchasing the N66U.

I'm aware I could use both the N66U and EA2700 and probably solve all my problems, however EA2700 is known to be insecure and the N66U not fulfilling this role is obviously not reasonable and so I'm determined to try and get to the bottom of this!

Thanks again.

 

[wouterv]

Not all mentioned fixes work out well for everyone ;-)
In other words: do not allways believe the release notes.
Murphies law fully applies, new firmware releases usually fix a few problems and create at least the same amount of new problems.

It would be nice if Merlin can look into your logs, I can imagine he suffers the bad weather in the northern Americas and Canada and has other issues to look after.

 

[carn1x]

Asus Tech Support have been pretty responsive. Their first response however was pretty useless, asking me questions I told them in my initial request. Their follow up however advised me to test without the ISP TV which I'll try next time the wife is out . They also advised I try MAC Cloning which I'm testing now, fingers crossed

EDIT: I note that the latest Merlin (and maybe Asus FW, I still have Merlin flashed) has a MAC Clone button next to the MAC Address field, however clicking this button doesn't seem to do anything? I have simply entered the MAC Address of my previous router into that field and clicked Apply and it's persisting. It seems in cases where others have had MAC locking problems, it seems they had zero connectivity, or they solved the problem by simply power cycling the modem, neither applying to my case.

EDIT: OK 12 hours of zero disconnects after applying the MAC clone. Previous record was about 2-4 hours I think, so it's looking pretty good.

 

[wouterv]

It would be brilliant if MAC cloning is the solution for the PPPoE disconnect issue.
I know from my DHCP WAN connection that it immediately refuses a new MAC address (due to exchange of a router), I have to leave the modem off for considerable time (an hour or so) and switch it on again with the new router to accept another MAC address...unless I use MAC cloning.
I assume PPPoE also has a timeout for MAC addresses, or (what I know was used mostly in the old days) you have to register a new MAC address at the ISP through some administrative procedure.

ASUS firmware 3.0.0.4.374_979 also has the MAC Clone option under WAN>Internet Connection Tab, I assume it is there since ever (it is a rather standard thing in routers).