Asuswrt-Merlin 380.58 is now available

[stratocu]

When selecting columns in AIprotection (parental controls --> Time Scheduling --> Time management) my column(s) are not saved. In previous versions I had no problems at all!

I tested this on a AC87U and a AC88U.......

Edit: "This problem only exists when editing columns for an already existing client. If I add a new client I do not have this problem".

Regards,
John

 

[agilani]

Not sure if this is related to my problems with the new release, but anyone seeing this in their logs over and over?


Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)
Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)
Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)
Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)
Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)
Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)
Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)

here's what the disk usage looks like after a reboot since the router appear locked up...

admin@RT-AC68P-F9A0:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 28928 28928 0 100% /
devtmpfs 127752 0 127752 0% /dev
tmpfs 127856 1100 126756 1% /tmp
/dev/mtdblock4 64256 4640 59616 7% /jffs

admin@RT-AC68P-F9A0:/# du -s * | sort -nr | head
45066 usr
14999 www
11276 lib
9497 jffs
5593 rom
1658 bin
1132 sbin
1100 tmp
0 var
0 sysroot

And before that it looks like i'm getting these errors over and over...

Feb 14 10:29:59 smbd[21443]: [2016/02/14 10:29:59.410426, 0] smbd/sesssetup.c:1355(reply_sesssetup_and_X)
Feb 14 10:29:59 smbd[21443]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negotiated.
Feb 14 10:30:01 smbd[21444]: [2016/02/14 10:30:01.657103, 0] smbd/sesssetup.c:1355(reply_sesssetup_and_X)
Feb 14 10:30:01 smbd[21444]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negotiated.
Feb 14 14:27:16 miniupnpd[690]: upnp_event_recv: recv(): Connection reset by peer
Feb 14 15:36:08 miniupnpd[690]: upnp_event_recv: recv(): Connection reset by peer
Feb 14 16:41:44 miniupnpd[690]: upnp_event_recv: recv(): Connection reset by peer

 

[john9527]

Dec 27 09:37:33 dnsmasq-dhcp[23479]: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 0s)

Sounds like there may be another runaway log file. Don't know if this is the best way to find it, but try this command

ls -lR /tmp | grep "\.log" | sort -r -k 5 | head

 

[RMerlin]

I've noticed that the vpn client status says Stopped when it actually isn't. The service state is ON and an IP Check gives me the IP that I'm expecting. A reboot fixes the problem for a few hours. Does anyone else have this issue? I'm using an RTAC87.

Works for me. What client number are you using?

 

[agilani]

Sounds like there may be another runaway log file. Don't know if this is the best way to find it, but try this command

ls -lR /tmp | grep "\.log" | sort -r -k 5 | head

thanks, here's what it looks like right now, the challenge is trying to catch it before it locks up:

admin@RT-AC68P-F9A0:/# ls -lR /tmp | grep "\.log" | sort -r -k 5 | head
-rw-rw-rw- 1 admin root 262243 Jul 31 2015 syslog.log-1
-rw-rw-rw- 1 admin root 52241 Mar 25 13:44 syslog.log
-rw-rw-rw- 1 admin root 138 Mar 25 13:44 usb.log
-rw-rw-rw- 1 admin root 74 Mar 24 20:24 miniupnpc.log
-rw-rw-rw- 1 admin root 46 Mar 25 02:00 sig_upgrade.log

Not sure what that old log file is hanging out for. This router does not keep time correctly after a reboot until the ntp kicks in. Removed the old log file for now, and I'll keep my eye on it for now...

 

[Benben]

Works for me. What client number are you using?

I'm using client 1 and 2. It also happens on either one when using only one of them at a time. I also noticed that as I use up data, the byte count goes up.

 

[RMerlin]

I'm using client 1 and 2. It also happens on either one when using only one of them at a time. I also noticed that as I use up data, the byte count goes up.

Tested with both clients 1 and 2, everything working fine here.

 

[GSpock]

Have just upgraded my RT-AC87U to 380.58 (from 380.57) and everything is OK.
BTW, many thanks for the "Networkmap: hourly full network rescans (default: Yes)" option, this is working great, my NAS is not waken-up every hour ...
Rgds,
GS

 

