What's new

[Beta] Asuswrt-Merlin 380.65 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
The beta is working well on my rt-ac87u. Busybox, Tor, and VPN work. I assume you got the TOR build script fixed?
 
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
Edit and Delete the posting if it was nonsense - do not post another message! :rolleyes:
 
WPS is partly broken on the RT-AC87U. This is something Asus will have to fix.



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.
From where you have this info ?
 
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.
Hmm. Just tried with a 8760DW and noticed Scan to PC wasn't in the menu. I initiated a scan from the PC, and after that it showed up in the menu and worked as before.

I turned off the printer and turned it back on. Scan to PC showed up in the menu about a minute later. So I'm not seeing an issue here. Forgot to mention this is with an 87U
 
Last edited:
From where you have this info ?

The notification center code has been partly in the firmware for nearly a year now, and I see new pieces of it appear with new GPLs.

I assume you got the TOR build script fixed?

I never had any problem with it.
 
Hmm. Just tried with a 8760DW and noticed Scan to PC wasn't in the menu. I initiated a scan from the PC, and after that it showed up in the menu and worked as before.

Interesting. Actually, for me it was initiating the scan from the PC that would not work. I'll try to start one from the MFC side, and see if that fixes it...although it is peculiar that rolling back to the last "stable" firmware build solves the problem.
 
This beta breaks WiFi Calling on all devices in my house, a mixture of Apple and Android devices. Works perfectly on Alpha 4, I can switch between the 2 and have it broken and fixed, so definitely something in the beta.

I'm assuming it's something to do with the Firewall changes but I've never needed to change anything for it to work as I have UPnP enabled
 
Last edited:
This beta breaks WiFi Calling on all devices in my house, a mixture of Apple and Android devices. Works perfectly on Alpha 4, I can switch between the 2 and have it broken and fixed, so definitely something in the beta.

I'm assuming it's something to do with the Firewall changes but I've never needed to change anything for it to work as I have UPnP enabled

I just went through the complete list of changes between alpha 4 and beta 1, and I can't see anything that could have an impact. The firewall changes only ensured that any rules configured on the Network Service Firewall pages were properly applied - if you don't have any rule configured there, then this change has no impact on traffic routing. All that happens then is iptables jumps to an empty chain, which makes it immediately return back to the FORWARD chain, and continue with the rest of the configured rules.

One thing that changed is that IPv6 is now being requested using a proper DUID, rather than using a series of "000" as the router's MAC on some specific router models. I have no idea how Wifi Calling works, but if it relies on some kind of MAC-based authentication, maybe you'll need to turn off your modem for 10-15 mins to fully reset its connection. But in theory, this change should only have any impact when using IPv6.
 
It doesn't rely on MAC based authentication and my ISP isn't using IPv6.

WiFi Calling just requires ports UDP 500 (IKEv2) and UDP 4500 (IKEv2), but I've never needed to make any changes to my router and as I said on Alpha 4 things work perfectly.

This is Cisco's whitepaper in regards to Wifi Calling

http://www.cisco.com/c/en/us/soluti...802-11ac-solution/white-paper-c11-735826.html

Could any of the NAT Passthrough settings be needed? I currently have them all disabled and it's working on Alpha 4.

[edit]

Enabling IPSec Passthrough enables WiFi Calling to work on Beta 1, not sure why it works on Alpha 4 without IPSec Passthrough though.
 
Last edited:
Wifi calling is working fine for me:

RT-AC1900P running 380.65 beta1, connected to Comcast cable internet via Netgear CM600 modem
iPhone 6 on AT&T

