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.
With Google Chrome update 56.0.2924.74 there are layout pages problems:
View attachment 8358
View attachment 8359
..etc.

Just updated Chrome, and yes I have the same, cosmetic gaps, pages are:

Guest_network.asp
AdaptiveQoS_Bandwidth_Monitor.asp
Main_TrafficMonitor_realtime.asp
cloud_main.asp
Tools_Sysinfo.asp
Advanced_Wireless_Content.asp
Advanced_LAN_Content.asp
Advanced_WAN_Content.asp
Advanced_IPv6_Content.asp
Advanced_VPNStatus.asp
Advanced_BasicFirewall_Content.asp
Advanced_OperationMode_Content.asp
Main_LogStatus_Content.asp
Main_Analysis_Content.asp

Edge and IE don't have the gaps.

Asuswrt-Merlin 380.65 Beta 2

Regards
 
Last edited:
Been running beta 2 for almost a week now no issues with the script i maintain and stability has been really good even my issues with 5ghz that i had in the previous alphas and beta 1.
 
Just out of curiousity, for those having the issue with scanners with the new firmware, how many of you have Trendnet active on the router? I have not tested this yet, but was wondering if it could be causing issues.

I have it on . . . always have.
 
Just updated Chrome, and yes I have the same, cosmetic gaps, pages are:

Google changed something, so rendering now matches Firefox and Opera rather than match IE in behaviour. Fix is easy, just apply the same rendering "fix" to Chrome as was already done to the first two. This will however break the layout for people who aren't upgrading to the latest Chrome, but that's their problem, not mine.
 
Google changed something, so rendering now matches Firefox and Opera rather than match IE in behaviour. Fix is easy, just apply the same rendering "fix" to Chrome as was already done to the first two. This will however break the layout for people who aren't upgrading to the latest Chrome, but that's their problem, not mine.
It doesn't bother me to be honest. Not using it for its prettiness :)

Verstuurd vanaf mijn SM-G935F met Tapatalk
 
Fix is easy, just apply the same rendering "fix" to Chrome as was already done to the first two.

Can you throw in a clue for the clueless Mr Merlin sir:confused:

Regards

It doesn't bother me to be honest. Not using it for its prettiness :)

Verstuurd vanaf mijn SM-G935F met Tapatalk

Me neither , but some people are:eek::)

Regards
 
Google changed something, so rendering now matches Firefox and Opera rather than match IE in behaviour. Fix is easy, just apply the same rendering "fix" to Chrome as was already done to the first two. This will however break the layout for people who aren't upgrading to the latest Chrome, but that's their problem, not mine.
Just did the update for my fork....here's a little piece of code you may find useful :)
Code:
if(isChrome){
    var major = navigator.userAgent.match("Chrome\/([0-9]*)\.");    //check for major version
    if(parseInt(major[1], 10) < 56)
        isChrome = false;
}
 
Just did the update for my fork....here's a little piece of code you may find useful :)
Code:
if(isChrome){
    var major = navigator.userAgent.match("Chrome\/([0-9]*)\.");    //check for major version
    if(parseInt(major[1], 10) < 56)
        isChrome = false;
}

I don't want to base isChrome strictly on the version (as other parts of the code might eventually be Chrome-specific), but I'll take a hint of Asus having a isIE8 flag, and go with isChrome56 there. Something like this:

Code:
var isChrome = navigator.userAgent.search("Chrome") > -1;
if(isChrome){
        var major = navigator.userAgent.match("Chrome\/([0-9]*)\.");    //check for major version
        var isChrome56 = (parseInt(major[1], 10) >= 56);
}
 
I have been using Asuswrt-Merlin since I got my T Mobile version of the AC1900 up and running (about 2 months). I tried 380.65 beta 2 yesterday, but I went back to 380.64 release 2 because I lost much of the internet with 380.65. It was strange, because I could connect to some web locations but other locations would just time out. Since one of the locations it could not connect to was my local ISP (Spectrum/Brighthouse) the new version was a no go for me. I have not checked this whole thread to see if anyone else reported a similar problem. I did not reset after upgrading to the new version, but, the general instructions say that you do not need to reset for a next version, just if you have skipped a few versions. When I downgraded to 380.64 everything worked again perfectly.

Ellsworth
 
Just the OCD in me:p

Is there a reason nat-start appears to be invoked when Reboot is initiated via GUI?


