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

[john9527]

Hello all! I've put up a beta refresh, V18B9.

BETA RELEASE: Update-18B9
7-June-2016
Merlin fork 374.43_2-18B9j9527
Download http://bit.ly/1UGjcOX
============================

Key changes over V18B1

• Updated OpenVPN, OpenSSL and dnsmasq
• Backported Merlin's experimental codel and fq_codel support for traditional QOS for the AC56U and AC68U (sorry, can't be supported on the MIPS based routers)
• Experimental changes to improve traditional QOS, including some level of bandwidth limiting
• Firmware is now packaged as a zip file (consistent with Merlin firmware releases)

If you use traditional QOS, please feedback if it provides any improvement.

The full ChangeLog over V17E8 is in the download directory and is also included in the zip file. As a reminder, if you are using the new dedicated Bandwidth Limiter QOS, you should be using either V18B1 or V18B9.

Notes on the V18B1 release can be found here....
http://www.snbforums.com/threads/fork-update-for-374-43-available-v17e8.18914/page-188#post-255754

Also note that loading the latest ASUS (380.3xxx) or Merlin-alpha releases (380.60) will prevent you from returning to this fork via the webui (some, but not all, have been able to go back via the firmware restoration tool or CFE mini server).

Have fun!

 

[jeff288]

Just tried qos on my 66u and it scored the same B (C or D with it off) on dslreports' bufferbloat test as Merlin .59. I think I could get it to an A if I tweaked it but I don't use it so never worried about it. But this fork has always been stable for me and no problems other than Main_ConnStatus_Content.asp on Firefox, it takes a while and you have to refresh a couple times, same as previous.

Considering the recent changes in 380.60, I think I'll stick with your firmware for a while until tested more. If I didn't like to experiment with different features, I'd stay on yours.

 

[Rhepius]

I have a problem with V18B9. When I set "Connect to DNS Server automatically" at the WAN-settings page to "Yes"...
it still uses the previously specified servers entered at "DNS Server1" & "DNS Server2". Even after clearing the fields and rebooting the router.

 

[john9527]

I have a problem with V18B9. When I set "Connect to DNS Server automatically" at the WAN-settings page to "Yes"...
it still uses the previously specified servers entered at "DNS Server1" & "DNS Server2". Even after clearing the fields and rebooting the router.

Didn't change anything with respect to the DNS servers in V18 that I'm aware of. Where are you looking to see the DNS servers?

A couple of things....
If you specify DNS Servers under LAN>DHCP Servers, they will override anything set on the WAN page.
Same if you use DNS Filters under Parental Controls.
Also, for wired clients, you may need to reboot the client to pick up any changes in the DNS servers.

 

[rtn66uftw]

Hello all! I've put up a beta refresh, V18B9.

BETA RELEASE: Update-18B9
7-June-2016
Merlin fork 374.43_2-18B9j9527
Download http://bit.ly/1UGjcOX
============================

Key changes over V18B1

• Updated OpenVPN, OpenSSL and dnsmasq
• Backported Merlin's experimental codel and fq_codel support for traditional QOS for the AC56U and AC68U (sorry, can't be supported on the MIPS based routers)
• Experimental changes to improve traditional QOS, including some level of bandwidth limiting
• Firmware is now packaged as a zip file (consistent with Merlin firmware releases)

If you use traditional QOS, please feedback if it provides any improvement.

The full ChangeLog over V17E8 is in the download directory and is also included in the zip file. As a reminder, if you are using the new dedicated Bandwidth Limiter QOS, you should be using either V18B1 or V18B9.

Notes on the V18B1 release can be found here....
http://www.snbforums.com/threads/fork-update-for-374-43-available-v17e8.18914/page-188#post-255754

Also note that loading the latest ASUS (380.3xxx) or Merlin-alpha releases (380.60) will prevent you from returning to this fork via the webui (some, but not all, have been able to go back via the firmware restoration tool or CFE mini server).

Have fun!

