asuswrt-merlin 380.57 on RT-AC66U B0: Can't comprehend behaviour of LEDs

[A.D.]

I bought a new RT-AC66U (B0 HW) last week to operate it as an access point.

My main motivation for trying asuswrt-merlin 380.57 was that the stock firmware doesn't spin down the external HDD which I connected a few days later. I flashed asuswrt-merlin RT-AC66U_380.57_0.trx and did a factory reset afterwards.

That's where the big thank you goes. Not only does asuswrt-merlin handle the USB HDD. Even in access point mode, there are some nice additions available.

I definitely will use Stealth Mode later but since the device is new, I'm experiencing with its behaviour and performance in the existing context, so the LEDs are active.

I noticed that the LEDs don't behave as with the stock FW. The 2.4 GHz LED works, but it's blinking a lot after system reboot -- a bit too much maybe. And the 5 GHz LED is always on, regardless what the 5 GHz clients do. The USB LED also does not seem to indicate data transfer as before. The other LEDs seem to work fine.

Not much of a problem, but irritating at times when I want to get an overview of the current data traffic. Is there something I can do or try?

 

[ColinTaylor]

The network LEDs are on when there is no traffic. They blink off when there is traffic. A LED is completely off if nothing is connected to that port. My USB LED is always on regardless of activity.

 

[RMerlin]

LED behaviour is identical to the stock firmware - there was no change there.

 

[A.D.]

The network LEDs are on when there is no traffic. They blink off when there is traffic. A LED is completely off if nothing is connected to that port. My USB LED is always on regardless of activity.

Sorry for being not clear enough. What you describe is exactly what I would expect and what the stock FW does. Not so with asuswrt-merlin 380.57.

Do you use 380.57 on an AC66U?

 

[A.D.]

LED behaviour is identical to the stock firmware - there was no change there.

Then what could I do / have done wrong, because it's different now?

 

[ColinTaylor]

Do you use 380.57 on an AC66U?

No I don't, sorry. So I'm not a valid comparison.

The 2.4 GHz LED blinking a lot on boot is normal as far as I am concerned. So the only odd behaviour seems to be the 5GHz LED. Are you sure you have any clients connected to 5GHz?

 

[A.D.]

No I don't, sorry. So I'm not a valid comparison.

The 2.4 GHz LED blinking a lot on boot is normal as far as I am concerned. So the only odd behaviour seems to be the 5GHz LED. Are you sure you have any clients connected to 5GHz?

Valid question. But since 2.4 GHz and 5 GHz SSIDs are different... yes, absolutely, up to five. And provoking traffic of various kinds.

I could swear I had seen the USB LED blink on access with the stock FW, also. But that's less relevant to me than the 5 GHz traffic.

 

[RMerlin]

Then what could I do / have done wrong, because it's different now?

Could be something that changed at some point with a specific firmware change.

 

[L&LD]

Did you perform a reset to factory defaults after flashing the firmware and then manually and minimally configure the router to secure it and connect to your ISP?

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

 

[A.D.]

Could be something that changed at some point with a specific firmware change.

That was the key; thank you.

The RT-AC66U LEDs work just fine with asuswrt-merlin 378.56.2.

There's no official 380 firmware for the RT-AC66U from ASUS yet. Maybe they discontinued its support and are starting to drop HW specific code artefacts along the way, in favour of compile time switches for new models.

 

[A.D.]

Did you perform a reset to factory defaults after flashing the firmware and then manually and minimally configure the router to secure it and connect to your ISP?

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

To be honest, I did not -- it wasn't mentioned in the README-merlin. Thank you for the pointer.

Didn't make any difference, though.

I presume the RT-AC66U is no longer fully supported by the ASUS code base beyond 378.

 

[ColinTaylor]

There's no official 380 firmware for the RT-AC66U from ASUS yet. Maybe they discontinued its support and are starting to drop HW specific code artefacts along the way, in favour of compile time switches for new models.

Well considering they issued a new firmware last month and 2 in December it still looks pretty well supported. I think the older hardware can't support some of the features that the newer hardware has. That might explain the different branches.

 

[A.D.]

Well considering they issued a new firmware last month and 2 in December it still looks pretty well supported. I think the older hardware can't support some of the features that the newer hardware has. That might explain the different branches.

Could you please clarify:

• Are you suggesting the asuswrt-merlin 380.57 is based on an ASUS code branch which does not support the RT-AC66U any more, while another branch exists which supports it? Or what do you refer to when you mention "different branches"?
• Would you expect that there is a potential for further subsystems of the RT-AC66U hardware which might be not fully supported in this case?

On second thought, I'm not so sure any more whether it's really a hardware driving problem. The LEDs in question do reflect the respective basic interface status (on/off) in a plausible manner (timing), and they're also all toggled on/off during boot, as with the 378. It's just that activity isn't shown for 5 GHz and USB any more, while 2.4 GHz simply "feels different".

