Asuswrt-Merlin 380.59 is now available

[ubimea]

Installed Merlin release firmware 380.59 on RT-AC87R set as access point and RT-AC3200 as router. Forced manual reboot before and after update, then powered off from the mains with both devices before final power back on. Everything seems to work just fine, lots of attached wired and wireless clients with plain vanilla set up but no issues to report. Thank you Merlin for making this firmware available.

 

[mirage22]

Hi Merlin, I see a lot of

Jul 21 08:52:34 kernel: [truncated] L/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/npch ==NULL/np

in the System logs. This was not there before the update. Any idea what could be the issue?

Hi Merlin, I used to see a lot of that error with the earlier builds. This error used to fill my syslog.

With the .58 update the error came down drastically to a single line a few times a day.

After the upgrade to.59, i haven't seen the error in the last 6 odd hours of up-time.

 

[malinois1]

After updating from beta 2 should we do a factory reset and reconfigure manually?

 

[MarkRH]

Put this on my RT-AC68U from beta 2 and so far no problems after 3 days. I did the update with no reset afterwards since everything seemed fine.

 

[lewekleonek]

First off all, thank you for all the hard work.

I have update my RN-N66U from 380.58 -> 380.59 few hours ago.
I started seeing issues with clients not showing up in the client list. I saw the number of connected clients but no luck trying to get them in the drop-downs throughout the interface.
I have done the factory reset to no avail.
In addition to clients not showing up in the UI where you should normally see them, I have seen that Tools page is displaying "Querying switch..." in the Ethernet Ports section. No amount of reboots/resets would fix that.

I flashed back to 380.58 and things started working again.

--- edit ---
I found this post just a minute ago: http://www.snbforums.com/threads/be...-beta-2-is-available.32266/page-9#post-258419

What invalid host name would that be, the one with the space in it, a hyphenated one?

 

[isr25]

Ok... I think I messed up. I have been using merlin for a few years now on my Asus AC66U. I saw a new update on Asus's OFW 3.0.0.4.380.3264, so installed it to check it out. Installed it just fine and after testing a few of it's functions, I wanted to return to Merlin 380.59 (was using 380.57 previously) and uploaded the new firmware, it wouldn't install!

there is a dialog box that says upgrade unsuccessful (as per attached). Help!

 

[isr25]

Oh
I think its mean u cant go back to .59 now
Correct me if im wrong

http://www.snbforums.com/threads/asus-rt-ac68u-firmware-3-0-0-4-380-3264.32506/

This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. <-- God damn it, I missed that part!

 

[RMerlin]

Channels 36 to 48 are not DFS though. Those channels shouldn't be affected.

Whenever I add a guest network on 5ghz, the Channel I chose won't be used but instead it'll use a DFS channel. This is on my RT-AC87U, is that a similar issue?

The RT-AC5300 has two separate 5 GHz radio, which must operate in separate band. Therefore one of the two radios must use DFS channels when in Europe.

 

[RMerlin]

After the upgrade to.59, i haven't seen the error in the last 6 odd hours of up-time.

That's because Asus simply removed that logging entry from the kernel.

 

[RMerlin]

After updating from beta 2 should we do a factory reset and reconfigure manually?

Shouldn't be necessary.

What invalid host name would that be, the one with the space in it, a hyphenated one?

Anything with apostrophes, quotes or accented characters.

 

[pengful]

Hey Merlin, thanks for the great work. One question. Is it normal for wired connection speed to degrade after turning on QoS?
- Before turning on QoS: ~800 Mbps (DL)/ ~900 Mbps (UL) but
- After turning on QoS: ~600 Mbps (DL)/ ~500 Mbps (UL)
FYI, I am on 1 Gbps Fibre plan.

 

[Iwakan]

I have same problem

New app version released on AppStore. Issue fixed

 

[wpte]

