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

[john9527]

Thank you all for answers. My ISP it's RCS&RDS Romania and I was using IPV6 with build 3.0.0.4_374.43_2-06Ej9527 and worked without any problems.
Now I've switched back to merlin build 378.54_2 and it's working. When I have some time I'll do more tests.

I did a lot of work with another user with the same ISP/location trying to get it working unsuccessfully. But....at that time I didn't have the info that it used to work on V6. If you would, could you give it a try on V10 and see if it works there?

 

[razvanu]

Tested with V10, no IPV6
I've done like this: reset@default, upload firmware V10, hard reset@default, configured like in the atachement.

 

[john9527]

Tested with V10, no IPV6

OK....a change that went in to V10 was my first thought at a possibility, but that wasn't it.

If you'd consider trying to help out, could you start testing with V7 and working your way up until if fails (there's no need to do a factory reset in between the code loads, just try stopping and restarting IPv6 for each test).

 

[razvanu]

Tested with V7: I have no IPV6, It worked only with V6E(attached ss)
I will ask at softpedia forum if there is anyone else with this problem.

 

[john9527]

At least it failed with the first one you tried Thanks for helping to give me someplace to look (wouldn't have thought to go back that far)

 

[KGB7]

I also had to go back to V10. With V11 and V12, i had random internet cut off via LAN and Wifi at random times. Internet surfing is also snappier with v10.

No ipv6, no openvpn, no samba, no external HDDs, ... just plain vanilla set up for internet surfing.

Samy S4, Samy S5, iphone S4, iphone 6, 2x LG Tablets, Dell laptop(lan). Desktop PC is wired directly in to Fios modem.

 

[maurer]

no ipv6 here - rt-n16 with v12
native drom ISP (RDS - Romania)

 

[Chrysalis]

I also had to go back to V10. With V11 and V12, i had random internet cut off via LAN and Wifi at random times. Internet surfing is also snappier with v10.

No ipv6, no openvpn, no samba, no external HDDs, ... just plain vanilla set up for internet surfing.

Samy S4, Samy S5, iphone S4, iphone 6, 2x LG Tablets, Dell laptop(lan). Desktop PC is wired directly in to Fios modem.

This is odd considering a pretty nasty performance issue was fixed in v12 on the ac68 (it wasnt keeping buffers).

Ideally you need to give better feedback for the "internet cutoff" how was it cutoff? did you check logs.?

I use a samsung s5 with my ac68 on v12 fine as well.

 

[lesandie]

v12. openvpn working nice. The regeneration of the dh key was ok and also i activated the tls_min_ver 1.2 option in both openvpn client and server to force TLS1.2. rt-n66u
great work john.

 

[Deleted member 22229]

John what did you do different with IPv6 in V-12 ? I can honestly say it has never worked better. I am able to pull a V6 address every time now when my modem or router is rebooted on older builds it was hit and miss but V-12 is solid. Something has changed for the better or i need to start playing the lottery..

 

[Lotta Cox]

Why is it that with V12 I can log into the router without the 2 hard drives attached spinning up.
Haven't been able to do that in long time. Hope it stays that way.
Uptime 5 days 9 hours 41 minutes 29 seconds

 

[r00tz31820]

LATEST RELEASE: Update-12
20-June-2015
Merlin fork 374.43_2-12j9527
Download http://1drv.ms/1uChm3J
============================

For those of you not yet ready to update to the latest 376 or 378 releases, I have created an incremental update (fixpack) to 374.43_2. This fork is based on an older code release with a history of being very stable, and any changes are carefully weighed to preserve that stability.

Update-12 HighLights:

• Merlin Backports
  • Update OpenSSL to 1.0.2c
    This makes the move from the OpenSSL 1.0.0 stream to the latest 1.0.2 stream for this fork. This adds new ciphers and helps gets us ahead of the year-end EOL for OpenSSL 1.0.0.
  • Automatically update VPN Server to use a pre-generated 2048bit DH key if a key of less than 1024bits is found (previous default was 512bits).
    • IMPORTANT: Many OpenVPN clients are now being updated to require DH primes of at least 768 bits due to what has been dubbed the 'Logjam Attack' vulnerability. In addition, versions of OpenSSL starting with 1.0.2b will reject handshakes of less than 768 bits. Direction has been announced to require a 1024bit key in the future. This means:
      • If you are running the OpenVPN client on the router, you may need to request the owner of the VPN server to regenerate the DH key. It is expected that virtually all commercial VPN providers will already have DH keys that meet or exceed the 768bit requirement.
      • If you are running the OpenVPN server on the router, a pre-generated 2048bit DH key from RFC 3526 will be used during first time setup of the VPN Server, or your existing key will be updated to the pre-generated key the first time the Server is started after the firmware update.
      • You can still generate your own DH keys, as long as it is 1024bits or stronger using tools such as easy-rsa or the built in OpenSSL available via telnet/ssh on the router. Be aware that key generation on the router can take some time. For example, on an overclocked AC68U, it can take up to 5-10min for a 1024bit key, and 35-45min for a 2048bit key.
  • OpenVPN updated to 2.3.7
    This will automatically take advantage of the upgraded TLS support in OpenSSL 1.0.2 if it is available on both the server and client.
  • dnsmasq updated to version 2.73rc1.patch
  • miniupnpd updated to version 1.9.20150430
  • pppd updated to version 2.4.7
  • rp_pppoe synced with 378 codebase
  • Updated Entware install scripts
  • Merlin's latest revisions for OpenVPN policy based routing (up through master commit 22d91b1)
  • Fix for OpenVPN not restoring DNS servers with some provider configs
  • Wait for NTP sync before starting VPN servers/clients

• New Fork Updates
  • Removed the gui option to 'Allow local subnet forwarding' and made this the default
  • Fixed all the System Log pages so the scroll bars will only be visible under IE if they are needed
  • Updated formatting of the Routing Table status under System Log
  • Updated formatting of the IPv6 status under System Log if temporary addresses are in use
  • Fixed the wireless client count on the Sysinfo page to include guest clients
  • Client RSSI on the Wireless log page is now '??' if the information is not available or invalid (limitation of the older MIPS wireless drivers)
  • General performance improvement for ARM routers
  • Upstream maintenance for radvd
  • radvd will now quickly release IPv6 addresses when shutdown
  • New gui media server option to disable the media scan that occurs on every boot (will only update on change to media files)
  • Media Server now recognizes addition images as folder artwork, the full list is now:
    Folder.jpg/folder.jpg/Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Thumb.jpg/thumb.jpg
  • Disable the exclaimation point alert if allowing guest access for Samba or FTP

Some notes on this fork release....

The fork does include

• Maintenance for documented security issues
• Maintenance for supporting open source components (such as dnsmasq, miniupnpd, etc)
• Backports of applicable fixes and new functions from Merlin's main branch
• Some unique support for options requested by users
• Older versions of the wireless drivers that some feel offer better performance (especially on the MIPS based routers)
• A different IPv6 stack which may work better in some environments
• Less of a lockdown on tweaking power levels

The fork does not include

• The new TrendMicro DPI engine functions for ARM routers
• The enhancements to the networkmap for custom icons, client naming, etc.
• Some of the enhanced gui formatting of later releases, for instance the new wireless log
• All the changes/tweaks that ASUS may have made since the original code was released (and any newly introduced bugs )

The following routers are supported by this fork:

• N16, N66U, AC66U, AC56U, AC68U, AC68P (and the retail and color versions, R and W)

The following routers were released after the base code used for this fork was available, and are NOT supported.

• AC87U, AC3200 (and the retail R versions)

The custom features of the fork which are not exposed in the gui can be set by an nvram variable. All the custom features are documented in the Merlin_Fork_Options file in the download directory.

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

Thanks to @Chrysalis for getting the discussion started on the OpenSSL upgrade start and for his continued testing and feedback. Additional thanks to @Kal-EL and @GHammer for testing on early pre-release code.


Source: https://github.com/john9527/asuswrt-merlin : branch 374.43_2-update
SHA256 hashes:

4f196122b0e1c137a8d59e99e027a276714262c110740e0b2c13ac5580736cb3 *RT-AC56U_3.0.0.4_374.43_2-12j9527.trx
3f32b49bf0c51b736ccb70fc2e480366f5191b430d0898e9805197d632b7b55f *RT-AC66U_3.0.0.4_374.43_2-12j9527.trx
44725cff8d69ba434687f4fcfba7e5f03e911f9d1eacdf9373fac89bb8718db8 *RT-AC68U_3.0.0.4_374.43_2-12j9527.trx
aafc116642f598defba96904634ba95e011dc0deef78fb7ce7d8c2b33529f8bf *RT-N16_3.0.0.4_374.43_2-12j9527.trx
b29e478e43558c3ed63d0836abe00e297875d8afe0b6bf547931833bac1282e7 *RT-N66U_3.0.0.4_374.43_2-12j9527.trx

So I have been around this firmware since merlins first release on the ac66u.. I gotta say with this release... it was the best.. however with v12 of the fork.. for some reason despite a full reset before and after and proper setup.. range has dropped dramatically and I no longer get the full 1300mbs I only get 867 depite my best attempts on throught put and avg 600.. What happened man...? I am not sure how regulartory and stuff is handled.. but I lost a significant amount of power output.. zero networks around me.. middle of no where.. no military interference.. absolutley nothing has changed so I have narrowed it down to the recent v11 and v12 fork.. Any Ideas folks.. it would be much appreciated..

Also if we can bump the power up to the standard 500 mw for the US that would be great 200 is stupid.. and I have actually done extensive RF testing.. where 500 would benefit me over 200

I realize this doesnt include older drivers but you know what.. the version you forked from was AMAZING

 

[john9527]

John what did you do different with IPv6 in V-12 ? I can honestly say it has never worked better. I am able to pull a V6 address every time now when my modem or router is rebooted on older builds it was hit and miss but V-12 is solid. Something has changed for the better or i need to start playing the lottery..

Wow...something finally made a difference
Best guess, I made a small tweak in the IPv6 startup based on something I saw going through my logs that was not supposed to happen. I didn't affect me (running a 6in4 tunnel), but I put in a workaround none the less.

PS - I'd still buy a lottery ticket!

 

[john9527]

Why is it that with V12 I can log into the router without the 2 hard drives attached spinning up.
Haven't been able to do that in long time. Hope it stays that way.
Uptime 5 days 9 hours 41 minutes 29 seconds

Most likely a pleasant side effect of the performance enhancement that went in for ARM. The code was unnecessarily flushing it's buffers on a periodic basis and probably loosing track of data about the attached drives. (I actually hadn't noticed it, but I see the same thing )

 

