Asuswrt-Merlin 378.56_2 is now available

[joegreat]

Just purchased AC68P and flashed Asuswrt-Merlin 378.56_2.

Factory reset after update done?

 

[freeman_g]

The NAT loopback bypasses NAT acceleration, so NAT is then done by the CPU, hence the high load.

Thank you. Is it software or hardware limitation? Is it possible to use CPU2 to increase the speed?

 

[freeman_g]

Factory reset after update done?

Sure. I believe that the problem is much deeper that just factory reset. For example, N65U/N56U can offload CPU with hardware NAT acceleration (even in case of NAT loopback) but it is possible as Padavan (major alternative frimware maintainer) has source code. In case of AC68P I am not sure if such offload is possible in principle.

 

[RMerlin]

Thank you. Is it software or hardware limitation? Is it possible to use CPU2 to increase the speed?

Nothing more that I can do about it.

 

[hasafly]

And what about 4G dongle support, like Huawei E3276 -150MB??

 

[Chazall1]

I have been running the latest Johns fork for the past two weeks and just wanted to confirm the proper way to test your latest beta. Can I load 378.56_2 or beta and reset? Thanks

 

[neil0311]

Doing a direct flash to 378.56_2 is fine, as long you're coming from a fairly recent firmware. 378.56 is fine. 378.55 would require a factory default reset only for the RT-AC87U, due to the new QTN SDK.

I have not yet updated either my RT-AC68P or RT-N66U from 378.55 to .56_2. Given real experiences since release, is the above from Merlin still correct, that a factory reset is NOT required for that update?

Any issues that change this guidance?

 

[joegreat]

I have not yet updated either my RT-AC68P or RT-N66U from 378.55 to .56_2. Given real experiences since release, is the above from Merlin still correct, that a factory reset is NOT required for that update?

Not needed to do a factory reset.

Any issues that change this guidance?

After reading the 20 pages for you: No issue found!

 

[kitch9]

Does anyone have any idea why my phone would start throwing up dns errors after working fine for a while on 2.4ghz wifi on a AC68U on this firmware?

It doesn't have any issue using the Merlin Fork firmware or 5ghz wi fi... I can work around it for now but it would be handy to sort it.

 

[ml70]

AC66: coming from 378.55, 378.56_2 killed my 5G wifi. Reset. Turn 5G radio off/on. Reload older settings. Many resets. Nothing helps. Moved back to 378.55, 5G radio's not coming back.
Seems it's a full factory reset and reconfigure boot camp again. *sigh*

At first there is no 5G channel at all, as seen by a wifi scanner. Then noticed that on Wireless>General>Control Channel, which is on Auto (as are all other settings) the box [] Auto select channel including band1 channels, is not ticked. Tick and reset, and finally 5G radio can at least be seen on wifi scanner. But connecting to it on any client is impossible.

This happened long time ago with some other build, and only a full factory reset and reconfigure helped.

 

[neil0311]

After reading the 20 pages for you: No issue found!

I read through the thread as well, which is how I saw Merlin's post. Didn't see anyone post negative issues, but wanted to be sure. Thanks for the confirmation.

 

[alruf]

Asuswrt-Merlin is now available for all supported models, including the RT-N66U build.

Summary of changes since 378.55:

• Merged with Asus GPL 378_9177, which includes numerous fixes and tweaks, and improvements to the networkmap. This includes the newer Quantenna driver for the RT-AC87U, which resolves connectivity issues on the 5 GHz band, however it still causes some battery drain on that band. The only workaround is to revert to 378.55 if this is a problem for you.
• Support was added for the (unreleased yet) RT-AC88U. Thanks to Asus for providing a development sample.
• Enhancements to syslog handling. The default log level can now be configured (it used to be hardcoded to Emergency). This is especially useful to users who log to a remote syslog server.
• Editable entries for the DHCP static lease, virtual servers and prot triggers pages.
• Various component updates: miniupnpd, openvpn, dropbear and minidlna were updated to their latest versions.
• Various issues related to networkmap were resolved, especially handling of long hostnames.
• You can now configure up to five separate OpenVPN clients, to match Asus's stock FW.
• Numerous other fixes, please see the complete changelog for details