But that could potentially also be due to a software change in the data collection for making the LEDs blink which e.g. doesn't work well on the RT-AC66U with its (nowdays) relatively slow 600 MHz CPU.

 

[ColinTaylor]

Are you suggesting the asuswrt-merlin 380.57 is based on an ASUS code branch which does not support the RT-AC66U any more, while another branch exists which supports it? Or what do you refer to when you mention "different branches"?

Sorry, I'm not an expert when it comes to the different versions of the firmware. Perhaps "branch" was the wrong term. It just seems to me that looking at the official firmware download pages, most of the routers are using 378 whilst only the routers released at the end of last year are using 380.

There's no doubt some logic to this that maybe @RMerlin can explain.

 

[L&LD]

If I remember what RMerlin wrote a while back, Asus is following two code branches for a while now until they get the new (SDK) routers (AC3100, AC88U, AC5300) to a certain functional and reliability level.

Afterwards, they will once again merge the features to have one base and models will be able to support the features as their hardware will allow.

I think this may have gotten a little more complicated now that Asus will be introducing new routers soon(ish)?

 

[L&LD]

To be honest, I did not -- it wasn't mentioned in the README-merlin. Thank you for the pointer.

Didn't make any difference, though.

I presume the RT-AC66U is no longer fully supported by the ASUS code base beyond 378.

Your presumption is wrong. RT-AC66U still actively supported by Asus.

I don't want to re-read the posts above, but since this router is in AP mode, could following the reset to factory defaults with minimal and manual configuration link be useful for your main router too?

 

[A.D.]

Your presumption is wrong. RT-AC66U still actively supported by Asus.

I don't want to re-read the posts above, but since this router is in AP mode, could following the reset to factory defaults with minimal and manual configuration link be useful for your main router too?

The factory default procedure didn't change anything fpr the RT-AC66U, and my router is a non-ASUS SOHO product.

Let me try to sum up everything I learned from you and @ColinTaylor:

• The RT-AC66U is still supported by ASUS.
• If it is still supported, the current ASUS code base will be merged later with 378.56 to officially support it.
• Since there is no 380 FW for it by ASUS, the current asuswrt-merlin 380.57 is not guaranteed to work flawlessly with it.
• To be on the safe side, one should use only asuswrt-merlin versions based on code versions which ASUS officially made available for the device in question.

Is that it?

Thank you for your valuable input!

 

[L&LD]

The factory default procedure didn't change anything fpr the RT-AC66U, and my router is a non-ASUS SOHO product.

Let me try to sum up everything I learned from you and @ColinTaylor:

• The RT-AC66U is still supported by ASUS.
• If it is still supported, the current ASUS code base will be merged later with 378.56 to officially support it.
• Since there is no 380 FW for it by ASUS, the current asuswrt-merlin 380.57 is not guaranteed to work flawlessly with it.
• To be on the safe side, one should use only asuswrt-merlin versions based on code versions which ASUS officially made available for the device in question.

Is that it?

Thank you for your valuable input!

Yes.

