What's new

Release Asuswrt-Merlin 386.4 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
This particular model downgrades itself to dual-band automatically. And it indeed happens overnight. High-end home router technology.
 
Also it looks like the update is a big one with a number of vulnerabilities, AI mesh issues, and DDNS using WAN IPV6 issues addressed. I'm sure Merlin will incorporate in a future update once ASUS releases the GPL.
A lot of these vulnerability fixes are already included in 386.4. Same with the DDNS fixes.
 
I am kinda surprised that reverting to 2.85 is only coming in 386.5 and not a 386.4_2, at least as of today.
I don't have time to work on a point release right now, and a new customer contract signed today means I probably won't have much time either for the next two weeks.

Today was the first time in nearly a week that I actually had time to eat lunch.
 
A lot of these vulnerability fixes are already included in 386.4. Same with the DDNS fixes.
That explains why I couldn't find 386_45958 or anything newer on ASUS-wrt official up until yesterday. Current now is 386_46061, but RMerlin was ahead of Asus itself for almost two weeks :D

Probably Pizza is my guess.
With stuffed crust

EDIT:
Just out of curiosity @RMerlin, and forgive my ignorance, but why aren't your releases and ASUS' own synchronized and having the same version-numbers? Why would they give you "older" GPLs and then release newer ones themselves sometime after? And what and who decides which ones you get, and why do you get those specifically and not the absolute latest? Just trying to learn about your process :) Also hope you get some well deserved rest the next few weeks.
 
Last edited:
Just out of curiosity @RMerlin, and forgive my ignorance, but why aren't your releases and ASUS' own synchronized and having the same version-numbers?
One of the reasons is Asus themselves don't release all models on the same firmware version, as they release each model independently. My own development model however has me releasing all models at the same time, which means I need the same code version for all my models - that means even if Asus doesn't release a firmware for some models for that same version.

The other reason is I get GPL code from Asus separately from their own release, as they send me code based on my own development cycle. Sometimes it's the same version as an intended release, sometimes it's a snapshot in time as they are themselves still busy working on things for an incoming release.

And finally, it's the only way I can get code ahead of time. Otherwise if I we have to wait for them to release something, it means I can only begin working after their own release is out. That would mean I would always be 1-2 months behind them.

So during my own development cycle, we just settle on a specific release that they feel is in a good enough state to be used as a base. Sometimes they send another update, or separate patches afterward if serious issues have been fixed on their end. This is why 386.4 is based on 45958, but it does contain a number of additional fixes that Asus had implemented after 45958. During the 386.4 development cycle I received two different GPL versions.

Why would they give you "older" GPLs and then release newer ones themselves sometime after?
They didn't. They gave me what was up-to-date at the time, which was early November for 45958. Development simply takes time, there's is a lot of work to do on my end after I receive GPL archives. So while I was working on 386.4, Asus didn't stop developing on their own end.
 
Now I’m hungry for a croque monsieur.
In Paris...

EDIT: Back in 2018 we had a layover in Paris on the way home from South Africa --> Toronto. Had enough time to get out to the city and see the sights.

zaoCxaA.png
 
I've been stable since 386.4's release date but had a crash today. Configuration changes since 386.3_2 include enabling IPv6 and an OpenVPN Client profile added but the crashlog makes me lean towards something around the USB subsystem. I'll check my external devices for errors and if it happens again, I'll use a new AC86U power plug I have hanging around.

Just wanted to throw this out as an FYI, unless someone has more insight.