@RMerlin - thank you for your awesome contributions! I have searched a lot to find an answer to my issue but I have to resort to asking you directly as I have not found a solution in weeks. I have an RT-AC3200 running 378.56_2 which seems to have a persistent Network Map issue. After rebooting my router I can access the network map page for a short period of time, after which it shows up all scrolled up and mostly blank. The attached image is all I see and I cannot scroll up or down or even access any other part of the GUI. I have resorted to keeping a link to a different page (any) and as long as I do not click on the network map page I can use the router as normal.

Below is my syslog since my last reboot yesterday.

Dec  9 14:30:55 rc_service: ntp 539:notify_rc restart_upnp
Dec  9 14:30:55 rc_service: waitting "start_firewall" via udhcpc ...
Dec  9 14:30:55 kernel: nf_conntrack_rtsp v0.6.21 loading
Dec  9 14:30:55 kernel: nf_nat_rtsp v0.6.21 loading
Dec  9 14:30:55 kernel: tfat warning (device sda1, pid 725): fat_fill_super(): FAT volume 16GB is dirty.  You should unmount and repair it.
Dec  9 14:30:55 usb: USB vfat fs at /dev/sda1 mounted on /tmp/mnt/16GB.
Dec  9 14:30:55 rc_service: udhcpc 563:notify_rc start_upnp
Dec  9 14:30:55 rc_service: waitting "stop_upnp" via udhcpc ...
Dec  9 14:30:56 WAN Connection: WAN was restored.
Dec  9 14:30:57 ddns update: ez-ipupdate: starting...
Dec  9 14:30:57 rc_service: ntp 539:notify_rc restart_diskmon
Dec  9 14:30:57 disk_monitor: Finish
Dec  9 14:30:57 rc_service: hotplug 706:notify_rc restart_nasapps
Dec  9 14:30:57 rc_service: waitting "restart_diskmon" via ntp ...
Dec  9 14:30:57 ddns update: connected to members.dyndns.org (204.13.248.111) on port 80.
Dec  9 14:30:57 ddns update: request successful
Dec  9 14:30:57 ddns update: asusddns_update: 0
Dec  9 14:30:58 iTunes: daemon is stopped
Dec  9 14:30:58 FTP Server: daemon is stopped
Dec  9 14:30:59 disk monitor: be idle
Dec  9 14:30:59 ddns: ddns update ok
Dec  9 14:31:00 Samba Server: smb daemon is stopped
Dec  9 14:31:00 kernel: gro disabled
Dec  9 14:31:01 Timemachine: daemon is stopped
Dec  9 14:31:01 kernel: gro enabled with interval 2
Dec  9 14:31:01 kernel: * Make sure sizeof(struct sw_struct)=160 is consistent
Dec  9 14:31:02 kernel: sizeof forward param = 160
Dec  9 14:31:02 Samba Server: daemon is started
Dec  9 14:31:06 rc_service: udhcpc 563:notify_rc start_firewall
Dec  9 14:31:06 dhcp client: bound xxx.xxx.xxx.xxx via xxx.xxx.xxx.xxx during 600 seconds.
Dec  9 14:31:07 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Dec  9 14:31:25 crond[481]: time disparity of 188431 minutes detected
Dec  9 14:34:10 rc_service: httpd 479:notify_rc start_sig_check
Dec  9 15:00:59 disk_monitor: Got SIGALRM...
Dec  9 16:04:35 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 16:04:46 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 16:05:07 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 16:56:15 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 16:56:17 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 19:46:17 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 19:46:18 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 19:46:30 dnsmasq-dhcp[473]: Ignoring domain hp.local for DHCP host name HPPC118
Dec  9 23:00:59 disk_monitor: Got SIGALRM...

Would you kindly point me in the right direction?

Thanks!

 

[alruf]

Since I am not allowed to edit my previous post, I have to post again to add this:

In case it matters, "nvram show" tells me this about the space left:
size: 64020 bytes (1516 left)

Using @john9527 great backup script I noticed that I have two sets of DHCP static client lists which may be eating up the free space. I wonder if that may be part of the issue?

 

[john9527]

In case it matters, "nvram show" tells me this about the space left:
size: 64020 bytes (1516 left)

I'd consider that to be 'out of nvram' and can cause all sort of strange problems.

Try this one-liner via telnet/ssh to print the top 20 nvram variables by size (courtesy of @ryzhov-al )

nvram show | awk '{print length(), $0 | "sort -n -r"}' | cut -d"=" -f 1 | head -n 20

 

[alruf]

I'd consider that to be 'out of nvram' and can cause all sort of strange problems.

