SomeWhereOverTheRainBow
Part of the Furniture
Ahhh, seems you have unknowingly upgraded to a dual band model. Those nightly builds can be game changers.I have one dual-band AC5300! One of the 5GHz radios is broken...
Release Asuswrt-Merlin 386.4 is now available
- Thread starter RMerlin
- Start date
- Status
A lot of these vulnerability fixes are already included in 386.4. Same with the DDNS fixes.
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.
maxbraketorque
Very Senior Member
Hopefully something yummy.
Centrifuge
Senior Member
Probably Pizza is my guess.
torstein
Senior Member
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
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:
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.
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.
Ham and cheese sandwich from a local bakery. They're awesome.
dave14305
Part of the Furniture
Now I’m hungry for a croque monsieur.
shabbs
Very Senior Member
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.
CaptnDanLKW
Senior Member
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.
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/0x28ColinTaylor
Part of the Furniture
Yep, corrupted USB filesystem.
torstein
Senior Member
will a factory reset fix that?
ColinTaylor
Part of the Furniture
No. It needs to be repaired using
fsck.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.
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
Made a donation via paypal. Thanks Merlin
- Status
Similar threads
Similar threads
Similar threads
-
Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14
- Started by B0GDAN
- Replies: 1
-
Release Asuswrt-Merlin 386.14 is now available for AC models
- Started by RMerlin
- Replies: 222
-
-
Release Asuswrt-Merlin 386.13 / 386.13_2 is now available for AC models
- Started by RMerlin
- Replies: 79
-
Beta Asuswrt-Merlin 386.13 beta is now available for AC models
- Started by RMerlin
- Replies: 32
-
Release Asuswrt-Merlin 386.12_6 is now available for AC models
- Started by RMerlin
- Replies: 168
-
Please add Asuswrt-merlin to GT-BE98 (Non-pro) version
- Started by kaotic2499
- Replies: 22
-
-
Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices
- Started by RMerlin
- Replies: 75
-
Several Questions Re:Asuswrt-Merlin Feature Implementation
- Started by fenixreign
- Replies: 2
Latest threads
-
-
Finally upgraded to AX86u Pro- Started by DarkKnight75
- Replies: 1
-
-
-
Diversion Diversion failed to update. Check the Diversion-web-update.log with sf in the SSH UI.
- Started by mikefrommanchester
- Replies: 4
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!