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

[njespo]

my condolences John

 

[ualdrivr]

Curious thing! After upgrading to 15E5 I noticed that quality and strength of the 5GHz on my 68U router had dropped down to 30% - 35% at the furthest corner of my house were my Linksys Bridge WUMC710 is located. Mind you that the signal there was always around 75% with all previous version of @john9527 I couldn't live with it. The Linksys extender RE6500 in the house was showing the 5Ghz at three bars at best with the 15E5 firmware, poor strength and quality. The 2.4GHz was showing normal levels all the time.

I flushed the 14E1 back to the Router, rebooted and presto, signal back to normal levels at the bridge and the extender. Anyone else noticed something like that with their 68U on the 5GHz side? I think I'll stay with the 14E1 for a bit, see how things turn up.

Just a quick update on my previous post above. I did a sight survey under the Wireless tab of GUI and I found out this. A few of my neighbors have gone back to Optimum Cable Internet services. Now, the way they do it is they give you the modem and the router, but once you are theirs the router becomes a Hot Spot for Optimum WiFi. The sight survey reviled that Optimum WiFi's 5GHz signal transmits on channel 149, that was the channel that until now my 68U was transmitting on. Obviously the channel was saturated. I changed mine to channel 153 and the strength/quality of the 5GHz signal came back where it was. Conclusion? @john9527 Firmware update had nothing to do with it, nor did beam forming. I had to investigate further, because it was killing me.

I probably won't be putting out a formal release until after the New Year, but in case anyone wants to try out the latest I've uploaded a Beta release. (It's what I'm currently running )
Note it's a different download location from the stable release location.

BETA RELEASE: Update-16B5
11-December-2015
Merlin fork 374.43_2-16B5j9527
Download http://1drv.ms/1sDtB1V
============================

Changelog

• Updated OpenSSL to 1.0.2e
• Did my own code review and closed multiple buffer overflow exposures
• Updated e2fsprogs to latest Merlin level
• Increased max Parental Controls to 32
• Updated entware install script to entware-ng
• Added support for igmpproxy customization
• Fixed Smart Sync not syncing after start (ASUS binary updates) - @DocUmibozu
• Fix router failure at boot if NFS is active - @ziolupo
• Add valid ip address check/retries/logging to QoS start - @strangeluck
• Add new option to System Log>Connections to display connection count summary - @UserEasy
• Fix vendor lookup from the networkmap client status - @Wisiwyg
• NTP Updates
  • Show successful NTP syncs in syslog by default
    The successful sync logs can be disabled in the gui in the Syslog options, failures will always be shown
  • Allow changing the alternate NTP server in the gui (the router already actually used 2 NTP servers, this just externalizes the second server)
  • Allow changing the time between NTP syncs in the gui
    Note: Setting the sync interval to '0' disables sync attempts and tells the router to accept as valid whatever time is set (useful when the router is not connected to the internet, and the time is set manually via the command line (use with caution) - @dasbrot)

@john9527 After all the heartache above, I did flash the 16 Beta version on my 68U and all's well!

 

[john9527]

Now, the way they do it is they give you the modem and the router, but once you are theirs the router becomes a Hot Spot for Optimum WiFi. The sight survey reviled that Optimum WiFi's 5GHz signal transmits on channel 149, that was the channel, that until now my 68U was transmitting on. Obviously the channel was saturated. I changed mine to channel 153 and the strength/quality of the 5GHz signal came back where it was.

Great detective work! This is likely to be more common and something that people may need to keep an eye on (I've read Optimum, Comcast/Xfinity and maybe TWC are all doing this).

 

[Deleted member 22229]

Great detective work! This is likely to be more common and something that people may need to keep an eye on (I've read Optimum, Comcast/Xfinity and maybe TWC are all doing this).

It is becoming very common and at least with comcast the hot spot can be turned off. Unfortunately 99% of customers dont even know they are broadcasting a hot spot or that it can be disabled.

 

[john9527]

This is very sad news John are you 100% sure this is the case. Also is this only for the 68? Will you continue to support other models or is it a moot point after the change ?

Unfortunately I'm pretty sure this is the case. But, I have no plans to change what is supported for as long as the fork continues (still will support the AC68U rev B1.....that's me ). What I'm thinking about right now is how to handle the folks who try anyway with the later rev hardware....

 

[Deleted member 22229]

This is a bummer all the way around. I guess I am glad I picked up the 3100 now. I still have my N66 for a back up and will always use your builds for that router because it simply works the best. I for one John appreciate and have enjoyed all your work and look forward to what you can support in the future.

 

[RMerlin]

Unfortunately I'm pretty sure this is the case. But, I have no plans to change what is supported for as long as the fork continues (still will support the AC68U rev B1.....that's me ). What I'm thinking about right now is how to handle the folks who try anyway with the later rev hardware....

Just don't do anything. The 380 firmware on these will refuse to flash your builds (or my older builds).

 

[Nazgulled]

I wouldn't expect that this fork would behave any differently. The base of the fork is 374.43_2 and I haven't touched anything with respect to the modem support.


Coming for the base 374.43_2 you should just be able to load this code directly from the gui. I've added code such that any new features will be initialized without the need for a factory reset.
You didn't say what router you have, but I'd be sure to have a backup of your /jffs if you are using any custom scripts, particularly on the MIPS based routers. On the MIPS routers, jffs will most certainly be overwritten by the larger code size and will need to be reinitialized/reformatted.


See this thread for my NVRAM Save/Restore utility (it will also take care of backing up your jffs space). Always good to plan ahead
http://www.snbforums.com/threads/user-nvram-save-restore-utility-r22.19521/

I have an AC68U.

