Release Asuswrt-Merlin 386.5 is now available

[Gary_Dexter]

Do you have multicast routing enabled under IPTV in LAN settings?

Nope. Disabled.
These only started appearing following upgrading to _5 from _4

 

[DirtyFlash]

I upgraded a AC1900 aka AC68U from 386.4 to 386.5 and it was for the most part uneventful as usual. One thing that was unusual was at the end of the upgrade process it noted the need to manually reboot the router. Just as I was about to walk over to the router to do so, it magically rebooted by itself. Anyone have any thoughts as to why that appeared at the end of the upgrade process?

 

[ColinTaylor]

I upgraded a AC1900 aka AC68U from 386.4 to 386.5 and it was for the most part uneventful as usual. One thing that was unusual was at the end of the upgrade process it noted the need to manually reboot the router. Just as I was about to walk over to the router to do so, it magically rebooted by itself. Anyone have any thoughts as to why that appeared at the end of the upgrade process?

http://www.snbforums.com/threads/speed-diff-for-openvpn-on-rt-ac68u-and-rt-ac86u.77523/post-748840

 

[Clark Griswald]

All good over here! Sometimes the good ole nuclear option does the trick..

say that quietly, yest ye invoke @L&LD

Latest RMerlin FW working well!

I haven't noticed any issues reported RE: AXE11000, which is obviously another Gold Star for RMerlin's talent, and hope for the upcoming routers gaining his support!

 

[predatorz]

Dirty upgrade from 386.4 to 386.5 on RT-AC88U, everything ok.
Thanks for new firmware.

 

[ColinTaylor]

Geforce NOW QoS Bug

I'm assuming this is a bug. But as I don't use QoS, let alone Geforce NOW QoS, I can't test for it.

Back in October I spotted what appears to be two typos in qos.c which presumably would impact video traffic. The typos are still present in the current release.

# nvram get nvgfn_ch_rulelist
audio>udp>49003<mic>udp>49004<video>udp>49005<control>tcp>49006

https://github.com/RMerl/asuswrt-me...8c839e9aab9/release/src/router/rc/qos.c#L2112

    /* fixed ports */
    fprintf(f, "$TFA parent 1: prio 10 protocol ip u32 match ip protocol 17 0xff match ip dport %d 0xffff flowid 1:10\n", nvfgn_GetQoSChannelPort("audio"));
    fprintf(f, "$TFA parent 1: prio 10 protocol ip u32 match ip protocol 17 0xff match ip dport %d 0xffff flowid 1:10\n", nvfgn_GetQoSChannelPort("mic"));
    fprintf(f, "$TFA parent 1: prio 10 protocol ip u32 match ip protocol 17 0xff match ip dport %d 0xffff flowid 1:10\n", nvfgn_GetQoSChannelPort("vedio"));
    fprintf(f, "$TFA parent 1: prio 10 protocol ip u32 match ip protocol 17 0xff match ip dport %d 0xffff flowid 1:10\n", nvfgn_GetQoSChannelPort("control"));
    fprintf(f, "$TFA parent 1: prio 10 protocol ip u32 match ip protocol  6 0xff match ip dport %d 0xffff flowid 1:10\n", nvfgn_GetQoSChannelPort("control"));

https://github.com/RMerl/asuswrt-me...8c839e9aab9/release/src/router/rc/qos.c#L2165

    /* fixed ports */
    fprintf(f, "$TFAU parent 2: prio 10 protocol ip u32 match ip protocol 17 0xff match ip sport %d 0xffff flowid 2:10\n", nvfgn_GetQoSChannelPort("audio"));
    fprintf(f, "$TFAU parent 2: prio 10 protocol ip u32 match ip protocol 17 0xff match ip sport %d 0xffff flowid 2:10\n", nvfgn_GetQoSChannelPort("mic"));
    fprintf(f, "$TFAU parent 2: prio 10 protocol ip u32 match ip protocol 17 0xff match ip sport %d 0xffff flowid 2:10\n", nvfgn_GetQoSChannelPort("vedio"));
    fprintf(f, "$TFAU parent 2: prio 10 protocol ip u32 match ip protocol 17 0xff match ip sport %d 0xffff flowid 2:10\n", nvfgn_GetQoSChannelPort("control"));
    fprintf(f, "$TFAU parent 2: prio 10 protocol ip u32 match ip protocol  6 0xff match ip sport %d 0xffff flowid 2:10\n", nvfgn_GetQoSChannelPort("control"));

 

[IshWishDish]

Have you removed any USB attached devices first?

Thanks, I did just try that but no luck. I removed the USB drive and rebooted, then tried flashing again, but it just hangs at Applying... forever with no status change.

 

[erkme73]

I apologize if this has been addressed in the previous 9 pages, but I could not find it. I tried updating from _4 to _5 on my RT-AC68U using the admin page. All appeared to work, no errors, however, it ended up stuck on the mini-cfe page. I apparently forgot to pull the USB stick (diversion) before the upgrade.

In any case, I've now reset the nvramvia the prompt on the mini-cfe and through the wps button combination press. It kept rebooting about every minute, so loading the .trx from the cfe didn't work.

Finally I pulled the router and pressed all the buttons at the same time on power up. Now it stays solid on the CFE and I was able to reinstall 386_5 from the CFE. I got the complete notice, but after a reboot (both software and hardware), it returns to the cfe screen and reboots every minute.

After again doing the three button reset, it stays on cfe screen and I uploaded 386_4. Again it completed, but still reboots every minute or so, staying on the CFE screen.

