[Release] Asuswrt-Merlin 380.65 is now available

[Diamond67]

Yes, http://192.168.0.1:8200/ was working for me till I have uploaded new Media file, after uploading a couldnt access it anymore - after MS reboote I could access it again (380.65)

If 'Enable status webpage' setting is "Yes", both http://router.asus.com:8200/ and http://192.168.1.1:8200 work for me. My router model is AC68U though. Maybe your problem is purely AC66U-related?

 

[RMerlin]

The AC3200 is particularly NVRAM challenged because when then added the 3rd radio they didn't expand the nvram space (the 3rd radio takes up 6-7K of space). Best advice I have is in this post. Note that if you need to clean out the 'clientlist' vars, you may lose any custom name/icon configurations you have made.

https://www.snbforums.com/threads/asuswrt-merlin-380-59-ac68u-port-fwd-apply-fail.33895/#post-273422

Another trick is to access every OpenVPN and server instances you do NOT use (i.e. server 2, client 1, client 2, etc...) and click the "Default" button. If you had old configuration leftovers from past versions, they will be wiped.

 

[RMerlin]

I even did a factory restore, re-configured things, and still no DLNA server.

Does http://router.asus.com:8200/ work for others ? I even tried http://192.168.1.1:8200 with no luck as well.

A few releases ago, Asus removed that page from minidlna for security reasons (it allowed anyone to access your list of DLNA clients, seeing their MAC addresses). With 4180, they added an undocumented setting that allows to re-enable it, probably for troubleshooting reasons.

In 380.65 I added a webui setting to enable/disable that setting. This is still disabled by default, for the same security reasons it was originally removed by Asus.

 

[RMerlin]

Can someone confirm me the TRX file's CRC for me ?

I just tried to go to the new 380_65, from a few versions ago (380_62 think), and it got stuck in a boot loop, couldnt factory the router or connect to it.

I got it in to Recovery and planted the default latest ASUS firmware, which is like 38MB in size, but the Merlin 380_65 is only 33MB in size.

CRC32 - 0298B938 Can anyone confirm this CRC for 380_65 ? (Faulty download perhaps ?)

SHA256 hashes are included in the zipfile, as well as on the download page at https://asuswrt.lostrealm.ca/ .

 

[uwish]

I had to revert back to a _64 build. For some reason I do not seem to be getting the same wifi coverage as I was before, and clients keep dropping out. Now that I am back on _64 B2 the issue has gone away. I didn't see anything related to wifi drivers etc on the release notes of _65. So I am not sure what it is, but I can reproduce the results as I went to _65 over the weekend again and the problem re-appeared.

 

[Martin Fishkov]

Anyone else have trouble stopping TOR in this release? (RT68U)

 

[vincom]

I had to revert back to a _64 build. For some reason I do not seem to be getting the same wifi coverage as I was before, and clients keep dropping out. Now that I am back on _64 B2 the issue has gone away. I didn't see anything related to wifi drivers etc on the release notes of _65. So I am not sure what it is, but I can reproduce the results as I went to _65 over the weekend again and the problem re-appeared.

did u do a factory reset after flashing?

 

[latenitetech]

I noticed in 380.65 inotify watches added by minidlna are now elevated to the 'WARN' level in the minidlna log, which means I now have >1000 extra (rather worthless) warnings in my minidlna log on every media server restart. In the previous release, they were at the 'INFO' level, so the default "WARN and higher" level of logging would suppress them. Was that change really intended, or just a byproduct of the latest AsusWRT merge? In my mind, something expected and normal should not be warned about. I like to keep my minidlna log file reasonably clean as it can provide useful info on bad media files, but an extra 1000 useless warnings tends to overshadow otherwise useful messages.

It's an easy (temporary) fix to change the log level on inotify messages to 'ERROR' in minidlna.conf to again suppress them (meaning don't log anything below ERROR in importance):

log_level=general,artwork,scanner,database,metadata,http,ssdp,tivo=warn,inotify=error

