[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[JPtjee]

I'll take a look into it....right now I've locked down the Beta to get a public release out. I was suffering from 'content creep' and was never going to get it out.

I hope so. That would be great, because more people are having these issues. Thanks again for your help.

 

[cybrnook]

U da man John! Keep it up good sir.

 

[john9527]

Update-07 Public BETA

The BETA is closed

BETA RELEASE: Update-07B4
9-January-2015
Merlin fork 374.43_2-07B4j9527
Download - No longer available
Note this is a different location from the stable release
===============================

As I mentioned previously, I'm first making this release available as a BETA, primarily due to the IPv6 fixes unique to this fork. Unfortunately, I'm not yet IPv6 enabled, so can only do some basic testing on these fixes. Due to some late breaking items I wanted to get included, we're now at a BETA4 release level. A detailed Changelog can be found in the download directory.

HighLights:

• Includes Merlin's temporary fixes for ASUS infosvr LAN-side security vulnerability
  
• OpenVPN updated to 2.3.6, including an upstream fix for Cipher-None.
  
• Support for the AC68P. I did find some unique 68P code regarding the 5G wireless parameters buried in the 376 release which have been backported. If you are an AC68P user, feedback would be appreciated.
  
• IPv6 fixes for Stateful DHCP-PD, 6in4 tunnel configuration and MTU advertisement for PPP IPv6 connections
• IPv6 fix for a Comcast buffer overflow condition and a potential performance improvement for Comcast IPv4 connections (both ported from Shibby Tomato)
  
• Miscellaneous gui fixes correcting the inability to modify some fields and more flexibility in manually setting the transmit power above 200mW
• A potential fix for power settings not being properly applied without a reboot - please provide feedback
  
• Some new features....
  • 
    [*] You can now display the Traffic Monitor graphs in Mb/s instead of KB/s
    [*] You can now specify different address : port combinations for SSH access (different ports for WAN vs LAN access). If you were using the previous release of the fork SSH address feature, you should clear that value before loading this code.
    ​

The new features and one of the fixes require setting of an nvram variable to become active. Details can be found in the Merlin_Fork_Options.txt file in the download directory.

A factory default reset is NOT required if coming from any level of the fork or Merlin 374 code. Coming from any other level does require a factory default reset after the code is loaded.

SHA256 hashes:

edc05d2b0c2ab194fa0d78767aa5022b5f30e5605301343a1c0064f449d119c8 *RT-AC56U_3.0.0.4_374.43_2-07B4j9527.trx
bcc08e251762174fdfdc8396c58ab530474e685a3bccde1d05e8da4eb9cf5eb4 *RT-AC66U_3.0.0.4_374.43_2-07B4j9527.trx
56b239eff2a2edfe49c4481e00575e6c584b06c2f75629ca72ec49444e886bcf *RT-AC68U_3.0.0.4_374.43_2-07B4j9527.trx
3366eaaa41bf51c913994f89e2164e93673acdfb0aa563e39a656fb66982f442 *RT-N16_3.0.0.4_374.43_2-07B4j9527.trx
b1c5ac434916939b0a5c150b86d72bab096adbca3cab9544a2385dcb4c413c27 *RT-N66U_3.0.0.4_374.43_2-07B4j9527.trx

Thanks to everyone for your support (and your interest in this next update) !

 

[penguin22]

Loaded the new beta on my RT-N66, which has been working with Comcast IPv6 to this point and it initially looked like it wasn't working.

After a restart however, I saw the following IPv6 related entries in the log:
Jan 9 17:47:53 rdnssd[475]: Get IPv6 address & DNS from DHCPv6
Jan 9 17:47:53 rc_service: rc 478:notify_rc start_dhcp6c
Jan 9 17:52:06 rc_service: dhcp6c-state 491:notify_rc start_radvd
Jan 9 17:52:06 rc_service: dhcp6c-state 491:notify_rc start_httpd
Jan 9 17:52:06 rc_service: waitting "start_radvd" via dhcp6c-state ...

After waiting a little longer I pulled an IPv6 address around 17:54 and clients are connected properly having tested with test-ipv6.com. So it seems that getting the WAN address from Comcast may take some time, but does eventually work, at least from my testing.

I will be loading this onto my RT-AC66 (in AP mode) and resetting to factory and will update later tonight.

 

[john9527]

Loaded the new beta on my RT-N66, which has been working with Comcast IPv6 to this point and it initially looked like it wasn't working.

After a restart however, I saw the following IPv6 related entries in the log:
Jan 9 17:47:53 rdnssd[475]: Get IPv6 address & DNS from DHCPv6
Jan 9 17:47:53 rc_service: rc 478:notify_rc start_dhcp6c
Jan 9 17:52:06 rc_service: dhcp6c-state 491:notify_rc start_radvd
Jan 9 17:52:06 rc_service: dhcp6c-state 491:notify_rc start_httpd
Jan 9 17:52:06 rc_service: waitting "start_radvd" via dhcp6c-state ...

After waiting a little longer I pulled an IPv6 address around 17:54 and clients are connected properly having tested with test-ipv6.com. So it seems that getting the WAN address from Comcast may take some time, but does eventually work, at least from my testing.

I will be loading this onto my RT-AC66 (in AP mode) and resetting to factory and will update later tonight.

Did you previously have the problem where it sometimes took several reboots to get an IPv6 address?

 

[penguin22]

Did you previously have the problem where it sometimes took several reboots to get an IPv6 address?

No, although I have had to not rename admin otherwise IPv6 stopps working entirely. I know Merlin said it was an issue a while back, but I have not tested to see if it is fixed in your firmware fork.

 

[john9527]

No, although I have had to not rename admin otherwise IPv6 stopps working entirely. I know Merlin said it was an issue a while back, but I have not tested to see if it is fixed in your firmware fork.

Nothing that I did on purpose would change that (actually, first I've heard of that restriction on 'admin' related to IPv6).

Keep the feedback coming....thanks!

 

[penguin22]

Ok, just finished the RT-AC66 (in AP mode), which is connected to an EA-N66 (media bridge) connected to the RT-N66 (non-conflicting channel to the AC66).

I decided to gamble and changed the admin to a different name on factory reset since I was coming from Merlin's latest build. IPv6 is working perfectly and the range and RSSI from the AC66 is much better as I can bump the 5GHz TX power in your firmware without the restriction. I had used SSH to manually set it in the 376 build, but don't know if it was working and the signal did not seem too much better.

So this build has measurably better signal strength in my application, fully functional IPv6 even when renaming the admin, and will stay on my devices until you post a newer update.

You had mentioned ending this build series in favor of one based on the 376 builds, but if the TX restrictions are enforced and cannot be adjusted, please reconsider. I can tell you that there are no other 5GHz signals in my area, which is what I am boosting and the performance of your builds are remarkable. Thanks to you and Merlin for all the hard work!!!

 

[penguin22]

Nothing that I did on purpose would change that (actually, first I've heard of that restriction on 'admin' related to IPv6).

Keep the feedback coming....thanks!

I took it one step further and changed the admin on both the N66 and AC66 with no impact on IPv6. It just works! Thank you again.

 

[Lotta Cox]

No issues with the new beta so far. TM working fine in Mb/s. Thx!

I am wondering if there could be a fix so when I log into the router, the attached hard drives don't have to spin up.
My WD Mybook takes a long time to spin up. That causes a long delay when logging in.
Or if the drives go to sleep while logged in and I click something else in the GUI, another long delay occurs while the drives spin up.

Jan 9 22:04:16 sd-idle-2.6[457]: spinning up /dev/sda after 3 mins 2 secs
Jan 9 22:04:21 kernel: xhci_hcd 0000:00:0b.0: WARN: Stalled endpoint
Jan 9 22:04:21 kernel: xhci_hcd 0000:00:0b.0: WARN: Stalled endpoint
Jan 9 22:04:46 sd-idle-2.6[457]: spinning up /dev/sdb after 3 mins 30 secs

I thought Merlin fixed it so there was no spin up on login.
Not a big deal for me. I am used to the delay.

AC-68U
AC-66U Repeater

 

[RMerlin]

No, although I have had to not rename admin otherwise IPv6 stopps working entirely. I know Merlin said it was an issue a while back, but I have not tested to see if it is fixed in your firmware fork.

John, check that there isn't a service getting started with a hardcoded username of "admin". Asus did that error a few times in the past, maybe one of the latest fixes occurred only after your branching out.

 

[john9527]

John, check that there isn't a service getting started with a hardcoded username of "admin". Asus did that error a few times in the past, maybe one of the latest fixes occurred only after your branching out.

Thanks for the hint....I'll take pass through the code (but it looks like it ended up OK when he tried changing it this time around).

Do you have any hints on the drive spin-up during logon comment from Lotta_Cox? I did a search through the commits and didn't find anything specific on that one.

 

[JPtjee]

An emergency update release...

STABLE RELEASE: Update-06E
9-January-2015
Merlin fork 374.43_2-06Ej9527
Download http://1drv.ms/1uChm3J
===============================

For those of you not yet ready to update to the latest 376.xx release, I have created an incremental update (fixpack) to 374.43_2. This build primarily backports some of the fixes of the later Merlin builds back to the 374.43_2 build.

Update-06E of the 374.43 update fork is now available. This is an emergency release for the stable build to pick up Merlin's temporary fixes for the ASUS infosvr LAN-side security vulnerability. THERE ARE NO OTHER CHANGES IN THIS RELEASE.

Highlights

- Includes Merlin's temporary fix for infosvr LAN-side security vulnerability

A factory default reset is NOT required if coming from any level of the fork or Merlin 374 code. Coming from any other levels does require a factory default reset after the code is loaded.


For those waiting on the Update-07 BETA release.....it will be posted later today (and also includes the infosvr fixes)

Works great from here, thanks!

 

[Chrysalis]

Time for a Public BETA...

BETA RELEASE: Update-07B4
9-January-2015
Merlin fork 374.43_2-07B4j9527
Download http://1drv.ms/1sDtB1V
Note this is a different location from the stable release
===============================

As I mentioned previously, I'm first making this release available as a BETA, primarily due to the IPv6 fixes unique to this fork. Unfortunately, I'm not yet IPv6 enabled, so can only do some basic testing on these fixes. Due to some late breaking items I wanted to get included, we're now at a BETA4 release level. A detailed Changelog can be found in the download directory.

HighLights:

• Includes Merlin's temporary fixes for ASUS infosvr LAN-side security vulnerability
  
• OpenVPN updated to 2.3.6, including an upstream fix for Cipher-None.
  
• Support for the AC68P. I did find some unique 68P code regarding the 5G wireless parameters buried in the 376 release which have been backported. If you are an AC68P user, feedback would be appreciated.
  
• IPv6 fixes for Stateful DHCP-PD, 6in4 tunnel configuration and MTU advertisement for PPP IPv6 connections
• IPv6 fix for a Comcast buffer overflow condition and a potential performance improvement for Comcast IPv4 connections (both ported from Shibby Tomato)
  
• Miscellaneous gui fixes correcting the inability to modify some fields and more flexibility in manually setting the transmit power above 200mW
• A potential fix for power settings not being properly applied without a reboot - please provide feedback
  
• Some new features....
  • 
    [*] You can now display the Traffic Monitor graphs in Mb/s instead of KB/s
    [*] You can now specify different address : port combinations for SSH access (different ports for WAN vs LAN access). If you were using the previous release of the fork SSH address feature, you should clear that value before loading this code.
    ​

The new features and one of the fixes require setting of an nvram variable to become active. Details can be found in the Merlin_Fork_Options.txt file in the download directory.

A factory default reset is NOT required if coming from any level of the fork or Merlin 374 code. Coming from any other level does require a factory default reset after the code is loaded.

SHA256 hashes:

edc05d2b0c2ab194fa0d78767aa5022b5f30e5605301343a1c0064f449d119c8 *RT-AC56U_3.0.0.4_374.43_2-07B4j9527.trx
bcc08e251762174fdfdc8396c58ab530474e685a3bccde1d05e8da4eb9cf5eb4 *RT-AC66U_3.0.0.4_374.43_2-07B4j9527.trx
56b239eff2a2edfe49c4481e00575e6c584b06c2f75629ca72ec49444e886bcf *RT-AC68U_3.0.0.4_374.43_2-07B4j9527.trx
3366eaaa41bf51c913994f89e2164e93673acdfb0aa563e39a656fb66982f442 *RT-N16_3.0.0.4_374.43_2-07B4j9527.trx
b1c5ac434916939b0a5c150b86d72bab096adbca3cab9544a2385dcb4c413c27 *RT-N66U_3.0.0.4_374.43_2-07B4j9527.trx

Thanks to everyone for your support (and your interest in this next update) !

Ok I will try to report back ASAP on the ipv6 fixes, thanks.

 

[Benna]

I've just update my N66U from older 276 to 374_6 fork release , and the first thing i noticed switching the firmware is that Wako Ok LAN feature no more works.
I mean, sending magic packet from the site http://www.wakeonlan.me/ the laptop turns on, so the magic packet starts from the site, arrives to the router and it is forwarded to the correct MAC address, but if i try to turn the laptop on via the router interface, nothing happen, and this was not the case with the old firmware.

Does anybody know if this is a known bug ?

 

[RMerlin]

Thanks for the hint....I'll take pass through the code (but it looks like it ended up OK when he tried changing it this time around).

Do you have any hints on the drive spin-up during logon comment from Lotta_Cox? I did a search through the commits and didn't find anything specific on that one.

No idea. Disk power management is only partly under the router's control, so it's difficult to troubleshoot.

 

[john9527]

I've just update my N66U from older 276 to 374_6 fork release , and the first thing i noticed switching the firmware is that Wako Ok LAN feature no more works.
I mean, sending magic packet from the site http://www.wakeonlan.me/ the laptop turns on, so the magic packet starts from the site, arrives to the router and it is forwarded to the correct MAC address, but if i try to turn the laptop on via the router interface, nothing happen, and this was not the case with the old firmware.

Does anybody know if this is a known bug ?

I'm not aware of any bug with WOL (and haven't changed anything there from the base Merlin code).

What OS on your laptop and and how is it connected?

 

[ocram59]

I'm not aware of any bug with WOL (and haven't changed anything there from the base Merlin code).

What OS on your laptop and and how is it connected?

Hi All
I verified on RT-N66U and i can confirm that WOL does not work

To be sure that the cause was not in PC / OS configuration i used a WOL magic packet listener (on PORT 9 UDP9 on an already turned on PC and used that PC MAC address to send WOL packet from router.
Listener did not show any magic packet entering

I repeated the test sending WOL by LAN with Android and Listener correctly shown the Magic Packets

Same positive result when i Used WOL on WAN (I haad already configured everthing was needed to forward Magic Packets) and WOL correctly arrived to the listener

So there is something not working in WOL on router in this release

Best Regards
Ocram

 

[john9527]

@Ocram, which release did you use for the test, 6, 6E or the beta?

EDIT: I just tested Update-01, 06, 06E and 07B4 and all worked fine for me. Put PC to sleep, WOL from router.....PC wakes. Tested both static and DHCP address for the target PC on 07B4 (just in case that somehow played into it).

Also, I'm not sure I'd trust the WOL Listener app....I grabbed one, standalone 'WakeOnLanListener 2.0', and it didn't see anything even though the WOL was working. It didn't see both the router packet or a packet from my PC wol app. (I use a wol command line app from a remote HTPC to wake up my main HTPC/Media Server and that has been working fine as well).

 

[Jaded]

Hello John.... Can you elaborate on the IPv4 potential performance fix for Comcast customers?
...is this with IPv4 only... Or only for users using IPv6 and IPv4?

From notes:
IPv6 fix for a Comcast buffer overflow condition and a potential performance improvement for Comcast IPv4 connections (both ported from Shibby Tomato)


lastly... Do you have a paypal account for those who would like to thank you for your time on this endeavor?


Thank you for your time.