Yes, I have some scripts, I didn't forget about them

I'll be sure to look into that utility.

Thanks for all the clarifications.

 

[sbailey4]

Great detective work! This is likely to be more common and something that people may need to keep an eye on (I've read Optimum, Comcast/Xfinity and maybe TWC are all doing this).

Also to note TWC in my area setup theirs to use 40mhz on the 2.4 band! So those neighbors are stepping all over the place . I am in a suburban neighborhood with probably 25+ wifi networks that can be seen. With 3-4 of those new TWC using 40 mhz. Yeah one would think they would know better than to set up this way in a busy neighborhood. Geez. Definitely something to look at when there are wifi performance issues.

 

[Deleted member 22229]

Also to note TWC in my area setup theirs to use 40mhz on the 2.4 band! So those neighbors are stepping all over the place . I am in a suburban neighborhood with probably 25+ wifi networks that can be seen. With 3-4 of those new TWC using 40 mhz. Yeah one would think they would know better than to set up this way in a busy neighborhood. Geez. Definitely something to look at when there are wifi performance issues.

This is the very reason i dont use 2.4 Ghz any longer. Just not sure whats going to happen when 5 GHz becomes the new play ground.

 

[Wisiwyg]

A little tease for any Private Internet Access (PIA) VPN users. PIA released the 'secret sauce' that their client uses to set various options when negotiating the server connection......and with a bit of porting......

Dec 16 23:55:49 openvpn[3743]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1542'
Dec 16 23:55:49 openvpn[3743]: WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
Dec 16 23:55:49 openvpn[3743]: WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
Dec 16 23:55:49 openvpn[3743]: WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Dec 16 23:55:49 openvpn[3743]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Dec 16 23:55:49 openvpn[3743]: Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 16 23:55:49 openvpn[3743]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Dec 16 23:55:49 openvpn[3743]: Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 16 23:55:49 openvpn[3743]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Dec 16 23:55:49 openvpn[3743]: [Private Internet Access] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194

The WARNING messages are the defaults which are then overridden by the router VPN client.

Good to know! I've been looking into setting up AirVPN with the AC68U. There are instructions in the AirVPN site specific to settint their service up with AsusWRT (https://airvpn.org/asuswrt/). At the bottom of that post, there is a reference to AsusWRT-Merlin firmware, highlighting added/enhanced features!

 

[RocketJSquirrel]

I just noticed that the parameter TCP Timeout: Established is set to 432000 on my AC68U. I'm pretty sure I never changed any of these TCP settings on purpose because I don't really know what they do. Should I change it back to the default 2400?

 

[john9527]

I just noticed that the parameter TCP Timeout: Established is set to 432000 on my AC68U. I'm pretty sure I never changed any of these TCP settings on purpose because I don't really know what they do. Should I change it back to the default 2400?

The 432000 (7 days) was the old default. It was switched by ASUS and I picked up the change a while back. I thought I mentioned in the release notes to check it and manually reset it.....but maybe I I had a brain-check

 

[RocketJSquirrel]

Thanks for the reply, but... what should I do? Leave it at 432000 or change it to 2400? What are the units, btw?

 

[john9527]

Thanks for the reply, but... what should I do? Leave it at 432000 or change it to 2400? What are the units, btw?

Change to 2400....units are seconds....

 

[Nazgulled]

Guests means upper range of dhcp /24 block, i've set up dhcp to give out addresses from .129-.254 only, this corresponds to .128/25 which is easily defined as a qos rule. Own devices are with fixed dhcp reservations in .2-.126 range, corresponding to .0/25 , also easily defined.

How exactly do you set a QoS rule for an IP range?

 

[john9527]

How exactly do you set a QoS rule for an IP range?

The QoS rules also accept addresses that are are in CIDR format. It's basically a shorthand for entering a netmask. Rather than try to explain it here, there are lots of good examples you can find by searching the web. You can also find address range to CIDR calculators that will give you the CIDR entries you need to cover any specific address range.

 

[MuppetSoul]

A little tease for any Private Internet Access (PIA) VPN users. PIA released the 'secret sauce' that their client uses to set various options when negotiating the server connection......and with a bit of porting......

Dec 16 23:55:49 openvpn[3743]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1542'
Dec 16 23:55:49 openvpn[3743]: WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
Dec 16 23:55:49 openvpn[3743]: WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
Dec 16 23:55:49 openvpn[3743]: WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Dec 16 23:55:49 openvpn[3743]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Dec 16 23:55:49 openvpn[3743]: Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 16 23:55:49 openvpn[3743]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Dec 16 23:55:49 openvpn[3743]: Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 16 23:55:49 openvpn[3743]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Dec 16 23:55:49 openvpn[3743]: [Private Internet Access] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194

The WARNING messages are the defaults which are then overridden by the router VPN client.

Does this make always-on VPN for specific IP addresses turn key?

 

[john9527]

Does this make always-on VPN for specific IP addresses turn key?

You already have that today (it may depend on your provider and your custom config options), I've been running PIA 24X7 for a long time now.

With their client software running on a PC, you were able to set options that weren't available when running the client on the router. They released info on how they set the options, which I was able to port to the router. That's what my post was about.

 

[Nazgulled]

The QoS rules also accept addresses that are are in CIDR format. It's basically a shorthand for entering a netmask. Rather than try to explain it here, there are lots of good examples you can find by searching the web. You can also find address range to CIDR calculators that will give you the CIDR entries you need to cover any specific address range.

Cool, thanks

However, I got this error: "192.168.0.208/28 is not a valid IP address!"

One last thing, if I want to add a rule for a specific IP but for every service (every port), should I add nothing to the "destination port" or an "*"?