Jan 27 08:45:27 RT-AC68U kern.notice rc_service: httpd 3125:notify_rc reboot
Jan 27 08:45:28 RT-AC68U kern.info kernel: device eth0 left promiscuous mode
Jan 27 08:45:28 RT-AC68U kern.info kernel: br0: port 1(vlan1) entering forwarding state
Jan 27 08:45:28 RT-AC68U kern.info kernel: device eth0 entered promiscuous mode
Jan 27 08:45:28 RT-AC68U kern.info kernel: br0: port 1(vlan1) entering forwarding state
Jan 27 08:45:28 RT-AC68U kern.info kernel: br0: port 1(vlan1) entering forwarding state
Jan 27 08:45:29 RT-AC68U daemon.notice openvpn[2115]: Closing TUN/TAP interface
Jan 27 08:45:29 RT-AC68U daemon.notice openvpn[2115]: /usr/sbin/ip addr del dev tun21 10.188.0.1/24
Jan 27 08:45:29 RT-AC68U daemon.notice openvpn[2115]: updown.sh tun21 1500 1622 10.188.0.1 255.255.255.0 init
Jan 27 08:45:29 RT-AC68U user.warn updown.sh[13482]: User openvpn-event running
Jan 27 08:45:29 RT-AC68U user.warn (vpnserver1-down): 13490 Openvpn event 'down' (tun21) via 10.188.0.1 args = [tun21 1500 1622 10.188.0.1 255.255.255.0 init]
Jan 27 08:45:29 RT-AC68U user.warn (vpnserver1-down): 13490 Processing Openvpn Server 1 (tun21) event 'down'.....
Jan 27 08:45:29 RT-AC68U user.warn (vpnserver1-down): 13490 Block port 455 inbound from Openvpn Server 1 to NAS (10.88.8.1.196)
Jan 27 08:45:30 RT-AC68U user.warn (vpnserver1-down): 13490 Block ping inbound from Openvpn Server 1 to NAS (10.88.8.1.196)
Jan 27 08:45:30 RT-AC68U daemon.notice openvpn[2115]: SIGTERM[hard,] received, process exiting
Jan 27 08:45:33 RT-AC68U kern.notice iTunes: daemon is stopped
Jan 27 08:45:33 RT-AC68U kern.notice FTP Server: daemon is stopped
Jan 27 08:45:34 RT-AC68U kern.notice Samba Server: smb daemon is stopped
Jan 27 08:45:34 RT-AC68U kern.warn kernel: gro disabled
Jan 27 08:45:34 RT-AC68U kern.notice Timemachine: daemon is stopped
Jan 27 08:45:34 RT-AC68U kern.notice WEBDAV Server: daemon is stopped
Jan 27 08:45:34 RT-AC68U kern.notice NAT Tunnel: AAE Service is stopped
Jan 27 08:45:34 RT-AC68U kern.notice NAT Tunnel: AAE Service is stopped
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver cdc_mbim
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver cdc_ncm
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver qmi_wwan
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver cdc_wdm
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver rndis_host
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver cdc_ether
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver asix
Jan 27 08:45:34 RT-AC68U kern.info kernel: cdrom: Uniform CD-ROM driver unloaded
Jan 27 08:45:34 RT-AC68U kern.info kernel: usbcore: deregistering interface driver usblp
Jan 27 08:45:35 RT-AC68U kern.notice custom script: Running /jffs/scripts/services-stop
Jan 27 08:45:35 RT-AC68U user.warn (services-stop): 13722 Martineau Services shutdown cleanup starting...... []
Jan 27 08:45:35 RT-AC68U kern.notice WEBDAV Server: daemon is stopped
Jan 27 08:45:35 RT-AC68U kern.notice NAT Tunnel: AAE Service is stopped
Jan 27 08:45:35 RT-AC68U kern.notice NAT Tunnel: AAE Service is stopped
Jan 27 08:45:35 RT-AC68U user.warn (services-stop): 13722 Stopping rstats.....
Jan 27 08:45:35 RT-AC68U kern.notice iTunes: daemon is stopped
Jan 27 08:45:35 RT-AC68U kern.notice rc_service: service 13730:notify_rc stop_rstats
Jan 27 08:45:35 RT-AC68U kern.notice FTP Server: daemon is stopped
Jan 27 08:45:35 RT-AC68U user.warn (services-stop): 13722 Stopping cstats.....
Jan 27 08:45:35 RT-AC68U kern.notice Samba Server: smb daemon is stopped
Jan 27 08:45:35 RT-AC68U kern.warn kernel: gro disabled
Jan 27 08:45:35 RT-AC68U kern.notice rc_service: service 13734:notify_rc stop_cstats
Jan 27 08:45:35 RT-AC68U kern.notice rc_service: waitting "stop_rstats" via ...
Jan 27 08:45:35 RT-AC68U kern.notice Timemachine: daemon is stopped
Jan 27 08:45:35 RT-AC68U kern.notice disk_monitor: Finish
Jan 27 08:45:36 RT-AC68U user.debug syslog: cstats stopped.
Jan 27 08:45:39 RT-AC68U kern.notice NAT Tunnel: AAE Service is stopped
Jan 27 08:45:39 RT-AC68U kern.notice NAT Tunnel: AAE Service is stopped
Jan 27 08:45:39 RT-AC68U kern.notice start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan 27 08:45:39 RT-AC68U kern.notice custom script: Running /jffs/scripts/nat-start
Jan 27 08:45:39 RT-AC68U user.warn (nat-start): 13755 Martineau NAT customisation starting.... []
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 7(wl1.3) entering forwarding state
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 6(wl0.3) entering forwarding state
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 5(wl0.2) entering forwarding state
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 4(wl0.1) entering forwarding state
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 3(eth2) entering forwarding state
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 2(eth1) entering forwarding state
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 1(vlan1) entering forwarding state
Jan 27 08:45:39 RT-AC68U user.warn (nat-start): 13755 **WARNING: Shutdown in progress: '/tmp/SHUTDOWNINPROGRESS' skipping processing!
Jan 27 08:45:39 RT-AC68U kern.info kernel: device eth0 left promiscuous mode
Jan 27 08:45:39 RT-AC68U kern.info kernel: device vlan1 left promiscuous mode
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 1(vlan1) entering disabled state
Jan 27 08:45:39 RT-AC68U kern.info kernel: device eth1 left promiscuous mode
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 2(eth1) entering disabled state
Jan 27 08:45:39 RT-AC68U kern.info kernel: device eth2 left promiscuous mode
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 3(eth2) entering disabled state
Jan 27 08:45:39 RT-AC68U kern.info kernel: device wl0.1 left promiscuous mode
Jan 27 08:45:39 RT-AC68U kern.info kernel: br0: port 4(wl0.1) entering disabled state
Jan 27 08:45:40 RT-AC68U kern.info kernel: device wl0.2 left promiscuous mode
Jan 27 08:45:40 RT-AC68U kern.info kernel: br0: port 5(wl0.2) entering disabled state
Jan 27 08:45:40 RT-AC68U kern.info kernel: device wl0.3 left promiscuous mode
Jan 27 08:45:40 RT-AC68U kern.info kernel: br0: port 6(wl0.3) entering disabled state
Jan 27 08:45:40 RT-AC68U kern.info kernel: device wl1.3 left promiscuous mode
Jan 27 08:45:40 RT-AC68U kern.info kernel: br0: port 7(wl1.3) entering disabled state
Jan 27 08:45:41 RT-AC68U kern.notice kernel: klogd: exiting
Jan 27 08:45:41 RT-AC68U syslog.info syslogd exiting
Jan 27 08:46:05 RT-AC68U Spoof.logger (services-stop): Martineau Services shutdown cleanup complete.
Jan 27 08:46:06 RT-AC68U Spoof.logger (services-stop): Saving syslog before Reboot.....
 
