Asuswrt-Merlin 380.58 is now available

[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.

 

[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

In case this helps anyone else, for some reason after the upgrade SMB sharing became enabled - even though I did not enable it or have a hard drive/additional memory installed in the RT-AC68P. At this point my best guess is that the log files were filling up /tmp with SPNEGO errors leading somehow to a system crash. (I thought Linux automatically cleared out the /tmp directory when it runs low on disk space?) I disabled the smb sharing and have been watching the disk usage, the problem has not reappeared. A watched pot never boils

On a side note, can rstat-speed.gz be deleted without any adverse effects? It's the biggest file in the tmp directory right now.

 

[agilani]

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

I've seen odd behavior like this after upgrading both the base station and the units configured as repeater. I've seen where the repeater unit loses its config and has the same ip address as the base station. Once this happens the web gui from the two units become intermingled and erratic. you don't really know which unit you are configuring or upgrading then.

I have my base units and repeaters configured for different SSID. I have two guest SSID's that I use just for the repeaters and I don't overlap SSID's from the base station to the repeaters. That way I always know where i'm connecting to and don't have a repeater station come up inadvertently as my base station. Also, always make sure your repeaters do not use the same ip address as your base station. I've reserved the first 20 or so ip addresses for static entries that I've assigned to my repeaters/cameras/etc.

D0ing a complete clean upgrade becomes challenging...

 

[jsmiddleton4]

I need a little help on the SMB2 setting.

I only have one device that lets me pick which SMB protocol to use, its a NAS device that stores my video files. Primarily accessed by my media player. The Mede8er does both NFS and SMB as does my NAS. The NAS is attached to the router, the media player attached to the router. Works fine. Just not sure about the SMB 2 setting.

Does leaving it off default to SMB3? Force SMB2, turning off SMB3, if turn the SMB2 option on?

The media player is not Windows in anyway. I do access the NAS device from Windows 10 based machines when moving archive video files to it. But that is secondary use. Primary and most access is by the media player.

How do I use the SMB2 option in my setting?

 

[Iwakan]

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

Same here, now my NAS sleeps for hours but I have a new issue that maybe is related to this new setting. If NAS goes to sleep for more than an hour then is impossible to reach it over VPN (can't wake up again) but if I try to access it from LAN wakes up normally.

 

[RMerlin]

Does leaving it off default to SMB3? Force SMB2, turning off SMB3, if turn the SMB2 option on?

No, the default is the old NTLM protocol, which you might think of it as being "SMB 1.0".

How do I use the SMB2 option in my setting?

It's not something you "use". SMB clients will automatically negotiate which protocol version to use with the server, based on which protocol they both support. Most embedded devices are limited to NTLM, as they use very old versions of Samba, and SMB 2 is also more CPU intensive (the reason why it's kept disabled in Asuswrt-Merlin). You need something based on Samba 3.6 or higher to support SMB 2. SMB 3 was added in Samba 4.

Your NAS lets you choose it because it's also a server, not a client.

Windows supports SMB 2 since Vista, and SMB 3 since Windows 8.

 

[RMerlin]

Same here, now my NAS sleeps for hours but I have a new issue that maybe is related to this new setting. If NAS goes to sleep for more than an hour then is impossible to reach it over VPN (can't wake up again) but if I try to access it from LAN wakes up normally.

The ARP entry most likely expires after a while. Search the forums on how to configure a "static ARP entry" (I don't remember the specifics, sorry).

 

[GSpock]

The ARP entry most likely expires after a while. Search the forums on how to configure a "static ARP entry" (I don't remember the specifics, sorry).

arp -s ip-addr mac-addr
eg:
arp -s 192.168.1.11 01:02:03:04:05:06

arp -a to view all existing entries (PERM will show besides the one you have defined as static)

Rgds,
GS

 

[CiscoX]

Hi,
7 days uptime without any problems on this firmware
Thank you very much for your work RMerlin

 

[splatee]

Working great on 87R. Thank you RMerlin

 

[Ache]

About IPv6 problem, I have tunnel 6in4 and it dies after a while (from minutes to several hours) if CTF is on. Simple workaround: turn off CTF. This is old ASUS bug:
http://vip.asus.com/forum/view.aspx...d_id=11&model=RT-AC66U&page=1&SLanguage=en-us

 

[Eric Lieb]

Been having a problem with 380.58 on my AC66R. Devices on the 2.4 ghz signal lose internet connection randomly and don't reestablish. Problem has been exhibited on an Ipad4, Sensi Wifi Thermostat, Asus ul80vt using an Intel 5100 and a Raspberry Pi 2 using a wifi usb adapter.

I recently replaced 1 of the antenna with a

• Alfa APA-M25 2.4/5 GHz dual band directional 10 dBi panel antenna for 802.11ac/n

 

[BeachBum]

Im currently running 380.57 in Wireless AP mode. Would it be ok to upgrade in this mode?

 

[RMerlin]

arp -s ip-addr mac-addr
eg:
arp -s 192.168.1.11 01:02:03:04:05:06

arp -a to view all existing entries (PERM will show besides the one you have defined as static)

Rgds,
GS

Thanks. I would put these in a user script such as services-start to have them re-applied every reboot.

 

[RMerlin]

Im currently running 380.57 in Wireless AP mode. Would it be ok to upgrade in this mode?

Yes.

 

[Marc66]

Updated my AC-66U from 378.55 to 380.58 this afternoon and everything is fine. My router is used only as a router (no IPv6, WiFi, VPN, DDNS, Samba, FTP, Firewall filters, Media services, etc.). Only a USB key formated in Ext3 for Logs and John's NVRAM backup tool.

- Remove USB drive
- Flashed 380.58 over 378.55
- Did a Factory reset
- Connected USB drive
- Reconfigured

* Performance is as good as before
* RAM usage = 48 MB
* CPU usage around 2%

 

[TheOldMan]

About IPv6 problem, I have tunnel 6in4 and it dies after a while (from minutes to several hours) if CTF is on. Simple workaround: turn off CTF. This is old ASUS bug:
http://vip.asus.com/forum/view.aspx...d_id=11&model=RT-AC66U&page=1&SLanguage=en-us

My rt-ac68u ipv6 was purring along until 380.58 was installed. I kept losing ipv6 like the above user said. How did this bug sneak back in if it was taken care of previously?

 

[Yanoh]

RT-AC66U upgraded to 380.58 reboots every 10 mins in repeater mode. Had the same thing with 380.57 but was every 5 mins. Had to return to 378.56_2 before repeater mode is stable. Works fine in Wireless router mode.

 

[nagle3092]

Anyone else have their bandwidth limiter QoS client list clearing out on its own? Is there a limit on how fast your connection is to use it? I've had no issues with it since release (88U) and today my ISP bumped me from 10 down to 25 down but all my clients keep clearing out. Tried factory resting and same thing.

Edit: Seems like they are sticking again now.