[john9527]

I can't get openvpn to work on v12.

Just as an update for everyone...finally tracked down the problem that wiz was having with OpenVPN server on V12. It appears as if it was a timing issue on MIPS in setting paths/executing system commands...from all the posts, it looks like it may be configuration dependent and has always been there, but never was exposed until we starting relying on some functions that got used in the V12 update.

A special thanks to @wiz for providing endless amounts of data and trying all my debug builds!

A note for @RMerlin....add the full path for the openssl commands (2 places) in openvpn.c

 

[JZA80]

Having issues with v12 and openvpn. It worked fine on 11e1.

My setup consists of:

1. rt-n66u
2. openvpn running as server 1
3. self generated certs, key, dh
4. ca.crt, dh.pem, server.crt, and server.key contained in /jffs/ov.
5. dh.pem is 1024 bit

I did some troubleshooting / experimenting and whenever I start the openvpn server it would try and start, although it never does. I did see something about dh in the change log, so it might of been trying to generate a new dh.pem?

I removed the line (dh /jffs/ov/dh.pem) pointing to dh.pem in custom configuration under vpn details. Copied the contents of my dh.pem and placed it back into the gui (content modification of keys & certificates.) After this i started openvpn and it started right up like normal.

So I figure its something with the generation of a new dh.pem and not reading/loading the existing one I have from /jffs. Don't know why its trying to generate a new one, instead of using the one I already have.

 