Just suggesting perhaps to change the log level back to INFO for those messages in a subsequent FW release.

 

[latenitetech]

Yes, http://192.168.0.1:8200/ was working for me till I have uploaded new Media file, after uploading a couldnt access it anymore - after MS reboote I could access it again (380.65)

I'm not seeing the minidlna problems described with 380.65 on my RT-AC68U, so I'm wondering if they are specific to the *66* line of routers which are MIPS based (rather than ARM as on the AC68). I also noticed this comment in the git repository for inotify.c:

RMerl Merged with GPL 380_4180 (missing MIPS and AC3200 binary blobs)

Perhaps that might be related to the problem on MIPS-based routers? Just a thought ...

 

[SkebbZ]

Ever since 380.65 on AC68U, my main computer has trouble with DHCP. I have the router set to manually assign 192.168.1.100 to my PC's MAC address, but every time I boot I get the 169. address you get when DHCP fails...

Spamming ipconfig /renew fixes it after a while, or statically setting the IP in Windows. Annoying. No other clients have issues, but they just draw from the DHCP pool. Reverting to previous version seems to fix it, or deleting manual assignment from the router.

 

[florid]

This morning when I woke up, I found the Internet is very slow. So I use ASUS mobile app to reboot the router. Waited more than 3 min, no wifi signal (2.5 or 5G). As I set my RT-AC68U to stealth mode, I cannot tell the status from the front LED lights. But the physical interfaces connected to modem and switch are up.
As morning rush hours, I have no time to login portal check log via cable. I only had a power cycle to bring it back. Internet is back normal also. Haven't checked the log yet. No idea what had happened.
no issue to reboot the router using asus mobile app on 64_2. The first time did the same on 65. Not sure any other users experience the similar issue? Thanks.

 

[uwish]

did u do a factory reset after flashing?

No just a restart, no factory reset.

 

[Magnus33]

Something not right with this build where pppoe connections are concerned.

Was hoping it was just a flash issues that caused problems but it doesn't renew the connection correctly at times unlike previous builds.

Ac 68u.

Hmmmm seems teksavvy may have fixed things on there end with the PPPoE authentication server being slightly slow to respond.

 

[XIII]

380.65 working fine on the RT-AC66U, the RT-AC68U, and the RT-AC56U that I maintain for myself and some family members.

 

[Boen]

If 'Enable status webpage' setting is "Yes", both http://router.asus.com:8200/ and http://192.168.1.1:8200 work for me. My router model is AC68U though. Maybe your problem is purely AC66U-related?

My AC66U also has the same problem. Everytime I uploaded a new media files, the DLNA server always went down. I also couldn't connect to http://router.asus.com:8200" anymore.

The only remedy is to restart the DLNA server by DISABLE and re-ENABLE the Media Server Service.

 

[florid]

This morning when I woke up, I found the Internet is very slow. So I use ASUS mobile app to reboot the router. Waited more than 3 min, no wifi signal (2.5 or 5G). As I set my RT-AC68U to stealth mode, I cannot tell the status from the front LED lights. But the physical interfaces connected to modem and switch are up.
As morning rush hours, I have no time to login portal check log via cable. I only had a power cycle to bring it back. Internet is back normal also. Haven't checked the log yet. No idea what had happened.
no issue to reboot the router using asus mobile app on 64_2. The first time did the same on 65. Not sure any other users experience the similar issue? Thanks.

