[Beta] Asuswrt-Merlin 380.65 Beta is now available

[GoNz0]

You kidding ? #3

Yeah I read that but the way it is worded I expected to find the script in the scripts folder

380.65 adds a new update-notification user script

Should read You can create a new update-notification user script

You have to create /jffs/scripts/update-notification yourself, set the permissions and fill in your edited details.

Thanks for clearing it up

 

[Wutikorn]

AB-Solution 3.1 will have it as an option.

Does it means that I can set AB-Solution to send me firmware upgrade notification as well as regular stats? In that case, I look forward to getting AB-Solution 3.1. When do you expect it to come out?

 

[XIII]

• Host file will give priority to the hostname you configure for your router, over the hardcoded router.asus.com (will show up when doing a traceroute or any other router IP resolution

Can I only use <name> (without dots), or also <name>.asuscomm.com?

The latter would be nice for using Let's Encrypt instead of self-signed certificates (without exposing the GUI to the outside world).

 

[thelonelycoder]

Does it means that I can set AB-Solution to send me firmware upgrade notification as well as regular stats? In that case, I look forward to getting AB-Solution 3.1. When do you expect it to come out?

Yes and soon.

 

[Martineau]

I can confirm that you have fixed the NSFW FORWARD rule creation, and all my scripts appear to execute correctly although I haven't yet got around to replacing my existing 'awk' emulation procedure with the new 'uniq' Busybox applet.

Also it seems that OpenVPN 2.4 is more intelligent (unless I haven't been quite so diligent in checking the syslog previously)...at least for my Client TCP TUN connections?

PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.200.197.1.....explicit-exit-notify 2,ifconfig 10.200.197.62 255.255.255.0'
OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp

However, the following OpenVPN 2.4 'Linux ip -6' error

openvpn[32272]: /usr/sbin/ip -6 addr add 2001:db8:123::2/64 dev tun12
openvpn[32272]: Linux ip -6 addr add failed: external program exited with error status: 2
openvpn[32272]: Exiting due to fatal error

Spoiler: OpenVPN initialisation failure Syslog extract

openvpn[32272]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.200.196.1,ping 9,ping-restart 30,route-gateway 10.200.196.1,topology subnet,redirect-gateway def1,ifconfig-ipv6 2001:db8:123::2/64 2001:db8:123::1,route-ipv6 2000::/3 2001:db8:123::1,explicit-exit-notify 2,ifconfig 10.200.196.16 255.255.255.0'
openvpn[32272]: Option 'explicit-exit-notify' in [PUSH-OPTIONS]:9 is ignored by previous <connection> blocks
openvpn[32272]: OPTIONS IMPORT: timers and/or timeouts modified
openvpn[32272]: OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp
openvpn[32272]: OPTIONS IMPORT: --ifconfig/up options modified
openvpn[32272]: OPTIONS IMPORT: route options modified
openvpn[32272]: OPTIONS IMPORT: route-related options modified
openvpn[32272]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
openvpn[32272]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
openvpn[32272]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[32272]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
openvpn[32272]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[32272]: GDG6: remote_host_ipv6=n/a
openvpn[32272]: TUN/TAP device tun12 opened
openvpn[32272]: TUN/TAP TX queue length set to 100
openvpn[32272]: do_ifconfig, tt->did_ifconfig_ipv6_setup=1
openvpn[32272]: /usr/sbin/ip link set dev tun12 up mtu 1500
openvpn[32272]: /usr/sbin/ip addr add dev tun12 10.200.196.16/24 broadcast 10.200.196.255
openvpn[32272]: /usr/sbin/ip -6 addr add 2001:db8:123::2/64 dev tun12
openvpn[32272]: Linux ip -6 addr add failed: external program exited with error status: 2
openvpn[32272]: Exiting due to fatal error

can be 'fixed' - assuming IPv6 isn't required, which in my case, it isn't (yet!) by adding appropriate OpenVPN 2.4 Custom Configuration directives:

pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

(NOTE: Only the first directive is required? - but both may be apparently specified for good measure!!)

Subequently the VPN Client correctly initialises, although the (non-critical) weird lack of delimiters in the args passed to the openvpn-event 'up' invocation still occurs?

up? event:      custom script: Running /jffs/scripts/openvpn-event (args: tun121500155910.200.195.64255.255.255.0init)
 
route-up event: custom script: Running /jffs/scripts/openvpn-event (args: tun12 1500 1559 10.200.195.64 )

Also your example update-notification script using curl is easier on the eye rather than my current method of explictly invoking sendmail!

Spoiler: Example Gmail using curl

From: Martineau RT-AC68U <[email protected]>
To: me

Subject: New firmware version 380.64_2 is now available for your router RT-AC68U

Uptime is: 42 min
Session end: 12:00:00 up 34 min, load average: 0.02, 0.09, 0.31

---
Your friendly RT-AC68U router.
Build v380.65_beta1-ge824757

Sun Jan 15 12:07:17 GMT 2017

Many thanks

 

[sbailey4]

Hi Merlin, First thank you for all your time and energy you put into this project. It is appreciated by all! On the AC66, you mention:

• The RT-N66U, RT-AC66U, RT-AC56U and RT-AC3200 have to reuse some older closed source components due to incomplete/missing GPL release from Asus. Look for any unusual behaviour, especially regarding wifi.
• And - FIXED: Some models (N66/Ac66/AC5300) would reboot 3 times
  if one of the radios was found disabled by the user
  while booting (Asus bug).

Are these two separate items or are they related? Does the 380.64 version create the reboot issue mentioned and moving back to older components in this build resolves that? Does this mean the wifi drivers were changed (curious about "unusual behaviour, especially regarding wifi") Just an inquiring mind here running 380.64 flawlessly but interested in that massive update/fixed list of this build. Thanks again!

 

[stambeccuccio]

Merlin thanks a lot for your hard work.
The "Administration - Firmware Upgrade" page doesn't seem aligned as before.
In my opinion it was better before.

 

[RMHC]

I'm finally getting an IPv6 address again on my RT-AC3100 on Comcast. It had been broken for a long time........thanks for the fix!

 

[matthew_eli]

Tested OpenVPN from android device and it's ok with old config! No strange behaviour also from several scripts

 

[RMerlin]

Dear Merlin, Great work again. Thanks. Working good here so far on both AC66 and AC87. AC66 is in bridge mode.
I think that WPS should be off as default.

WPS is partly broken on the RT-AC87U. This is something Asus will have to fix.

Is any chance to add option/feature to configure notification by email in GUI ? This will be better solution and faster.

Not at this time. Asus is working on a new notification center, so until they finalize it, I don't want to waste hours on developing something that might become obsolete a few months from now. The ability to run a custom script gives you far more flexibility than any webui could and it was only a few minutes of development time, which is why this went in in this build.

 

[RMerlin]

Should read You can create a new update-notification user script

Key word here is "user". Those user scripts have been part of the firmware for years, this is already explained in the documentation.

Can I only use <name> (without dots), or also <name>.asuscomm.com?

The router's FQDN is composed of the device name on the LAN -> LAN IP page, and the domain on the DHCP Server page.

owever, the following OpenVPN 2.4 'Linux ip -6' error

I do not officially support IPv6 with OpenVPN. Far too many architectural changes needed to properly support it, so it's not in the short terms plans.

Also your example update-notification script using curl is easier on the eye rather than my current method of explictly invoking sendmail!

SMTPS support was what drove me to upgrade curl, as in the original curl version it would just segfault. I also liked the syntax, should make it easier for people to adapt it for their own SMTP, if for instance they don't support TLS or authentication (believe it or not, but one of the largest local ISPs still does not support TLS!).

Are these two separate items or are they related? Does the 380.64 version create the reboot issue mentioned and moving back to older components in this build resolves that? Does this mean the wifi drivers were changed (curious about "unusual behaviour, especially regarding wifi")

They're two separate issue. The "reboot three times" is something that has always been part of the firmware (as far as I can remember). What Asus does is at boot time, and only for those models, it checks the state of the radios. If one of the radios isn't on, the router increments an internal counter in nvram, and reboots itself. Once the number of reboots reaches a specific limit (also configured in nvram), then the router just "give up" on trying to resurrect what it thinks is a dead radio, and completes its regular boot. The fact Asus does this only for a few select models makes me suspect that there might have been a design defect in maybe some specific revisions, and they worked around it by just having the router retries to reboot a few times. The problem is, this process doesn't take into account radios that have been disabled by the end user, and therefore it would be normal for these to be disabled at boot time. This translated into a very long boot time for, for example, the RT-AC5300.

The "Administration - Firmware Upgrade" page doesn't seem aligned as before.
In my opinion it was better before.

The previous layout was broken. The hitbox on the checkbox was off by a few pixels as some browsers had issues properly rendering the page. Due to the way Asus designed this page, the only fix was to revert it back to Asus's own design - it was impossible to properly align all fields without redesigning the whole table. CSS workarounds people provided weren't working properly.

 

[Martineau]

Not sure if there is a minor (potentially frustrating) error on the VPN Client GUI?

With a fully functioning active VPN Client connection, attempt to manually stop the VPN Client:

Click the OFF slider, and the 'Applying settings' spins on screen for about 10-15 secs.......but the Service State slider remains ON in green in the GUI.

Click the OFF Slider again, and this time after the 'Applying settings' (again 10-15secs) the Service State slider now correctly shows OFF in Grey
(Allowing a re-start)

NOTE: If I navigate to the VPN Status page after the seemingly unsuccessful first OFF request attempt, then when I return to the VPN Client page the Service Status slider correctly shows OFF.

NOTE: Tried under IE and Firefox, and also confirmed via SSH session that the tun1x interface was physically removed despite the GUI still showing ON.

 

[JohnNerd]

I think people misunderstand the wps 5 gHz problem on 87U. It's not the button which switches on. You must use a wifi scanner to se that it's enabled. You must then turn it on and off again in the 87U GUI. As Merlin says: it's broken.

 

[eclp]

I think people misunderstand the wps 5 gHz problem on 87U. It's not the button which switches on. You must use a wifi scanner to se that it's enabled. You must then turn it on and off again in the 87U GUI. As Merlin says: it's broken.

Thanks for this!

 

[Shonk]

• Fixed IPv6 request for some models (like the RT-AC88U) that were using a blank MAC when generating their DUID

This seems to be causing me some issues with my isp sky in the uk

380.64_2 and below is fine

Release prefix on exit = Enabled
and the following to fix the default gateway being blank

services-start

sleep 10
killall odhcp6c
odhcp6c -df -R -s /tmp/dhcp6c -N try -c 00030001000000000000 -FP 0:56108 -r23 -r24 -r82 -r83 -k eth0

with the master branch im getting no ipv6 address i can coax one out of it in the end but its down on next reboot

i can release my ip on reboot every time and it works
but if i use release prefix on exit i get no ip
instead of the usual everything apart from default gateway on 380.64_2 and below

a rollback to 380.64_2 and its fine again

did you miss something on the merge to do with adding release prefix on exit maybe?

 

[Shonk]

actually on thinking about it

is -c 00030001000000000000 my duid?
if so that's most prob my problem im feeding it the wrong string in the script
for the new builds

doing a master build now and will check the default string without the script
and report back

fingers crossed its just me failing to add the changed duid to the script

 

[bobiii]

Also installed on my 5300. No problems runs well.

 

[bradbort]

I'm having the same issue with this beta that I had with the Alpha's. That is, I can no longer scan on the wireless network from a brother MFC with this version. Rolling back to your prior version, and all is well.

 

[Ryu Connor]

Asuswrt-Merlin 380.65 Beta is now available for download, for all supported models.

Fixed IPv6 request for some models (like the RT-AC88U) that were using a blank MAC when generating their DUID.

This fix definitely worked for my RT-AC88U in router mode.

I also hoped it was the source of the problem for the months old regression in the IPv6 stack that causes the clients of the 88U bridge mode to lose an IPv6 address after a certain amount of use.

Unfortunately this bug isn't the one.

Yes, I know you don't support using your firmware in bridge mode. I just wish Asus would fix this (I have reported it with the feedback tool). It has been six months since Asus introduced whatever change broke IPv6 in 88U bridge mode.

The IPv6 address randomly returns hours later. I wonder if I'm wrong about the bug being in the Bridge code exclusively. Seems possible the router DHCP-PD code has a bug.

 

[Shonk]

ok ignore my earlier post its fine
was just a case of waiting for the lease to expire on the old duid (30mins or so)
and having the wrong string in my script for the new duid