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

[RMerlin]

Is there a know way already to install your firmware when firmware .380 or higher is installed?

The instructions are in the first post of this thread.

 

[zonnebril]

The instructions are in the first post of this thread.

Omg.. sorry for that! Heading back to the first post. Thanks!

Edit: Worked! It took a fairly long time after it came up though... the restoration tool gave the following message after flashing: "Failed to connect to the wireless router. Check if the power led is blinking."

The router seemed up and running but was not reachable for 20 minutes or so... I resisted not to unplug the power...

So, just wait and for example setup a ping to the router's ip address. It will come up, total time for this operation was approx. 40 minutes.

 

[RMerlin]

The router seemed up and running but was not reachable for 20 minutes or so... I resisted not to unplug the power...

The RT-N66U uses slower flash, which can indeed take close to 40 minutes while in recovery mode.

 

[Lotta Cox]

Where can I get the CFE update file for the AC66?. It's not in the CFE folder in onedrive. Just the 56 and 68u are there.
My version is
Bootloader (CFE) 1.0.1.4
My AC68 is at 1.0.2.0 Is that what my 66U should be?

 

[john9527]

Where can I get the CFE update file for the AC66?. It's not in the CFE folder in onedrive. Just the 56 and 68u are there.
My version is
Bootloader (CFE) 1.0.1.4
My AC68 is at 1.0.2.0 Is that what my 66U should be?

No need to update the AC66 CFE....it's fine.

 

[Lotta Cox]

no
https://www.snbforums.com/threads/asus-routers-cfe-dumps-collection.17793/

So my 66 has the latest it looks like.
I see 1.0.2.5 for the 68. Is my 1.0.2.0 good enough? I don't want mess with it if I don't have to.

 

[RMerlin]

So my 66 has the latest it looks like.
I see 1.0.2.5 for the 68. Is my 1.0.2.0 good enough? I don't want mess with it if I don't have to.

Versions are model-specific, you can't compare them across different models.

 

[john9527]

Pushed a new beta ....can't let Merlin have all the fun!

Just as a note for everyone, I will be tied up on some personal business over the next several weeks, so may not be responding to every post (but will take note of them). Thanks!

BETA RELEASE: Update-23B8
29-January-2017
Merlin fork 374.43_2-23B8j9527
Download http://bit.ly/1UGjcOX
============================

Following are the major changes (full changelog is in the zip files)

Update-23B8 Highlights

• Security
  • Update OpenSSL to 1.0.2k
  • Update OpenVPN to 2.4.0
  • Samba fix CVE-2013-4124 Denial of service - CPU loop and memory allocation
• Other Updates
  • NEW: webui: add reset button to qos stats charts
  • NEW: ipv6: add scripts for ipv6 hosts auto update for native ipv6 (adds ipv6 name resolution to public address)
    To start this option, make or add the following lines to /jffs/configs/dnsmasq.conf.add
    

    dhcp-script=/usr/sbin/v6hosts.sh
    addn-hosts=/_etc/hosts.autov6  (remove the underscore, Cloudfare doesn't like specifying that directory)

  • CHANGED: webui: update to prevent entering too long a password
  • CHANGED: webui: update for Chrome version 56 changes
  • CHANGED: webui: change low nvram threshold for N16 to 1.5K (no openvpn certs)
  • CHANGED: webui: add dnscrypt unavailable message if openvpn dns option is relaxed or strict
    If you think about it, using dnscrypt with these options really doesn't make sense
  • CHANGED: build: expand jffs for ARM from 32MB to 64MB
    (ARM users, do like MIPS users and make a JFFS backup for safety just in case)
  • CHANGED: defaults: change wireless scheduler default to off
  • FIXED: qos: handle case of qos trying to start before wan is up
  • FIXED: httpd: always allow router address login if specified address only option is selected
  • FIXED: several fixes for properly updating the WAN timer in a dual wan environment
  • FIXED: several fixes for dual wan failover
  • Several kernel backports from Tomato and OpenWRT
  • Several backports from current Merlin releases

As always, a reminder to users with MIPS routers to have a backup of /jffs in case the jffs space needs to be reformatted due to increases in firmware size.

SHA256

b18f366b63bc08ea584fda817af36533b157fdd5851e5ea97a615da3eecbe52e  RT-AC68U_3.0.0.4_374.43_2-23B8j9527.trx
086c7b742522cbb09d20ef49322447cb3b38f1b131c92a792294ae6d261ae66b  RT-AC56U_3.0.0.4_374.43_2-23B8j9527.trx
2baab973baafaa5ea259279cf0591647ea6d305eb81b9e0be341e630810d44b2  RT-N16_3.0.0.4_374.43_2-23B8j9527.trx
f7044dc4cfa154974bb4319e5b72efa2dd6f381b4d6780040aff9ff4b6c06c8e  RT-AC66U_3.0.0.4_374.43_2-23B8j9527.trx
d2be254025169cf542ec63eb49db2c376403232c09d322ba1fb5b4f2ee3a3a48  RT-N66U_3.0.0.4_374.43_2-23B8j9527.trx

 

[john9527]

Hi @john9527, how are you? I have a couple comments this time:
QoS question here: Do the rules apply to traffic originated in the router itself? let's say (hypothetically speaking here Mr. NSA) someone has a torrent client running on the router; would that traffic be subject to the QoS rules?

I don't believe so. The router itself is in a separate tc class (you wouldn't believe how slow the gui is if it participates)