Feb 14 08:14:14 rc_service: httpds 450:notify_rc reboot
Feb 14 08:14:15 miniupnpd[907]: Failed to get IP for interface ppp0
Feb 14 08:14:15 miniupnpd[907]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Feb 14 08:14:17 wan: finish adding multi routes
Feb 14 08:14:17 wan: finish adding multi routes
Feb 14 08:14:18 iTunes: daemon is stopped
Feb 14 08:14:18 FTP Server: daemon is stopped
Feb 14 08:14:18 Samba Server: smb daemon is stopped
Feb 14 08:14:18 kernel: gro disabled
Feb 14 08:14:19 Timemachine: daemon is stopped
Feb 14 08:14:19 WEBDAV Server: daemon is stopped
Feb 14 08:14:19 NAT Tunnel: AAE Service is stopped
Feb 14 08:14:19 NAT Tunnel: AAE Service is stopped
Aug  1 10:00:13 kernel: klogd started: BusyBox v1.25.1 (2017-02-03 00:18:59 EST)
Aug  1 10:00:13 kernel: Linux version 2.6.36.4brcmarm (merlin@ubuntu-dev) (gcc version 4.5.3 (Buildroot 2012.02) ) #2 SMP PREEMPT Fri Feb 3 00:27:49 EST 2017
Aug  1 10:00:13 kernel: CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7f
Aug  1 10:00:13 kernel: CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Aug  1 10:00:13 kernel: Machine: Northstar Prototype
Aug  1 10:00:13 kernel: Ignoring unrecognised tag 0x00000000
Aug  1 10:00:13 kernel: Memory policy: ECC disabled, Data cache writealloc
Aug  1 10:00:13 kernel: Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 60416
Aug  1 10:00:13 kernel: Kernel command line: root=/dev/mtdblock2 console=ttyS0,115200 init=/sbin/preinit earlyprintk debug
Aug  1 10:00:13 kernel: Memory: 255488k/255488k available, 6656k reserved, 0K highmem
Aug  1 10:00:13 kernel: Virtual kernel memory layout:
Aug  1 10:00:13 kernel:     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
Aug  1 10:00:13 kernel:     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
Aug  1 10:00:13 kernel:     DMA     : 0xf7e00000 - 0xffe00000   ( 128 MB)
Aug  1 10:00:13 kernel:     vmalloc : 0xd0800000 - 0xf0000000   ( 504 MB)
Aug  1 10:00:13 kernel:     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
Aug  1 10:00:13 kernel:     modules : 0xbf000000 - 0xc0000000   (  16 MB)
Aug  1 10:00:13 kernel:       .init : 0xc0008000 - 0xc003d000   ( 212 kB)
Aug  1 10:00:13 kernel:       .text : 0xc003d000 - 0xc03a9000   (3504 kB)
Aug  1 10:00:13 kernel:       .data : 0xc03c0000 - 0xc03e32a0   ( 141 kB)
Aug  1 10:00:13 kernel: * Invalid signature of oopsbuf: FF-FF-FE-FB-FF-FF-FF-FF (len 4294967295)
Aug  1 10:00:13 kernel: External imprecise Data abort at addr=0x0, fsr=0x1c06 ignored.
Aug  1 10:00:13 kernel: Mount-cache hash table entries: 512
Aug  1 10:00:13 kernel: CPU1: Booted secondary processor
Aug  1 10:00:13 kernel: Found a AMD NAND flash:
Aug  1 10:00:13 kernel: Total size:  128MB
Aug  1 10:00:13 kernel: Block size:  128KB
Aug  1 10:00:13 kernel: Page Size:   2048B
Aug  1 10:00:13 kernel: OOB Size:    64B
Aug  1 10:00:13 kernel: Sector size: 512B
Aug  1 10:00:13 kernel: Spare size:  16B
Aug  1 10:00:13 kernel: ECC level:   8 (8-bit)
Aug  1 10:00:13 kernel: Device ID: 0x 1 0xf1 0x80 0x1d 0x 1 0xf1
Aug  1 10:00:13 kernel: bio: create slab <bio-0> at 0
Aug  1 10:00:13 kernel: PCI: no core
Aug  1 10:00:13 kernel: PCI: no core
Aug  1 10:00:13 kernel: PCI: Fixing up bus 0
Aug  1 10:00:13 kernel: PCI: Fixing up bus 0
Aug  1 10:00:13 kernel: PCI: Fixing up bus 1
Aug  1 10:00:13 kernel: PCI: Fixing up bus 0
Aug  1 10:00:13 kernel: PCI: Fixing up bus 2
Aug  1 10:00:14 WAN(0) Connection: Fail to connect with some issues.
Aug  1 10:00:14 WAN(1) Connection: ISP's DHCP did not function properly.
Aug  1 10:00:20 custom config: Appending content of /jffs/configs/dnsmasq.conf.add.
Aug  1 10:00:21 RT-AC68U: start httpd - SSL
Aug  1 10:00:21 syslog: Generating SSL certificate...
Aug  1 10:00:21 hour monitor: daemon is starting
Aug  1 10:00:21 hour monitor: daemon terminates
Aug  1 10:00:21 disk monitor: be idle
Aug  1 10:00:21 kernel: gro enabled with interval 2
Aug  1 10:00:23 Samba Server: daemon is started
Aug  1 10:00:24 jffs2: valid logs(1)
Aug  1 10:00:25 pppd[519]: pppd 2.4.7 started by felix, uid 0
Aug  1 10:00:25 pppd[519]: Connected to 78:da:6e:de:d2:60 via interface vlan2
Aug  1 10:00:25 pppd[519]: Connect: ppp0 <--> vlan2
Aug  1 10:00:25 pppd[519]: PAP authentication succeeded
Aug  1 10:00:25 pppd[519]: peer from calling number 78:DA:6E:DE:D2:60 authorized
Aug  1 10:00:25 pppd[519]: local  IP address 203.x.x.123
Aug  1 10:00:25 pppd[519]: remote IP address 10.x.x.119
Aug  1 10:00:25 rc_service: ip-up 536:notify_rc start_firewall
Aug  1 10:00:25 wan: finish adding multi routes
Aug  1 10:00:25 wan: finish adding multi routes
Aug  1 10:00:26 rc_service: ip-up 536:notify_rc stop_upnp
Aug  1 10:00:26 rc_service: waitting "start_firewall" via ip-up ...
Aug  1 10:00:27 rc_service: udhcpc 569:notify_rc start_firewall
Aug  1 10:00:27 rc_service: waitting "start_firewall" via ip-up ...
Aug  1 10:00:27 syslog: module ledtrig-usbdev not found in modules.dep
Aug  1 10:00:27 syslog: module leds-usb not found in modules.dep
Aug  1 10:00:27 kernel: SCSI subsystem initialized
Aug  1 10:00:27 kernel: csw_retry 100
Aug  1 10:00:29 WAN(0) Connection: WAN was restored.
Aug  1 10:00:29 WAN(1) Connection: WAN was restored.
Aug  1 10:00:29 start_nat_rules: apply the nat_rules(/tmp/nat_rules_0_ppp0_vlan2)!
Aug  1 10:00:30 custom script: Running /jffs/scripts/nat-start
Aug  1 10:00:30 felix: firewall Applying nat-start rules
Aug  1 10:00:31 kernel: nf_conntrack_rtsp v0.6.21 loading
Aug  1 10:00:31 kernel: nf_nat_rtsp v0.6.21 loading
Aug  1 10:00:31 custom script: Running /jffs/scripts/firewall-start (args: ppp0)
Aug  1 10:00:31 start_nat_rules: apply the nat_rules(/tmp/nat_rules_0_ppp0_vlan2)!
Aug  1 10:00:32 start_nat_rules: apply the nat_rules(/tmp/nat_rules_0_ppp0_vlan2)!
Aug  1 10:00:32 custom script: Running /jffs/scripts/nat-start
Aug  1 10:00:32 custom script: Running /jffs/scripts/nat-start
Aug  1 10:00:32 felix: firewall Applying nat-start rules
Aug  1 10:00:32 felix: firewall Applying nat-start rules
Aug  1 10:00:33 custom script: Running /jffs/scripts/firewall-start (args: ppp0)
Aug  1 10:00:33 wan: finish adding multi routes
Aug  1 10:00:34 rc_service: ip-up 536:notify_rc start_upnp
Aug  1 10:00:34 rc_service: waitting "stop_upnp" via ip-up ...
Aug  1 10:00:34 dhcp client: bound 60.227.254.211 via 60.227.255.254 during 3600 seconds.
Aug  1 10:00:35 miniupnpd[872]: HTTP listening on port 47070
Aug  1 10:00:35 miniupnpd[872]: Listening for NAT-PMP/PCP traffic on port 5351
Aug  1 10:00:35 ddns update: ez-ipupdate: starting...
Aug  1 10:00:35 ddns update: connected to dynamicdns.park-your-domain.com (104.219.249.25) on port 80.
Aug  1 10:00:36 ddns update: request successful
Aug  1 10:00:36 ddns update: asusddns_update: 0
Aug  1 10:00:37 ddns: ddns update ok
Aug  1 10:00:37 rc_service: zcip 873:notify_rc start_firewall
Aug  1 10:00:37 zcip client: configured 169.254.65.176
Aug  1 10:00:38 miniupnpd[872]: shutting down MiniUPnPd
Aug  1 10:00:38 start_nat_rules: apply the nat_rules(/tmp/nat_rules_0_ppp0_vlan2)!
Aug  1 10:00:38 custom script: Running /jffs/scripts/nat-start
Aug  1 10:00:38 ntp: start NTP update
Aug  1 10:00:38 felix: firewall Applying nat-start rules
Feb 14 08:20:43 rc_service: ntp 877:notify_rc restart_upnp