Ok... I think I messed up. I have been using merlin for a few years now on my Asus AC66U. I saw a new update on Asus's OFW 3.0.0.4.380.3264, so installed it to check it out. Installed it just fine and after testing a few of it's functions, I wanted to return to Merlin 380.59 (was using 380.57 previously) and uploaded the new firmware, it wouldn't install!

there is a dialog box that says upgrade unsuccessful (as per attached). Help!

Try with the Firmware restoration tool?

 

[pengful]

Hey Merlin, thanks for the great work. One question. Is it normal for wired connection speed to degrade after turning on QoS?
- Before turning on QoS: ~800 Mbps (DL)/ ~900 Mbps (UL) but
- After turning on QoS: ~600 Mbps (DL)/ ~500 Mbps (UL)
FYI, I am on 1 Gbps Fibre plan.

Ok, I got the answer. Known fact; Enabling QoS will disable CTF (Cut Through Forwarding) aka NAT acceleration

 

[charlie2alpha]

Ok, I got the answer. Known fact; Enabling QoS will disable CTF (Cut Through Forwarding) aka NAT acceleration

To be more precise, enabling Traditional QOS will disable CTF. Adaptive QOS will keep CTF enabled.

 

[spikehome]

i have a issue also
Upgraded mu rt68u from RT-AC68U_380.58_0 to RT-AC68U_380.59_0

i use jffs and a firewall script
now i cannot access remote my router
Here my script:
#!/bin/sh
touch /tmp/@@@services-start
/usr/sbin/iptables -I INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port 5445 -j ACCEPT
/usr/sbin/iptables -I INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port 22 -j ACCEPT
/usr/sbin/iptables -t nat -I VSERVER -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 80 -j DNAT --to 192.168.6.210:80
/usr/sbin/iptables -t nat -I VSERVER -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 8080 -j DNAT --to 192.168.6.201:80
/usr/sbin/iptables -t nat -I VSERVER -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 8081 -j DNAT --to 192.168.6.251:80
/usr/sbin/iptables -t nat -I VSERVER -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 5000 -j DNAT --to 192.168.6.210:5000
/usr/sbin/iptables -t nat -I VSERVER -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 5001 -j DNAT --to 192.168.6.210:5001
/usr/sbin/iptables -t nat -I VSERVER -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 6789 -j DNAT --to 192.168.6.210:6789

The first 2 rules seems not to work and these are for access the router port 5445 for http and the ssh
The other rules work good.
what is wrong?
the xxx.xxx.xxx.xxx ip is everywhere the same and it is my work ip number.

 

[archiel]

Check the web browser console for any Javascript error that might be preventing the page from working.

Can you explain in more detail?
Thank you.

 

[mstombs]

I really like the feature to be able to sort the manual dhcp list. Only gripes it is not in the changelog on P1 of this thread - and nothing on the web page to encourage you to start clicking on the column headers - a hidden gem?

 

[barcote]

Hi
Thank you Merlin for all your efforts on this great firmware.

I just updated to 380.59 on AC87U to find all my DLNA devices disappeared. Checked with smart TV, laptops and smart phones all showing nothing. DLNA I miss is synology NAS media server but equally effects other DLNA devices which usually appear (though I don't in practice use) e.g. windows DLNA, logitech server etc. Other networking functions remain functioning as normal.

Downgrading back to previous merlin release on the AC87U fixes the problem and all DLNA devices show up again.

Is there a setting which I am overlooking in the 380.59 firmware or is this a bug?

Many thanks for your help!

 

[Mikeyy]

I'm reading about new update by ASUS in relation with this Merlin's firmware.

ASUS RT-AC68U Firmware 3.0.0.4.380.3264

Releases note:
ASUS has been dedicated to cooperate with third party developers to come up with more innovative features.
To comply with regulatory amendments, we have modified firmware verification rule to ensure better firmware quality.
This version is not compatible with all previously released ASUS firmware and uncertified third party firmware.

Can someone elaborate on this? What does it mean?

EDIT: http://www.snbforums.com/threads/asus-firmware-will-change-the-verification-method.32357/