Thanks John for the update! Can you push your recent changes to GitHub? The last push was like 6 months ago

 

[ryan806]

Hello all! I've put up a beta refresh, V18B9.

BETA RELEASE: Update-18B9
7-June-2016
Merlin fork 374.43_2-18B9j9527
Download http://bit.ly/1UGjcOX
============================

Key changes over V18B1

• Updated OpenVPN, OpenSSL and dnsmasq
• Backported Merlin's experimental codel and fq_codel support for traditional QOS for the AC56U and AC68U (sorry, can't be supported on the MIPS based routers)
• Experimental changes to improve traditional QOS, including some level of bandwidth limiting
• Firmware is now packaged as a zip file (consistent with Merlin firmware releases)

If you use traditional QOS, please feedback if it provides any improvement.

The full ChangeLog over V17E8 is in the download directory and is also included in the zip file. As a reminder, if you are using the new dedicated Bandwidth Limiter QOS, you should be using either V18B1 or V18B9.

Notes on the V18B1 release can be found here....
http://www.snbforums.com/threads/fork-update-for-374-43-available-v17e8.18914/page-188#post-255754

Also note that loading the latest ASUS (380.3xxx) or Merlin-alpha releases (380.60) will prevent you from returning to this fork via the webui (some, but not all, have been able to go back via the firmware restoration tool or CFE mini server).

Have fun!

Hi John. I have been using the latest official beta firmware for my N66U (380) Would I have any problems flashing this?

 

[john9527]

Hi John. I have been using the latest official beta firmware for my N66U (380) Would I have any problems flashing this?

If your firmware level is 380.3xxx you won't be able to flash from the gui. You may be able to flash using the firmware restoration tool or the CFE mini server.

 

[mobileman88]

Should i be concerned about the error in the logs below on a AC68u with this latest build?


Jan 1 08:00:35 start_nat_rules: apply the nat_rules (/tmp/nat_rules)!
Jan 1 08:00:35 rc_service: waiting "start_firewall" via udhcpc ...
Jan 1 08:00:39 start_nat_rules: (/tmp/nat_rules) cancelled!

 

[john9527]

Should i be concerned about the error in the logs below on a AC68u with this latest build?


Jan 1 08:00:35 start_nat_rules: apply the nat_rules (/tmp/nat_rules)!
Jan 1 08:00:35 rc_service: waiting "start_firewall" via udhcpc ...
Jan 1 08:00:39 start_nat_rules: (/tmp/nat_rules) cancelled!

No, nothing to be concerned about. That's part of my boot 'hardening' that I did on the code.

Without getting too deep, the router generates and applies two sets of NAT rules during boot. A basic set, then a more specific set which adds information that is unique to your configuration and totally replaces the first. Unfortunately this process is a race. In the case you found, the router had generated (and maybe even already applied) the second set before it could apply the first set. So, the application of the first set gets 'cancelled'.

The other one you may see is where a NAT rules is logged as 'waiting'. In this case, the router is actually trying to apply both sets at the same time. I added a lock so that the second set would always be added after the first set, and it waits for the first set to complete.

This scenario, where the first rule set could overlay the second is a big part of what was causing no internet access after a reboot.

 

[cowst]

No, nothing to be concerned about. That's part of my boot 'hardening' that I did on the code.

Without getting too deep, the router generates and applies two sets of NAT rules during boot. A basic set, then a more specific set which adds information that is unique to your configuration and totally replaces the first. Unfortunately this process is a race. In the case you found, the router had generated (and maybe even already applied) the second set before it could apply the first set. So, the application of the first set gets 'cancelled'.

The other one you may see is where a NAT rules is logged as 'waiting'. In this case, the router is actually trying to apply both sets at the same time. I added a lock so that the second set would always be added after the first set, and it waits for the first set to complete.

This scenario, where the first rule set could overlay the second is a big part of what was causing no internet access after a reboot.

And that's awesome

 

[janosek]

Hello,