Try this one-liner via telnet/ssh to print the top 20 nvram variables by size (courtesy of @ryzhov-al )

nvram show | awk '{print length(), $0 | "sort -n -r"}' | cut -d"=" -f 1 | head -n 20

alruf@Olgiata_Router:/tmp/home/root# nvram show | awk '{print length(), $0 |
"sort -n -r"}' | cut -d"=" -f 1 | head -n 20
size: 64020 bytes (1516 left)
4481 nmp_client_list
1331 dhcp_staticlist
1326 custom_clientlist
624 sshd_dsskey
585 sshd_hostkey
540 vts_rulelist
384 rc_support
338 sshd_ecdsakey
323 webdav_smb_pc
146 fb_comment
120 qos_rulelist
109 wl2_acs_excl_chans
109 wl1_acs_excl_chans
92 2:pa5ga2
92 2:pa5ga1
92 2:pa5ga0
92 0:pa5ga2
92 0:pa5ga1
92 0:pa5ga0
88 fb_browserInfo
alruf@Olgiata_Router:/tmp/home/root#

I believe the extra entry to be: custom_clientlist

Is nmp_client_list a bit too big as well?

Would a backup, full reset, and restore with your utility resolve this? I believe I read it would not restore a variable that is no longer there if this is actually the case.

 

[john9527]

I'm admittedly not familiar with all the recent networkmap changes, but the first one on the list (nmp_client_list) seems like it may be starting to 'runaway'. custom_clientlist is valid and I think used if you start renaming clients. It's interesting that other than that first entry, there really isn't any set of vars that is eating up significant nvram space. What features do you have enabled?

What's the content of nmp_client_list?

nvram get nmp_clist_list

@RMerlin may be better able to comment on it's use.

 

[alruf]

I'm admittedly not familiar with all the recent networkmap changes, but the first one on the list (nmp_client_list) seems like it may be starting to 'runaway'. custom_clientlist is valid and I think used if you start renaming clients. It's interesting that other than that first entry, there really isn't any set of vars that is eating up significant nvram space. What features do you have enabled?

What's the content of nmp_client_list?

nvram get nmp_client_list

@RMerlin may be better able to comment on it's use.

It seems to have a list of host name, description and MAC address of current and OLD stuff that has not been connected to the network in many weeks if not one or two months. Is there a way to wipe it clean? Can I export, remove the variable, restore file permissions and finally restore the backup using your utility?

[EDIT: I used ...

nvram set nmp_client_list=""
nvram commit

... to clear the variable however I cannot reboot the router right now, and the Network Map page is still not working.

 

[john9527]

and the Network Map page is still not working.

Try turning on your browsers development console and look for script errors. Most common error is caused by having a client name that contains special characters.

 

[alruf]

Try turning on your browsers development console and look for script errors. Most common error is caused by having a client name that contains special characters.

There was indeed an error. Please see attached image. The nmp_client_list variable is back so something must have recreated it...

I took a look at the text in that variable and found 3 lines that seemed garbled:

<000f5001,3,3Ñ<000f6103e HolÁ<000f6103","Ot±<000f6103rs","¡<000f6103,"Von<000f6103one",
<e85shi S±<c42f90168c79>>HIKVISION DS-2C>>5>1>0>1>>NETGEAR>SmartTV>NETGEAR NTV300
<c52f,"Sma©<c52fTV & ¡<c42f9130x"
<00151<0015172<0015172@Laptñ<00151520<0015172<0015172<0015172<0015172 & Pe±$<00151520

These are the only ones that do not seem to follow a recurring format that I see in that variable. One of them is clearly one of my HikVision dome cameras, and since I have two, I am assuming one of the other illegible lines is the other HikVision camera. They have a super long Ethernet name that I cannot change. An email about changing the long names to Hikvision support a few weeks ago has yet to be answwered. When I get home I can try to physically disconnect the cameras, clear the variable, reboot the router, and see if the issue pops up after a few moments.

@RMerlin - I believe you had fixed the long name issue. Could this still be the same issue? What is the max number of chars that can be in the name?

 

[ekms]

Hi,

I just tried to upgrade my firmware to 378.56.2 for my AC68W. The current firmware I have is 376.49.4 which was from last year I believe, the firmware seems to have gone off successfully but after rebooting my firmware is still listed as 376.49.4 what do I have to do to upgrade it correctly?