EDIT: No ports forwarded, all NAT passthrough disabled EXCEPT IPSec (required for wife's work VPN connection)
 
Last edited:
AT&T says IPSec NAT passthrough is required for (at least their version of) wifi calling:

https://www.att.com/esupport/article.html#!/wireless/KM1114459

Wifi calling is working fine for me:

RT-AC1900P running 380.65 beta1, connected to Comcast cable internet via Netgear CM600 modem
iPhone 6 on AT&T
It doesn't rely on MAC based authentication and my ISP isn't using IPv6.

WiFi Calling just requires ports UDP 500 (IKEv2) and UDP 4500 (IKEv2), but I've never needed to make any changes to my router and as I said on Alpha 4 things work perfectly.

This is Cisco's whitepaper in regards to Wifi Calling

http://www.cisco.com/c/en/us/soluti...802-11ac-solution/white-paper-c11-735826.html

Could any of the NAT Passthrough settings be needed? I currently have them all disabled and it's working on Alpha 4.

[edit]

Enabling IPSec Passthrough enables WiFi Calling to work on Beta 1, not sure why it works on Alpha 4 without IPSec Passthrough though.
 
I had problems compiling 380.65beta1. Tried 5 times after fixing build environment. Didn't work. So I trashed asuswrt-merlin and redownloaded the git. It compiled without complaint. I had the files for over 6 months and they compiled without any issues. My suspicion was the tor makefile became corrupted or compromised for some reason. Alls well now. :)
 
This beta some how broke the HP scan to computer feature as well as the ability for HP mobile apps [HP print services and HP All-in-one] to find printer on the network.
Plex was also affected. Couldn't find media server.
Went back to 380.64_2 and all issues resolved.
 
This beta some how broke the HP scan to computer feature as well as the ability for HP mobile apps [HP print services and HP All-in-one] to find printer on the network.
Plex was also affected. Couldn't find media server.
Went back to 380.64_2 and all issues resolved.

I am having the same issue. I can't use wifi printing with HP printer using beta 1, but reverting back to 380.64_2 resolves the problem.
 
It doesn't rely on MAC based authentication and my ISP isn't using IPv6.

WiFi Calling just requires ports UDP 500 (IKEv2) and UDP 4500 (IKEv2), but I've never needed to make any changes to my router and as I said on Alpha 4 things work perfectly.

This is Cisco's whitepaper in regards to Wifi Calling

http://www.cisco.com/c/en/us/soluti...802-11ac-solution/white-paper-c11-735826.html

Could any of the NAT Passthrough settings be needed? I currently have them all disabled and it's working on Alpha 4.

[edit]

Enabling IPSec Passthrough enables WiFi Calling to work on Beta 1, not sure why it works on Alpha 4 without IPSec Passthrough though.

Weird i am not having any issues with wifi calling at all, works just as it used to with the previous alpha versions.

I have left the NAT Passthrough whatever the default was before.
 
Still having trouble getting ipv6 back like it used to be on my 87u with previous firmwares. I did a factory reset and installed 380.65 beta 1. I also tried changing the client id passed to odhcp6c which zquestz and others had success with and that also did not work.

I then checked the following and got nothing displayed form (1) and the correct lan MAC address was displayed for (2)

(1) nvram get et0macaddr
(2) nvram get et1macaddr

Now if I clone my computer MAC address to the router, I immediately get my ipv6 working?? No idea what is going on!
 
Still having trouble getting ipv6 back like it used to be on my 87u with previous firmwares. I did a factory reset and installed 380.65 beta 1. I also tried changing the client id passed to odhcp6c which zquestz and others had success with and that also did not work.

I then checked the following and got nothing displayed form (1) and the correct lan MAC address was displayed for (2)

(1) nvram get et0macaddr
(2) nvram get et1macaddr

Now if I clone my computer MAC address to the router, I immediately get my ipv6 working?? No idea what is going on!

You might just need to fully reset your Internet connection, by leaving the modem off for 10-15 mins, so next time the router connects and sends its MAC, your ISP will accept it.
 
"Uploaded alpha3 on router and re-booted it 6 hours ago--went fine. Uploaded on AP a few minutes ago--went well until I re-booted after the upload. At that point it seemed to break the web GUI on both the AP and router, but they continued to function otherwise. A few minutes later, the web GUIs came back spontaneously. I have a very basic setup."

I posted the above in the alpha thread. Last night I uploaded to router and AP; AP went fine, but the router's web GUI was again completely broken on Chrome even though functions seemed fine. Web GUI was fine on IE--didn't check other browsers. It stayed broken on Chrome for at least an hour, but was fine this morning.

Maybe this is something unique to my environment. Otherwise, everything seems great here!
 
Both WiFi calling (Verizon Wireless) and HP Scan to Computer (HP OfficeJet Pro 8720 to MacBook Pro) working here.
 
Can't confirm whether this bug was introduced by this beta version, but this is the version where I detected the bug.

Administration / System:

Specified IP address (Max Limit : 4)

You add a client, it works - but when you try to remove a client so that the list is empty and click Apply, you get this:

Fields cannot be blank

Which means you can't remove the client and you can now only access the WebUI from that client!

Browser is MS Edge
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top