[threepwood]

I can also confirm that nothing on my network (Desktop, NAS, Printer) has been waking up randomly since I updated to 380.58 on last Monday and disabled the Networkmap hourly rescans option. On previous firmwares all of them experienced random wake-ups.

No other issues to report with this firmware on a RT-AC68U. Thanks for the update RMerlin.

 

[Benben]

Tested with both clients 1 and 2, everything working fine here.

A factory reset seems to have resolved my problem. I did do a factory reset after upgrading so that's why I didn't try it before asking for help. Thanks Rmerlin.

 

[Jim Hand]

IPV6 is not working reliably for me with 380.58 and Time Warner on my AC88U. The router seems to be getting the proper addresses from TWC and usually seems to be assigning them correctly to a few devices on my network. However, after 10 or 15 minutes, the router will show that no clients have IPV6 addresses. My MacBook Pro, for instance, can connect fine with IPV6 for a little while and pass all tests at any of the IPV6 testing websites, but it then loses the IPV6 address. My assumption is that the router is revoking the IPV6 address that it assigned. I tried setting ipv6_debug setting to 1 in the nvram (and rebooting), but that hasn't provided any helpful information. I also tried unsetting all of the nvram variables with ipv6 in the name and re-configuring IPV6 through the GUI. That didn't help either. I have DHCP logging turned off, but may turn that back on to see if that gives any clues.

When the IPV6 addresses go away for the clients, it appears that the IPV6 settings under the IPV6 Log tab, such as the WAN address, LAN address, and gateway, are still set properly. It just no longer shows any clients with IPV6 addresses.

Yesterday, I turned off my cable modem and AC88U, let my cable modem boot all the way up, and then turned on the AC88U. It appears that most IPV6 functionality is working correctly now from the clients' sides. About 9 devices on my home network are getting IPV6 addresses and can connect to IPV6 websites and to each other. However, the AC88U only shows one or two of the clients under the Log -> IPV6 tab. At the AC88U shell when I run "ip -6 neigh", I see more than two clients, and they aren't the same as reported under the GUI. From my MacBook Pro, "ndp -all" shows about 9 clients on my home network with IPV6 addresses. From what I can determine now, it is only the AC88U GUI that is giving misleading information about IPV6 clients.

 

[R1-Limited]

The only difference between Beta 1 and this release is a few lines of scripting in vpnrouting.sh. If Beta 1 loaded fine, then your issue lies elsewhere.

I may agree with you to a point. That said, I believe I understand what may have occured. I would be beside myself to figure this one out or reproduce it.

Initially (Pre-Beta1) I was on 378.52.2.
I was on 52.2 as it was not causing any 5g issues in bridged mode.
I updated to beta 1 (I did not factory default) either the 66 or the 68 (As I normally do)
I updated to GA of 380.58
Factory defaulted using the pin hole after the update and both routers reverted to recovery.

ODDLY the ODD Part I
When I was able to get the initial modems back to 380.58 The main (68u) worked with no issues

The 66u however was the primary issue. Using the pin hole I made several attempts to clear the brick. 30/30/30 method did not work nor did the recovery web page as the router would not respond. I finally got the router booted after re flashing with asus 3.0.0.4.378.4585 and became stable.

ODDLY the ODD Part II
I then defaulted using the web GUI (not pin hole) that worked
I skipped wizard and updated to 380.85
I pin holed
The Router Bricked again
Now, when I pinholed it it came back to the original 3.0.0.4.378.4585 I cannot understand that at all.
I defaulted it this time again in web GUI
Updated to 380.85
It came up
When I bridged the 66 at that time it went off the grid, I could not find it, reach it without getting into one of the LAN ports and I was getting the default IP 192.xxx.blah.blah

ODDLY the ODD Part III
This is what I believe was going on.
After 2 days of mucking with the 66 I discovered when I entered the Bridge Password (On the 66) to connect to the mother ship (68) it was not taking.
I know I typed it in, I know this because I selected show PW

During my attempts I never looked at this and took no notice of the pre-filled in *********** in the PW field. I hi-lighted and wrote over. HOWEVER, my last attempt I changed it did its connection and I loose it again