For your last point, you may also want to try john9527 or hggomes firmware forks too (both based off of RMerlin's work).

The reason? RMerlin has suspended work on his firmware for health reasons. Both john9257 and hggomes have continually upgraded as required.

CURRENT VERSION:
================

380.57.5_HGG-FINAL (based on RMerlin 380.57)


https://github.com/RMerl/asuswrt-merlin/blob/master/README-merlin.txt
https://www.mediafire.com/folder/05psguze7t8gs


SUPPORTED MODELS:
================

RT-N16, RT-N66U, RT-AC66U, RT-N18U, RT-AC56U, RT-AC56S, RT-AC68U, RT-AC68P, RT-AC87U, RT-AC88U, RT-AC3100, RT-AC3200, RT-AC5300

U, R, W and P variations are also compatible.

U - Base Model
R - Retail Model
W - White Color
P - New model also known as RT-AC68U V2.

*UNLOCKED* FW files with 89 updated old packages to latest versions (lots of CVEs fixes), pppoe-server, sftp-server and bonding support,
custom MOTD, nano editor, new FW commands available and some other extra features that could be seen in detail on FW changes list bellow.


UPDATED PACKAGES:
================

atop avahi bonnie bridge-utils coreutils curl cyassl diskdev_cmds darkstat dnsmasq dosfstools dropbear e2fsprogs ebtables ecmh expat ffmpeg
flac flex gdb geoIP htop ifenslave iftop iperf iproute2 iproute2-3x iputils jpeg libevent libexif libgcrypt libgdbm libgpgerror libgmp libmnl
libncurses libogg libpcap libusb libvorbis libxml2 lighttpd (CVEs only) lsof lzma lzo masscan matrixssl mDNSResponder memtester minidlna
miniupnpd nano ncat neon nmap nping net-snmp netstat-nat ntfs-3g openlldp openpam openssl openvpn pcre ppp pppoe-server pptp-client pptpd quagga
radvd sdparm sftp-server sqlite strace tcpdump tor usb_modeswitch udev udhcpd udpxy util-linux vlan vsftpd wget wireless_tools xl2tpd xzutils
zlib


********************************************************************************************************************************************
* MANDATORY: FACTORY DEFAULT RESTORE (http://ROUTERIP/Advanced_SettingBackup_Content.asp) AND/OR HW RESET IS REQUIRED AFTER FW UPGRADE. *
* ********* DO NOT USE/IMPORT OLD CONFIGURATION FILE FROM A DIFFERENT FW AFTER FLASHING, JUST CONFIGURE IT MANUALLY FROM SCRATCH. *
* *
* ALL WIRELESS CHANNELS ARE UNLOCKED AND AVAILABLE ON THIS FW, SO YOUR CLIENTS COULD NOT USE SOME OF THEM BECAUSE OF REGION LOCK ON THE *
* CLIENT SIDE. DO NOT USE AUTO CONTROL CHANNEL OPTION OR THE ROUTER CAN ACT LIKE IT'S NOT BROADCASTING TO THOSE CLIENTS. *
* *
* ALWAYS CHOOSE A MANUAL CONTROL CHANNEL ON BOTH 2.4 AND 5GHZ BANDS (http://ROUTERIP/Advanced_Wireless_Content.asp) *
* *
********************************************************************************************************************************************


POWER SLIDE: - http://ROUTERIP/Advanced_WAdvanced_Content.asp
===========

These are the new TX Power level reference values:


1% => 42mW (16.2 dBm)

25% => 83mW (19.2 dBm)

50% => 178mW (22.5 dBm)

75% => 355mW (25.5 dBm)

100% => 1000mW (30 dBm)


By default the FW powerslide is set to 70% (25dBm), for more information about txpower usage please read:

http://www.quantenna.com/pdf/80211nPowerSettings.pdf

NOTE: This FW will increase wireless signal strength RSSI by 10-24dbm over stock/other FWs on 2.4 and 5GHZ bands, depending on router model.

ENHANCED MODE / MAXIMUM COVERAGE option (only available on FW versions >= 380.57) can be used to gain an extra ~7-12dBm (2.4GHZ) / ~3-5dBm (5GHZ).


CONTACT / FEEDBACK:
==================

asuswrt.hgg@gmail.com


CHANGES:
=======

380.57.6: (17 FEV 16)

- NEW: OpenVPN XOR obfuscation and UTUN support.
- FIXED: Unable to set Regulation Mode on WEBUI.
- FIXED: Preamble Type removal (ASUS code) on 5GHZ Professional tab.
- FIXED: WEBUI APPLY timings.
- UPDATED: Curl to 7.47.1 version.
- UPDATED: Htop to 2.0.0 version.
- UPDATED: Libgcrypt to 1.6.5 version.
- UPDATED: MiniUPNPd to 1.9.20160216 version.
- UPDATED: Nano Editor to 2.5.2 version.
- UPDATED: SDParm to 1.10b4 version.
- UPDATED: SQLite to 3.11.0 version.


380.57.5: (8 FEV 16)

- FIXED: Enhanced Mode, it locks up after set to Maximum Coverage (slower speeds) and it's unable to revert back to Maximum Speed after, this affects all ARM models.
- UPDATED: SDParm to 1.10b3 version.


380.57.4: (3 FEV 16)

- FIXED: MiniDLNA not working due to wrong symlink filename.

KNOWN ISSUES:

- Enhanced Mode, it locks up after set to Maximum Coverage (slower speeds) and it's unable to revert back to Maximum Speed after, this affects all ARM models.


380.57.3: (1 FEV 16)

- NEW: Private Internet Access VPN support.
- FIXED: ASUS WEBUI missing code.
- FIXED: RT-AC56U/S TX Power code.
- FIXED: WEBUI Media Server code.
- UPDATED: Curl to 7.47.0 version.
- UPDATED: JPEG to v9b version.
- UPDATED: LibUSB to 1.0.20 version.
- UPDATED: OpenSSL to 1.0.2f version.
- UPDATED: PCRE to 8.38 version.
- UPDATED: SDParm to 1.10b2 version.
- UPDATED: SQLite to 3.10.2 version.
- UPDATED: USB_ModeSwitch to 2.3.0 version.

KNOWN ISSUES:

- MiniDLNA not working due to wrong symlink filename.

The above is an example of what has changed in the hggomes version.

Note the 380.57.6 version changes we can expect.

 

[A.D.]

Yes.

For your last point, you may also want to try john9527 or hggomes firmware forks too (both based off of RMerlin's work).

The reason? RMerlin has suspended work on his firmware for health reasons. Both john9257 and hggomes have continually upgraded as required.

The above is an example of what has changed in the hggomes version.

Note the 380.57.6 version changes we can expect.

Thank you for all this information. I'm sorry to hear about @RMerlin 's health.

I'll look into the latest available asuswrt FW modifications once ASUS officially announces the new code base version supporting my device.

Many of the announced features seem to be of marginal use for an access point, though. And I definitely need the device to choose its channels automatically. Manual choice is not an option here.