[wiz]

Having issues with v12 and openvpn. It worked fine on 11e1.

My setup consists of:

1. rt-n66u
2. openvpn running as server 1
3. self generated certs, key, dh
4. ca.crt, dh.pem, server.crt, and server.key contained in /jffs/ov.
5. dh.pem is 1024 bit

I did some troubleshooting / experimenting and whenever I start the openvpn server it would try and start, although it never does. I did see something about dh in the change log, so it might of been trying to generate a new dh.pem?

I removed the line (dh /jffs/ov/dh.pem) pointing to dh.pem in custom configuration under vpn details. Copied the contents of my dh.pem and placed it back into the gui (content modification of keys & certificates.) After this i started openvpn and it started right up like normal.

So I figure its something with the generation of a new dh.pem and not reading/loading the existing one I have from /jffs. Don't know why its trying to generate a new one, instead of using the one I already have.

If you would read a bit back that's exactly what I had. In V12 there's being checked if your dh.pem is 1024 or bigger. Somewhere in that process something went pear shape and caused openvpn not to start. As John stated in a few posts back he found out what caused it and my guess is John will put a new V12 version out for the RT-N66U that will work.

 

[john9527]

So I figure its something with the generation of a new dh.pem and not reading/loading the existing one I have from /jffs. Don't know why its trying to generate a new one, instead of using the one I already have.

The 374 code base has no concept of moving the certs/keys into jffs, it expects everything to be in nvram. So, when it does the check of the dh, it falls into a similar hole as the problem wiz had (the dh couldn't be validated, in wiz's case because the command failed, in your case because the nvram value wasn't valid). The workaround you came up with is good for now, it put a valid dh in nvram to pass the test, but the server will continue to use whatever dh you specify in the custom configuration. Also, the fix for wiz's problem won't hang things anymore, it will generate the dh in nvram but won't use it if you override it in custom config.

I'll have to think a bit if there is a better way to handle it when people move things to jffs. There are other things that also are affected by moving the certs/keys...such as generating the .ovpn file.

 

[JZA80]

I'll have to think a bit if there is a better way to handle it when people move things to jffs. There are other things that also are affected by moving the certs/keys...such as generating the .ovpn file.

The only issue i've experienced with that is when using the gui to generate/export a client.opvn file, the contents of ca.crt do not get inserted into the file.

If your moving the certs/keys to jffs, its just matter of opening them and copy/paste the contents into your .ovpn file. I copy/paste the client.crt and client.key into the .ovpn file, so its just one more thing to copy/paste the ca.crt.

Thanks for your reply about dh and jffs.

 

[Chrysalis]

Why is it that with V12 I can log into the router without the 2 hard drives attached spinning up.
Haven't been able to do that in long time. Hope it stays that way.
Uptime 5 days 9 hours 41 minutes 29 seconds

probably the buffer fix