Is there a reason nat-start appears to be invoked when Reboot is initiated via GUI?

Probably the stop function of one of the services that requires a NAT restart to remove its rules.
 
Just wanted to give a small feedback. Beta 2 is working well on a RT-AC3100, and IPV6 (now) pulls an IP properly for Comcast/Xfinity.
 
I have been using Asuswrt-Merlin since I got my T Mobile version of the AC1900 up and running (about 2 months). I tried 380.65 beta 2 yesterday, but I went back to 380.64 release 2 because I lost much of the internet with 380.65. It was strange, because I could connect to some web locations but other locations would just time out. Since one of the locations it could not connect to was my local ISP (Spectrum/Brighthouse) the new version was a no go for me. I have not checked this whole thread to see if anyone else reported a similar problem. I did not reset after upgrading to the new version, but, the general instructions say that you do not need to reset for a next version, just if you have skipped a few versions. When I downgraded to 380.64 everything worked again perfectly.

Ellsworth
That is strange. WEre you seeing any issues with your 5G wireless connection itself, or literally issues with connecting to specific sites on the Internet?
 
Beta 3 (Jan 27th):
Some security updates came out this week, so I decided to delay the final release to have another round of test with these updates in place, just to be safe.

Changes since Beta 2:

Code:
   - CHANGED: Updated openssl to 1.0.2k
   - CHANGED: Updated tor to 0.2.9.9
   - FIXED: Webui layout was broken under Chrome 56
   - FIXED: miniupnpd errors at boot time about missing chains.
            Also streamlined miniupnpd stop/start events during
            boot, there are fewer of them now.

OpenSSL has been known to break stuff on new releases in the past, hence the need to be cautious :)
 
Something is causing the RT-AC88U to lose its IPv6 link local address (fe80).

I'm not sure what would cause that error.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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