I have just changed my dnscrypt resolvers (already activated) and a bunch of services were restarted but for some reason dnsleaktest.com still stated my prior dnscrypt resolvers were being used, until I issued a "service restart_dnscrypt" and tried again

Changing any of the dnscrypt options does a full restart of the WAN, so couldn't have been saved by the router. Most likely there was something cached in either your browser or the client dns cache.

I was looking at openvpn.c and if I understood correctly, for a client, when cryptMode=TLS the client.ovpn file only has "up" and "down" scripts depending on the selection on the DNS field (line 280). While that might make sense, updown.sh is responsible for calling openvpn-event and in cases where it is not included in the client.ovpn file, then the openvpn-event script would not be executed. I know I could add a "up openvpn-event" line if I wanted to, but that will in turn prevent updown.sh from being executed at all since OpenVPN will only execute the last script. At the end of the day, it feels inconsistent; don't you think updown.sh should always be there even when it would only be invoking openvpn-event?

Will have to find some time to dig in and try and follow what you are saying.

The cron job for the polling interval seems wrong, it executes "service vpnclient1 start" when it should execute "service start_vpnclient1"

Yep...it's a bug. Looks like it was fixed in one of Merlin's ASUS merges, so it wasn't explicity called out.

Is there a reason why vpn certs have not being mvoed from nvram to jffs as in Merlin? I know it probably happened after this fork, but I am just guessing why it did not follow along when it could be a huge nvram space save, right?

Just the amount of change to implement it the way ASUS did and the fact it would then break the ability to move between the fork versions for VPN users. And I only support 2 each servers and clients, vs 2 servers and 5 clients for Merlin. And it's easy to implement manually....
- Just put at least a dummy character in the gui for the cert you want to move (I put in the path to the cert)
- Add a line in the custom config pointing to the appropriate cert path/name
I've thought about allowing you to put the path to the cert in the gui, then handling things...but have never got around to it.

 

[jrmwvu04]

Loaded the new build.

FIXED: qos: handle case of qos trying to start before wan is up

I haven't had any problems over the past couple of days, wouldn't you know. I did see the qos-init change in the syslog on boot. It wasn't exactly a major problem to begin with, but I'll keep an eye on it.

Also, jffs expanded with no issue.

 

[john9527]

I haven't had any problems over the past couple of days, wouldn't you know. I did see the qos-init change in the syslog on boot.

Always the way.....as I said, I ultimately don't think that was the problem in your case, but I had already written the fix to cover that case, so left it included.

 

[Santiago C]

Hi @john9527! I have updated to 23B8 and found out I had the same issue as in prior betas that was not happening in 22E4: whenever I start the OpenVPN client, the current wan line gets disconnected until I restart the firewall.

I have disabled all my custom ovpn config but still the issue persist (with a PIA standard config that would be). While the wan is detected down and the actual failover happens, I cannot get a ping reply from my wandog target (8.8.8.8) until I do a service restart_firewall.