I logged back into the 66 and check the Password it was not my 5g password, it was the web gui admin password.

How in the hell was this happening? I do not know. I write snap shot notes when I do things like this so I reviewed (Thus the above Novel)

Anyway, How I got around it
downgraded both routers to 3.0.0.4.378.4585 web gui defaulted both twice. Updated to Version 3.0.0.4.380.1842
web gui defaulted twice (Ya over kill) seems pin hole is an issue with me routers not trusting that.

Everything is fine at this point as I updated as well this morning to 380.85 Not going to factory default anything at this time

 

[fiasko]

Just updated both AC66U and AC87U without an issue. AC66U though does show the "Memory Management: Regularly flush caches (ARM only) (default: Yes)" text, but both radio buttons are empty. If I enable one of those, the setting disapears after I press apply. This happens only with the AC66U. In AC87U the setting works just fine.

 

[slabastrou]

Failed upgrade on RT-AC66U... says the image is not right
rebooted the router and it worked....

 

[RMerlin]

Just updated both AC66U and AC87U without an issue. AC66U though does show the "Memory Management: Regularly flush caches (ARM only) (default: Yes)" text, but both radio buttons are empty. If I enable one of those, the setting disapears after I press apply. This happens only with the AC66U. In AC87U the setting works just fine.

This setting is only for ARM-based router - the RT-AC66U is MIPS-based, therefore this setting does not exist on that model.

 

[joegreat]

30/30/30 method if you want to clear Nvram dont work with Asus or Merlin Fw

Thre is NO(!) 30/30/30 reset on Asus routers - it's called NVRAM reset and only one try needed to get to it done!

 

[chrisinsocalif]

Yesterday, I turned off my cable modem and AC88U, let my cable modem boot all the way up, and then turned on the AC88U. It appears that most IPV6 functionality is working correctly now from the clients' sides. About 9 devices on my home network are getting IPV6 addresses and can connect to IPV6 websites and to each other. However, the AC88U only shows one or two of the clients under the Log -> IPV6 tab. At the AC88U shell when I run "ip -6 neigh", I see more than two clients, and they aren't the same as reported under the GUI. From my MacBook Pro, "ndp -all" shows about 9 clients on my home network with IPV6 addresses. From what I can determine now, it is only the AC88U GUI that is giving misleading information about IPV6 clients.

Thank you for catching that. I will activate my IPv6 with Time Warner again and check my devices. Also I am using John's fork for my AC66u and seems to be working better than .58.

 

[R1-Limited]

30/30/30 method if you want to clear Nvram dont work with Asus or Merlin Fw

Ya think

 

[Daybreak]

Howdy,
Any IPV6 system is still a little shaky without a full on boot. (just the nature of the implementation)
Steps to correct situation.
1. power down all components (all off at least 10 minutes)
2. Power on your modem. (wait at least 5 minutes)
3. Power on your router (wait at least 5 minutes)
4. Power on your computer
5. Power on your next and so on.

The above will alleviate the needless comments saying IP6 doesn't work, or my clients don't all show, or I can't get a IP6 address with this build, or My IP6 isn't working etc....

Now, after following the above steps, I bet there will be still some apple person saying their iPad and iPhone still doesn't work. As stated above, you need to follow the directions, and actually power it OFF.

Folks need to do a little investigating are their side before just spouting off that things don't work. Like instead of just loading a new build and out of the blue in the first 2 minutes saying something doesn't work. Reboot things, reset things, read the forums, and try a few things. Then post.

off the box, and feeling good.

 

[jsmiddleton4]

For me in the Phoenix, AZ market and Cox it takes a bit of time for the Cox IPV6 DNS server to connect, update, something. Cox's DNS servers have always been flaky. But if I wait a little, the router does get the right Cox IPV6 DNS information.

If I manually configure the IPV6 DNS with Google's or any of the others its instantaneous.

But if I'm using Cox's default IPV6 DNS server and look immediately and don't see the IPV6 DNS information I'd wrongly conclude something is broken with the IPV6 and RMerlin.