Asus RT87 - Merlin

[Ritzie]

Hey Merlin think you will do a firmware for this router? I'm in desperate need of your parental controls!!! Not pushing just wondering.

 

[damir]

Hey Merlin think you will do a firmware for this router? I'm in desperate need of your parental controls!!! Not pushing just wondering.

He is. Do some re-search

 

[RMerlin]

I was fixing the last RT-AC87U specific issues last night (one LED wasn't obeying Stealth Mode, and a display glitch on the wireless log page).

Now I need to look at some of the more generic issues related to 376_1779. I will probably push a beta build in the coming days once I'm satisfied with overall stability. It will depend on how my own testing will progress.

In the meantime, the latest code is published on Github, so anyone can compile it themselves if they want an early preview.

 

[Deleted member 22229]

I was fixing the last RT-AC87U specific issues last night (one LED wasn't obeying Stealth Mode, and a display glitch on the wireless log page).

Now I need to look at some of the more generic issues related to 376_1779. I will probably push a beta build in the coming days once I'm satisfied with overall stability. It will depend on how my own testing will progress.

In the meantime, the latest code is published on Github, so anyone can compile it themselves if they want an early preview.

How about for the AC68U any updates on this router ?

 

[RMerlin]

How about for the AC68U any updates on this router ?

I use a unified code repository, so the 376_1779 code works just as well from the top-of-the-line AC87U down to the entry level RT-N16. I haven't had time to specifically test these however, as the focus was on finalizing support for the AC87U.

 

[Deleted member 22229]

Thanks for the update.

 

[Ritzie]

I was fixing the last RT-AC87U specific issues last night (one LED wasn't obeying Stealth Mode, and a display glitch on the wireless log page).

Now I need to look at some of the more generic issues related to 376_1779. I will probably push a beta build in the coming days once I'm satisfied with overall stability. It will depend on how my own testing will progress.

In the meantime, the latest code is published on Github, so anyone can compile it themselves if they want an early preview.

Thanks Merlin. Appreciate the update. Looking forward to your firmware!!

 

[RMerlin]

One thing people will have to keep in mind however is, Asus is pushing new firmware releases as a neck breaking pace these days. So don't expect any release from me in the near future to be in sync with them, anything I release will always be a week or two behind Asus.

 

[jim769]

One thing people will have to keep in mind however is, Asus is pushing new firmware releases as a neck breaking pace these days. So don't expect any release from me in the near future to be in sync with them, anything I release will always be a week or two behind Asus.

No problem there i dont use Asus firmware so anything you release will be newer then then your last release. BTW no hurry as 43_2 has been working rock solid here.

Quick question will your new builds also have the Comcast neighbor table overflow fix ? It appears comcast has no interest in ever getting it fixed.

 

[RMerlin]

Quick question will your new builds also have the Comcast neighbor table overflow fix ? It appears comcast has no interest in ever getting it fixed.

This is actually an interesting topic. Asus's solution in their new firmware releases has been to modify the Linux Kernel so the error message does not appear in Syslog's default loglevel.

My solution might not be ideal, but I think it's still more optimal to drop those packets than to keep processing them throughout the whole networking stack, so yes, for the time being my current fix will remain there, as I haven't heard of any negative side-effect from it (and just in case, I did leave an nvram setting that allows disabling it).

 

[DaveMishSr]

One thing people will have to keep in mind however is, Asus is pushing new firmware releases as a neck breaking pace these days. So don't expect any release from me in the near future to be in sync with them, anything I release will always be a week or two behind Asus.

A week or two behind Asus?! I can live with that.

 

[jim769]

This is actually an interesting topic. Asus's solution in their new firmware releases has been to modify the Linux Kernel so the error message does not appear in Syslog's default loglevel.

My solution might not be ideal, but I think it's still more optimal to drop those packets than to keep processing them throughout the whole networking stack, so yes, for the time being my current fix will remain there, as I haven't heard of any negative side-effect from it (and just in case, I did leave an nvram setting that allows disabling it).

Thanks Merlin your the best. And yes your fix has saved me many headaches with this most ridiculous issue.

 

[jollywombat]

Looking forward to the release as well. Just upgraded to the RT-AC87 and realized I no longer have my OpenVPN server available on it like I did on my AC66

Thanks for all you do Merlin!

 

[nagle3092]

Looking forward to the release as well. Just upgraded to the RT-AC87 and realized I no longer have my OpenVPN server available on it like I did on my AC66

Thanks for all you do Merlin!

Its not the same but its still there, just go under VPN client and add it. Works fine for me with Airvpn.

 

[initrd]

Hi Guys...

This is my first post woot! I just bought my first Asus product. (previously I was in world of Netgear + DDWRT)

I just bought a AC87 and learning about MerlinWRT.

My current firmware is:

RT-AC87U_3.0.0.4_376_2044-g338a0a0

Every time I am trying to make any change in the Wireless - General page for 5G on applying the changes it goes into a infinite loop :-( for hours together it keeps showing applying settings....

Is anyone else facing this issue ?

Thanks,
Init

 

[RMerlin]

Hi Guys...

This is my first post woot! I just bought my first Asus product. (previously I was in world of Netgear + DDWRT)

I just bought a AC87 and learning about MerlinWRT.

My current firmware is:

RT-AC87U_3.0.0.4_376_2044-g338a0a0

I think you are confusing things here.

Asuswrt is the firmware developed by Asus - this is what you have on your router.
Asuswrt-Merlin (there is no MerlinWRT) is a third party firmware intended for Asus routers. At the time I'm writing this there is still no public release of Asuswrt-Merlin for the RT-AC87U.

 

[RMerlin]

Can any of you with an RT-AC87U do a simple test for me?

First, make sure you have a computer plugged on LAN port 1.

Enable Telnet, then telnet into the router, and run the following command:

et port_status all

Does it show as being Down?

Also please specify which FW version you are running (1779 or 2044).

Trying to figure out if this is due to an odd HW configuration by Asus to handle the QTN SoC or something else going on. Could be a HW design limitation since I noticed that that port doesn't work in Firmware Recovery mode either (and it's not a defective port, as my first engineering sample also had the same behaviour while in CFE).

Aside from that, I have zero problem with the computer on that port (it's in fact from where I ran my USB performance tests). It just means that accurate port status monitoring will be impossible in Asuswrt-Merlin (I have the same odd display from robocfg).

 

[lilstone87]

This is what its showing for me Merlin.

RT-AC87R:/tmp/home/root# et port_status all
Port Link Speed(Mbps) Duplex
---- ---- ----------- ------

0 Up 1000 Full
1 Down
2 Up 1000 Full
3 Down
4 Down

Pc was connected on lan port 1, and switch connected to lan ports 3. I find it odd showing lan port 2 as up.

Edit: Firmware 2044

 

[usmarine0622]

Can any of you with an RT-AC87U do a simple test for me?

First, make sure you have a computer plugged on LAN port 1.

Enable Telnet, then telnet into the router, and run the following command:

et port_status all

Does it show as being Down?

Also please specify which FW version you are running (1779 or 2044).

Trying to figure out if this is due to an odd HW configuration by Asus to handle the QTN SoC or something else going on. Could be a HW design limitation since I noticed that that port doesn't work in Firmware Recovery mode either (and it's not a defective port, as my first engineering sample also had the same behaviour while in CFE).

Aside from that, I have zero problem with the computer on that port (it's in fact from where I ran my USB performance tests). It just means that accurate port status monitoring will be impossible in Asuswrt-Merlin (I have the same odd display from robocfg).

This is what I get firmware 2044

0 Up 1000 Full
1 Up 1000 Full
2 Down
3 Down
4 Down

 

[RMerlin]

Now that's odd. Two on 2044, and you get different results with that LAN port.

If others can also post their results (either with 1779 or 2044) that'd be appreciated.