I have jumped ship to John's fork with the news that 380.60 will prevent flashing older versions. I am on V18B9 with my AC66U. So far so good. It feels like a natural break for John to take over MIPS router support from RMerlin. My .02

 

[Livin]

Question on Guest Wifi Network setting... I'm running two AC68R with 3.0.0.4.374.43_2-17E8j9527. I went to create 2 separate guest networks, one on each AC68 and the setting 'Access Intranet' was only available on the unit with Operation Mode set to "Wireless router" but not the other which is set to "Access Point(AP) mode"

why?

I'd like to have 2 separate guest networks that both can connect to the Intranet.

thx for the help

 

[ColinTaylor]

I'd like to have 2 separate guest networks that both can connect to the Intranet.

You already have that with the access point.

The access point is plugged into one of the LAN ports on the router. The router has no way of differentiating traffic coming from the access point from any other traffic on the LAN, therefore all clients connected to the access point have access to both the intranet and internet. That is why that option is not available.

 

[Livin]

You already have that with the access point.

The access point is plugged into one of the LAN ports on the router. The router has no way of differentiating traffic coming from the access point from any other traffic on the LAN, therefore all clients connected to the access point have access to both the intranet and internet. That is why that option is not available.

I'm not sure this is accurate or I don't understand how this can be the case since they are completely separate WIFI networks (SSIDs) on separate routers.

On the main AC68R (mode: Wireless router) the WIFI Guest network 'Secure1' has the option to 'Access Intranet' to On/Off.
On the secondary AC68R (mode: Access Point) the WIFI Guest network 'Secure2' does NOT have the option to 'Access Intranet' to On/Off.

... these are completely separate WIFI Guest networks - setup separately on each ASUS AC68R ... thus they are not 'pass through'

@john9527 - can you help me understand? thx

 

[slobodan]

Then set it to Wireless router, instead of Access Point.

 

[john9527]

Then set it to Wireless router, instead of Access Point.

Said in a slightly different way from @ColinTaylor , by default both the wireless connections to the router and the wireless connections to the access point have access to BOTH the internet and the intranet. On the router, it's possible to prevent the intranet access by setting up some rules for the wireless networks since the router is handling all the routing...you have an option to 'uncheck' the intranet access. On the AP this isn't possible since none of the routing is happening there and from the routers perspective all the AP connections are handled the same as a wired lan connection.

 

[ColinTaylor]

@Livin I don't wish to sound insulting but are you perhaps misunderstanding the difference between internet and intranet? Or maybe we don't quite understand how you have your 2 routers connected together.

 

[tyspeed42]

Running 18B9 on both my AC68U, AC68W, running excellent. Thanks John.

 

[Livin]

Said in a slightly different way from @ColinTaylor , by default both the wireless connections to the router and the wireless connections to the access point have access to BOTH the internet and the intranet. On the router, it's possible to prevent the intranet access by setting up some rules for the wireless networks since the router is handling all the routing...you have an option to 'uncheck' the intranet access. On the AP this isn't possible since none of the routing is happening there and from the routers perspective all the AP connections are handled the same as a wired lan connection.

@john9527 - thx. I understand, though it kinda sux ;-) ... The AP is acting as an extender and though we can create a separate Guest SSID on the AP it does not provide all the same controls that a Guest SSID does on the Router. Problem with this is that using a Guest SSID on the AP partly (or fully) defeats the purpose of a "Guest" network - which people often/usually want to isolate from the Intranet. Would be nice if there was a way to have the AP tell the Router not to route packets to the Intranet if they come from a specific SSID.

 

[mobileman88]

@john9527 - thx. I understand, though it kinda sux ;-) ... The AP is acting as an extender and though we can create a separate Guest SSID on the AP it does not provide all the same controls that a Guest SSID does on the Router. Problem with this is that using a Guest SSID on the AP partly (or fully) defeats the purpose of a "Guest" network - which people often/usually want to isolate from the Intranet. Would be nice if there was a way to have the AP tell the Router not to route packets to the Intranet if they come from a specific SSID.