Can that be related to the change you made to wandog to get the ping done from the specified interface?

 

[punchsuckr]

Hey John, getting the following messages with a frequency of every other day to twice in a day, allow only specified IP is off.

watchdog: restart httpd - SSL, error detected or process not responding (28)
Feb  2 23:01:14 rc_service: watchdog 443:notify_rc stop_httpd
Feb  2 23:01:14 rc_service: watchdog 443:notify_rc start_httpd
Feb  2 23:01:14 rc_service: waiting "stop_httpd" via watchdog ...
Feb  2 23:01:15 httpd: start httpd - SSL

As noted earlier, similar messages with ssl disabled would only appear with allow only specified IP enabled and router's own IP not added to that list (which you fixed in the latest beta). Going to try the beta and see if it persists.

 

[john9527]

Hey John, getting the following messages with a frequency of every other day to twice in a day, allow only specified IP is off.

watchdog: restart httpd - SSL, error detected or process not responding (28)
Feb  2 23:01:14 rc_service: watchdog 443:notify_rc stop_httpd
Feb  2 23:01:14 rc_service: watchdog 443:notify_rc start_httpd
Feb  2 23:01:14 rc_service: waiting "stop_httpd" via watchdog ...
Feb  2 23:01:15 httpd: start httpd - SSL

As noted earlier, similar messages with ssl disabled would only appear with allow only specified IP enabled and router's own IP not added to that list (which you fixed in the latest beta). Going to try the beta and see if it persists.

That looks like a real error detection......the watchdog attempted to check that the router could respond over https and it never received a response after 10 sec. This can happen if you hit the right window trying to login from different clients at the same time. The good news is that this could lock up the https access, but this check will break it free.

 

[john9527]

Hi @john9527! I have updated to 23B8 and found out I had the same issue as in prior betas that was not happening in 22E4: whenever I start the OpenVPN client, the current wan line gets disconnected until I restart the firewall.

I have disabled all my custom ovpn config but still the issue persist (with a PIA standard config that would be). While the wan is detected down and the actual failover happens, I cannot get a ping reply from my wandog target (8.8.8.8) until I do a service restart_firewall.

Can that be related to the change you made to wandog to get the ping done from the specified interface?

Are you using policy based routing? If so, try excluding the router ip from participating in the VPN (set it to WAN)

 

[Santiago C]

Are you using policy based routing? If so, try excluding the router ip from participating in the VPN (set it to WAN)

No, redirecting all traffic. Weirdest thing is it starts working after restarting the firewall and I couldn’t see anything odd in the start_firewall function (22E4 at least, last source available)
I’m guessing either the wandog changes or some iptables rules that are misplaced when the VPN starts but get properly sorted out when restarting the firewall?

 

[punchsuckr]

That looks like a real error detection......the watchdog attempted to check that the router could respond over https and it never received a response after 10 sec. This can happen if you hit the right window trying to login from different clients at the same time. The good news is that this could lock up the https access, but this check will break it free.

Another good news is I haven't yet seen this error on B8 yet. Will check again after a few days of uptime.

 

[john9527]

No, redirecting all traffic. Weirdest thing is it starts working after restarting the firewall and I couldn’t see anything odd in the start_firewall function (22E4 at least, last source available)
I’m guessing either the wandog changes or some iptables rules that are misplaced when the VPN starts but get properly sorted out when restarting the firewall?

Since you are redirecting all traffic....switch to policy rules with a rule that covers your entire subnet (192.168.1.1/24 for example), then add an exclude for the router address.

Also take a
iptables -nvL >savefile.txt

before and after your restart (different file names of course)

Also, does dual wan work correctly if you have the VPN disabled? I can envision MANY places where the two could be incompatible.

 

[punchsuckr]

Another good news is I haven't yet seen this error on B8 yet. Will check again after a few days of uptime.

Nah got it after a few hours.

 

[john9527]

Nah got it after a few hours.

Something is hanging up https or keeping it too busy to respond. I use curl for the check, and the (28) is the curl return code which is a timeout. Just speculating, but do you have a lot of syslog activity going on (do you have packet logging on for example)?

As long as it doesn't repeat one right after one another, it means its breaking whatever it is free by restarting https.