Am I missing a step? How do I get it to boot to the firmware vs. the CFE? FWIW this is my daily driver router that has been rock solid on on all the latest releases for the last three years.

 

[learning_curve]

Hi @RMerlin I have just updated 386.4 > 386.5 (dirty) and was hoping the the asuscomm DDNS would now be working on IPv6, however I can only find my address on IPv4. I know that you disabled this in the previous release inadyn: rc: disable IPv6 support · RMerl/asuswrt-merlin.ng@8c0194d · GitHub, but I thought that the issue had been fixed in their firmware 3.0.0.4.386.46065 and would now be working.

Before I annoy my family by reverting to standard Asus, checking if it works there, and reverting can you confirm if you think that it should be working in 386.5.

Apart from this, everything appears to be working fine.

Thanks, Archiel

AFAIK This ^^ won't be fixed by Asus (and then in due course, Merlin...) until, Asus finalise and officially release their own 386.5 series of firmware. The latest official Asus release for my own router is covered in this thread but as you can see, it's still 386.4 series... Your own router will no doubt have a different Asus release, but isn't it also, 386.4 series firmware?

I am also very keen for this to be fixed (as I do use it - see posts on other threads) but IMHO my own router is now running on Asuswrt-Merlin 386.5_0 which, is without doubt, the best firmware (for me) that I've ever used on this router & that's despite this item (IPv6 DDNS) not yet... being fully functional. IMHO It IS 100% better than the latest Asus FW (link ^^)

 

[pinkgrae]

Thanks, I did just try that but no luck. I removed the USB drive and rebooted, then tried flashing again, but it just hangs at Applying... forever with no status change.

I had this happen when I upgraded my AC86U from 386.3 to 386.4. I disabled jffs scripts, rebooted, removed the usb stick, and then was able to flash the new firmware successfully. Then I reenabled jffs scripts, rebooted again, and all done.

Haven't had to do any of that for upgrades since then - most recent one (from 386.4_alpha2 to 386.5) went without a hitch despite me forgetting to remove the usb stick. All stable on both router and node for the last 48 hours.

 

[RAH-66]

durty upgrade 386.2_2 -> 386.5 work fine

 

[Oferlaor]

dirty upgrade from 386.3.2 works great!

I do get this at the beginning of my logs after each reboot:

(there's a ton of them).

Jan 11 08:29:18 dnsmasq[2036]: failed to send packet: Operation not permitted
Jan 11 08:29:18 dnsmasq[2036]: failed to send packet: Operation not permitted
Jan 11 08:29:18 dnsmasq[2036]: failed to send packet: Operation not permitted
Jan 11 08:29:18 dnsmasq[2036]: failed to send packet: Operation not permitted
Jan 11 08:29:19 dnsmasq[2036]: failed to send packet: Operation not permitted

 

[ReneSL]

Smooth update from 386.4 here, everything working perfectly. Thanks RMerlin!

 

[eibgrad]

dirty upgrade from 386.3.2 works great!

I do get this at the beginning of my logs after each reboot:

(there's a ton of them).

These are very common, even on other firmware (e.g., DD-WRT). I'm pretty sure it's due to DNSMasq trying to access the internet before the WAN is up and available. DNSMasq is usually started very early in the bootup process, so this is to be expected until the WAN is fully functional.

That said, I wouldn't normally expect to see a "ton" of them (whatever that means).

 

[jb68]

Solid Upgrade for my routers, Thanks again Merlin, always appreciate it

 

[zd59]

I had this happen when I upgraded my AC86U from 386.3 to 386.4. I disabled jffs scripts, rebooted, removed the usb stick, and then was able to flash the new firmware successfully. Then I reenabled jffs scripts, rebooted again, and all done.

Haven't had to do any of that for upgrades since then - most recent one (from 386.4_alpha2 to 386.5) went without a hitch despite me forgetting to remove the usb stick. All stable on both router and node for the last 48 hours.

I had serious issues with WiFi 2.4GHz on 386.4, and numerous posts reported that also. So I downgraded back to 386.3.2, which is rock solid.
Would you be so kind, to report your experience with WiFi 2.4 GHz on 386.5. I do not want to upgrade prior positive reports, as my job is dependent on a 100% working WiFi.
Thanks.

 

[BeHappy]

Started to upgrade my RT-AC86U from 386.4 to 386.5_0 and got this message. Never experienced an unsuccessful message before. Tried several times to upgrade but without a positive result. Any idea how to solve this.
Edit: Upgraded my RT-AC68U without any problem.

 

[XIII]

View attachment 40014

Started to upgrade my RT-AC86U from 386.4 to 386.5_0 and got this message. Never experienced an unsuccessful message before. Tried several times to upgrade but without a positive result. Any idea how to solve this.
Edit: Upgraded my RT-AC68U without any problem.

Did you try rebooting without a USB device attached, just before flashing?

 

[pinkgrae]

I had serious issues with WiFi 2.4GHz on 386.4, and numerous posts reported that also. So I downgraded back to 386.3.2, which is rock solid.
Would you be so kind, to report your experience with WiFi 2.4 GHz on 386.5. I do not want to upgrade prior positive reports, as my job is dependent on a 100% working WiFi.

I'm running about a dozen IoT devices on my 2.4GHz guest network - connection for all of them has been stable since I flashed 368.5 two days ago. This includes my 'problem child' (TP-Link HS100 plug towards the edge of reception in the far corner of the garden), which has been connected for over 53 hours solid now.

 

[BeHappy]

Did you try rebooting without a USB device attached, just before flashing?

Thanks. Removing the USB device was indeed the solution!