Code:
crashlog: LOG
crashlog: <6>httpd (1268): drop_caches: 1
crashlog: <6>httpds (1267): drop_caches: 1
crashlog: <6>httpd (1268): drop_caches: 1
crashlog: <6>device tap11 entered promiscuous mode
crashlog: <6>IPv6: ADDRCONF(NETDEV_UP): tap11: link is not ready
crashlog: <6>IPv6: ADDRCONF(NETDEV_CHANGE): tap11: link becomes ready
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered disabled state
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered disabled state
crashlog: <6>br0: port 8(tap11) entered disabled state
crashlog: <3>usb usb3-port1: disabled by hub (EMI?), re-enabling...
crashlog: <6>usb 3-1: USB disconnect, device number 2
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131851 (offset 3694592 size 28672 starting block 661396)
crashlog: <3>Buffer I/O error on device sda1, logical block 661381
crashlog: <3>Buffer I/O error on device sda1, logical block 661382
crashlog: <3>Buffer I/O error on device sda1, logical block 661383
crashlog: <3>Buffer I/O error on device sda1, logical block 661384
crashlog: <3>Buffer I/O error on device sda1, logical block 661385
crashlog: <3>Buffer I/O error on device sda1, logical block 661386
crashlog: <3>Buffer I/O error on device sda1, logical block 661387
crashlog: <3>Buffer I/O error on device sda1, logical block 661388
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131869 (offset 0 size 0 starting block 630280)
crashlog: <3>Buffer I/O error on device sda1, logical block 630272
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131869 (offset 0 size 0 starting block 630287)
crashlog: <3>Buffer I/O error on device sda1, logical block 630276
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131354 (offset 0 size 0 starting block 661955)
crashlog: <3>Aborting journal on device sda1-8.
crashlog: <3>JBD2: Error -5 detected when updating journal superblock for sda1-8.
crashlog: <2>EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal
crashlog: <2>EXT4-fs (sda1): Remounting filesystem read-only
crashlog: <3>EXT4-fs (sda1): previous I/O error to superblock detected
crashlog: <3>lock_acquire[0]           (null) lock_hold[0]           (null)
crashlog: <3>lock_acquire[1]           (null) lock_hold[1]           (null)
crashlog: <3>lock_acquire[2]           (null) lock_hold[2]           (null)
crashlog: <3>lock_acquire[3]           (null) lock_hold[3]           (null)
crashlog: <1>Unable to handle kernel paging request at virtual address 1f90e000
crashlog: <1>pgd = ffffffc00182d000
crashlog: <1>[1f90e000] *pgd=0000000003d7a003, *pud=0000000003d7a003, *pmd=0000000000000000
crashlog: <0>Internal error: Oops: 96000006 [#1] PREEMPT SMP
crashlog: <4>CPU: 1 PID: 17188 Comm: hotplug Tainted: P           O    4.1.27 #2
crashlog: <4>Hardware name: Broadcom-v8A (DT)
crashlog: <4>task: ffffffc01918c0c0 ti: ffffffc003a20000 task.ti: ffffffc003a20000
crashlog: <4>PC is at __percpu_counter_add+0x34/0x110
crashlog: <4>LR is at clear_page_dirty_for_io+0xb0/0x100
crashlog: <4>pc : [<ffffffc0002bdd5c>] lr : [<ffffffc000105658>] pstate: 600001c5
crashlog: <4>sp : ffffffc003a23c10
crashlog: <4>x29: ffffffc003a23c10 x28: ffffffc01e76d300
crashlog: <4>x27: ffffffc000104ee0 x26: ffffffbe003aeb40
crashlog: <4>x25: 0000000000000000 x24: ffffffc003a23df8
crashlog: <4>x23: 0000000000000000 x22: ffffffc01e76d300
crashlog: <4>x21: ffffffc01e0b8200 x20: ffffffc01e76d300
crashlog: <4>x19: ffffffffffffffff x18: 0000000000000000
crashlog: <4>x17: 0000000000000220 x16: ffffffc01e76d308
crashlog: <4>x15: 0000000000000001 x14: 0000000000000001
crashlog: <4>x13: 0000000000000002 x12: ffffffc01e6a4d88
crashlog: <4>x11: 0000000000000012 x10: 0000000000000040
crashlog: <4>x9 : 0000000000000230 x8 : 0000000000000140
crashlog: <4>x7 : 0000000000000100 x6 : 000000001f90e000
crashlog: <4>x5 : 000000000000000c x4 : ffffffc003a23c10
crashlog: <4>x3 : ffffffc003a20000 x2 : 0000000000000010
crashlog: <4>x1 : 000000001f90e000 x0 : 0000000000000000
crashlog: <4>
crashlog: <0>Process hotplug (pid: 17188, stack limit = 0xffffffc003a20020)
crashlog: <4>Modules linked in: tun init_addr(          (null) -           (null)), core_addr(ffffffbffc13e000 - ffffffbffc1414ec)
...
crashlog: <0>Kernel panic - not syncing: Fatal exception
crashlog: <2>CPU0: stopping
crashlog: <4>CPU: 0 PID: 17189 Comm: hotplug Tainted: P      D    O    4.1.27 #2
crashlog: <4>Hardware name: Broadcom-v8A (DT)
crashlog: <0>Call trace:
crashlog: <4>[<ffffffc0000876d8>] dump_backtrace+0x0/0x150
crashlog: <4>[<ffffffc00008783c>] show_stack+0x14/0x20
crashlog: <4>[<ffffffc00050c4b8>] dump_stack+0x90/0xb0
crashlog: <4>[<ffffffc00008e730>] handle_IPI+0x190/0x1a0
crashlog: <4>[<ffffffc000080c70>] gic_handle_irq+0x88/0x90
crashlog: <4>Exception stack(0xffffffc003de3940 to 0xffffffc003de3a60)
crashlog: <4>[<ffffffc000083da8>] el1_irq+0x68/0xd8
crashlog: <4>[<ffffffc0000ccf28>] console_device+0x70/0x80
crashlog: <4>[<ffffffc00030e15c>] tty_open+0x29c/0x510
crashlog: <4>[<ffffffc000142540>] chrdev_open+0x98/0x198
crashlog: <4>[<ffffffc00013bf64>] do_dentry_open.isra.1+0x1c4/0x2f0
crashlog: <4>[<ffffffc00013cea0>] vfs_open+0x50/0x60
crashlog: <4>[<ffffffc00014b924>] do_last.isra.13+0x2dc/0xc20
crashlog: <4>[<ffffffc00014c2ec>] path_openat+0x84/0x5c0
crashlog: <4>[<ffffffc00014d920>] do_filp_open+0x30/0x98
crashlog: <4>[<ffffffc00013d2a0>] do_sys_open+0x140/0x228
crashlog: <4>[<ffffffc000185b34>] compat_SyS_open+0x1c/0x28
 
I've been stable since 386.4's release date but had a crash today. Configuration changes since 386.3_2 include enabling IPv6 and an OpenVPN Client profile added but the crashlog makes me lean towards something around the USB subsystem. I'll check my external devices for errors and if it happens again, I'll use a new AC86U power plug I have hanging around.

Just wanted to throw this out as an FYI, unless someone has more insight.

Code:
crashlog: LOG
crashlog: <6>httpd (1268): drop_caches: 1
crashlog: <6>httpds (1267): drop_caches: 1
crashlog: <6>httpd (1268): drop_caches: 1
crashlog: <6>device tap11 entered promiscuous mode
crashlog: <6>IPv6: ADDRCONF(NETDEV_UP): tap11: link is not ready
crashlog: <6>IPv6: ADDRCONF(NETDEV_CHANGE): tap11: link becomes ready
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered disabled state
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered forwarding state
crashlog: <6>br0: port 8(tap11) entered disabled state
crashlog: <6>br0: port 8(tap11) entered disabled state
crashlog: <3>usb usb3-port1: disabled by hub (EMI?), re-enabling...
crashlog: <6>usb 3-1: USB disconnect, device number 2
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131851 (offset 3694592 size 28672 starting block 661396)
crashlog: <3>Buffer I/O error on device sda1, logical block 661381
crashlog: <3>Buffer I/O error on device sda1, logical block 661382
crashlog: <3>Buffer I/O error on device sda1, logical block 661383
crashlog: <3>Buffer I/O error on device sda1, logical block 661384
crashlog: <3>Buffer I/O error on device sda1, logical block 661385
crashlog: <3>Buffer I/O error on device sda1, logical block 661386
crashlog: <3>Buffer I/O error on device sda1, logical block 661387
crashlog: <3>Buffer I/O error on device sda1, logical block 661388
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131869 (offset 0 size 0 starting block 630280)
crashlog: <3>Buffer I/O error on device sda1, logical block 630272
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131869 (offset 0 size 0 starting block 630287)
crashlog: <3>Buffer I/O error on device sda1, logical block 630276
crashlog: <4>EXT4-fs warning (device sda1): ext4_end_bio:332: I/O error -5 writing to inode 131354 (offset 0 size 0 starting block 661955)
crashlog: <3>Aborting journal on device sda1-8.
crashlog: <3>JBD2: Error -5 detected when updating journal superblock for sda1-8.
crashlog: <2>EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal
crashlog: <2>EXT4-fs (sda1): Remounting filesystem read-only
crashlog: <3>EXT4-fs (sda1): previous I/O error to superblock detected
crashlog: <3>lock_acquire[0]           (null) lock_hold[0]           (null)
crashlog: <3>lock_acquire[1]           (null) lock_hold[1]           (null)
crashlog: <3>lock_acquire[2]           (null) lock_hold[2]           (null)
crashlog: <3>lock_acquire[3]           (null) lock_hold[3]           (null)
crashlog: <1>Unable to handle kernel paging request at virtual address 1f90e000
crashlog: <1>pgd = ffffffc00182d000
crashlog: <1>[1f90e000] *pgd=0000000003d7a003, *pud=0000000003d7a003, *pmd=0000000000000000
crashlog: <0>Internal error: Oops: 96000006 [#1] PREEMPT SMP
crashlog: <4>CPU: 1 PID: 17188 Comm: hotplug Tainted: P           O    4.1.27 #2
crashlog: <4>Hardware name: Broadcom-v8A (DT)
crashlog: <4>task: ffffffc01918c0c0 ti: ffffffc003a20000 task.ti: ffffffc003a20000
crashlog: <4>PC is at __percpu_counter_add+0x34/0x110
crashlog: <4>LR is at clear_page_dirty_for_io+0xb0/0x100
crashlog: <4>pc : [<ffffffc0002bdd5c>] lr : [<ffffffc000105658>] pstate: 600001c5
crashlog: <4>sp : ffffffc003a23c10
crashlog: <4>x29: ffffffc003a23c10 x28: ffffffc01e76d300
crashlog: <4>x27: ffffffc000104ee0 x26: ffffffbe003aeb40
crashlog: <4>x25: 0000000000000000 x24: ffffffc003a23df8
crashlog: <4>x23: 0000000000000000 x22: ffffffc01e76d300
crashlog: <4>x21: ffffffc01e0b8200 x20: ffffffc01e76d300
crashlog: <4>x19: ffffffffffffffff x18: 0000000000000000
crashlog: <4>x17: 0000000000000220 x16: ffffffc01e76d308
crashlog: <4>x15: 0000000000000001 x14: 0000000000000001
crashlog: <4>x13: 0000000000000002 x12: ffffffc01e6a4d88
crashlog: <4>x11: 0000000000000012 x10: 0000000000000040
crashlog: <4>x9 : 0000000000000230 x8 : 0000000000000140
crashlog: <4>x7 : 0000000000000100 x6 : 000000001f90e000
crashlog: <4>x5 : 000000000000000c x4 : ffffffc003a23c10
crashlog: <4>x3 : ffffffc003a20000 x2 : 0000000000000010
crashlog: <4>x1 : 000000001f90e000 x0 : 0000000000000000
crashlog: <4>
crashlog: <0>Process hotplug (pid: 17188, stack limit = 0xffffffc003a20020)
crashlog: <4>Modules linked in: tun init_addr(          (null) -           (null)), core_addr(ffffffbffc13e000 - ffffffbffc1414ec)
...
crashlog: <0>Kernel panic - not syncing: Fatal exception
crashlog: <2>CPU0: stopping
crashlog: <4>CPU: 0 PID: 17189 Comm: hotplug Tainted: P      D    O    4.1.27 #2
crashlog: <4>Hardware name: Broadcom-v8A (DT)
crashlog: <0>Call trace:
crashlog: <4>[<ffffffc0000876d8>] dump_backtrace+0x0/0x150
crashlog: <4>[<ffffffc00008783c>] show_stack+0x14/0x20
crashlog: <4>[<ffffffc00050c4b8>] dump_stack+0x90/0xb0
crashlog: <4>[<ffffffc00008e730>] handle_IPI+0x190/0x1a0
crashlog: <4>[<ffffffc000080c70>] gic_handle_irq+0x88/0x90
crashlog: <4>Exception stack(0xffffffc003de3940 to 0xffffffc003de3a60)
crashlog: <4>[<ffffffc000083da8>] el1_irq+0x68/0xd8
crashlog: <4>[<ffffffc0000ccf28>] console_device+0x70/0x80
crashlog: <4>[<ffffffc00030e15c>] tty_open+0x29c/0x510
crashlog: <4>[<ffffffc000142540>] chrdev_open+0x98/0x198
crashlog: <4>[<ffffffc00013bf64>] do_dentry_open.isra.1+0x1c4/0x2f0
crashlog: <4>[<ffffffc00013cea0>] vfs_open+0x50/0x60
crashlog: <4>[<ffffffc00014b924>] do_last.isra.13+0x2dc/0xc20
crashlog: <4>[<ffffffc00014c2ec>] path_openat+0x84/0x5c0
crashlog: <4>[<ffffffc00014d920>] do_filp_open+0x30/0x98
crashlog: <4>[<ffffffc00013d2a0>] do_sys_open+0x140/0x228
crashlog: <4>[<ffffffc000185b34>] compat_SyS_open+0x1c/0x28
Yep, corrupted USB filesystem.
 
Hi
I've done a fresh install of latest 386.4 on AC86U (main router), with two AC68U as AiMesh nodes.

After this update, Guest Network 1 (the one I use to distribute a guest network all around the nodes) doesn't work anymore.
Clients doesn't get IP.

Is anybody else experiencing this? Any fix?
I've already done a hard reset of everything.

Best regards
Hi,
please excuse me, any hint on this?

Setting "Intranet access = ENABLED" solved the problem, however this makes no sense.

Best regards
 
Hi,
please excuse me, any hint on this?

Setting "Intranet access = ENABLED" solved the problem, however this makes no sense.

Best regards
The Internet is a globally-connected network of computers that enables people to share information and communicate with each other. An intranet, on the other hand, is a local or restricted network that enables people to store, organize, and share information within an organization.
 
after upgrading to this version on a AX68U, i started finding all my 5 Ghz clients disconnected. after a few hours. They were unable to reconnect.

didn't snag the log, but it seemed to imply my client had left the area.

tried a couple settings in the professional tab recommended for this problem, but no joy.
backed up the config, downgraded back to 386.3_2, restored the config. no issues on the older firmware.
 
After ~ 5 years my RT AC88's ET WAN Port died, nothing for it. I got an RT AX88U, updated to Merlin and restored settings. I had few neurotic tweaky things to do, of course, but very easily back in business. Made good use of the wifi radar site / traffic features; hadn't looked at my surroundings in while and things had changed.

Made a donation via paypal. Thanks Merlin
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top