I copied the log of the issue. Not sure if anything interesting.

 

[gjf]

Asus RT-N66W working in router mode. No DHCP, no WAN connection - all real routing is performed by RT-AC66U connected upper.

No USB devices, just connection of several clients via WiFi and Ethernet.
Every morning 5.0 GHz band is down. Also I cannot connect to web-interface of N66W. AC66U works OK.
The only solution is reboot.

Anybody expects the similar problems on 380.65?

Also sometimes the device loses connection to upper AC-66U with the following in logs:

Aug 1 07:00:12 kernel: SKIPPED false Type 1 Radar Detection. min_pw=72 pw_delta=0 pri=21999 fm_min=0 fm_max=0 nconsecq_pulses=3. Time from last detection = 10935, = 182min 15sec. Detected pulse index: 0
Aug 1 07:00:15 kernel: Type 1 Radar Detection. Detected pulse index=0 fm_min=0 fm_max=0 nconsecq_pulses=3. Time from last detection = 2, = 0min 2sec
Aug 1 07:13:13 kernel: br0: neighbor 8000.60:a4:4c:9f:41:28 lost on port 1(vlan1)
Aug 1 07:13:13 kernel: br0: topology change detected, propagating
Aug 1 07:14:35 kernel: device br0 entered promiscuous mode
Aug 1 07:15:44 kernel: device br0 left promiscuous mode

And the most surprising: the time settings are the same at both routers, but time in log of N66W is incorrect.

 

[Zirescu]

Anybody expects the similar problems on 380.65?

No issues with my RT-N66U but I've got it in AP mode and only have the 5GHz radio enabled in it.

 

[stambeccuccio]

Hoping new ASUS firmware 3.0.0.4.380.7266 is not with bug as 380.4180

 

[ElmerF]

Been using your Merlin releases for over a year on my AC68, and am beyond impressed with your work. As long as you are pumping out Merlin mods I'll stay with ASUS with a religious fervor. Just joined the forum today to flag a possible problem with the latest update 380.65. I had a problem with beta 3 (seemed like dhcp problems), went to beta 4 (seem okay), moved to the final version and this morning I woke up to no wireless. Had to do a hardware reset. I'm sure this is an ASUS generated problem in their recent closed source update, and I'll probably drop back a version if things lock up again. Sorry I don't have logs. First thing in the morning is not a troubleshooting time for me - hard resets and grumbling only.

Oh, by the way, I sent a small donation. Thanks again for all your hard work.