Release Asuswrt-Merlin 386.7 is now available for all models

[SomeWhereOverTheRainBow]

@RMerlin : I thought JFFS partition size was the same among all models.
Do some have larger max sizes?
Why was it max size 48 before the final release and now it's 47?

View attachment 42209

Mine is 63.

 

[John Fitzgerald]

Mine is 63.

Thanks,
On which model?

Do we have a chart for this on the supported models. I don't recall it being more than 48 on my 3 but I don't have access right now.

Or if it's a shorter list, which ones are 63, assuming no other sizes are in play.

 

[SomeWhereOverTheRainBow]

Thanks,
On which model?

Do we have a chart for this on the supported models. I don't recall it being more than 48 on my 3 but I don't have access right now.

Or if it's a shorter list, which ones are 63, assuming no other sizes are in play.

Rt ax 88u

 

[Treadler]

Thanks,
On which model?

Do we have a chart for this on the supported models. I don't recall it being more than 48 on my 3 but I don't have access right now.

Or if it's a shorter list, which ones are 63, assuming no other sizes are in play.

63 here.

 

[Treadler]

387 runs very well on the AC5300 but apparently you encounter an issue Before concluding that you have a hardware problem look at the list of configuration steps that L&LD has lined up https://www.snbforums.com/members/l-ld.24423/#about Take the time and always choose a channel for wifi (NOT auto).

FWIW, I use Auto, but I don’t have many clients, & I’m not in a highly populated area.
The 2.4 changes occasionally, the 5 ghz always settles on 149.
Just works….

 

[RMerlin]

@RMerlin : I thought JFFS partition size was the same among all models.

The size will vary between platforms and SDKs.

Why was it max size 48 before the final release and now it's 47?

The RT-AX86U has been 47 MB for a long time, possibly since day one. 1 MB is reserved for crashlog dumping.

 

[AlFreid]

RT-AX3000 - clean upgrade to 386.7 - restarts every few hours. Tried flashing to the latest Asus stock firmware - unsuccessful every time ( Version 3.0.0.4.386.48908 - 2022/05/24 ). Downgraded to Merlin 386.5_2 OK . Tried flashing Asus stock again - both RT-AX3000 and rt-AX58U - unsuccessful. Please help?

 

[jata]

RT-AX3000 - clean upgrade to 386.7 - restarts every few hours. Tried flashing to the latest Asus stock firmware - unsuccessful every time ( Version 3.0.0.4.386.48908 - 2022/05/24 ). Downgraded to Merlin 386.5_2 OK . Tried flashing Asus stock again - both RT-AX3000 and rt-AX58U - unsuccessful. Please help?

I think you need to use the ASUS firmware restoration tool to switch back to stock from Merlin 386.5 and 386.7 (on some models including ax3000 and ax58u)

 

[Ayitaka]

RT-AX86U from 386.7_beta to 386.7.

JFFS lost again.

My apologies, during the beta you asked for a log when jffs was suddenly not mounting, but I did not have one. This time, I do. I posted everything up to the last jffs message I found. If you need more please let me know.

Also sorry, I tried to add it as a spoiler but for some reason it kept telling me a problem occurred so I attached it as a txt file (Edit: which, apparently, is not showing after I attach it for some reason??).

Edit: Per Merlin's note, again, format and restore resolved the issue. All running fine now so far.

 

[Sumsurfguy]

RT-AX3000 - clean upgrade to 386.7 - restarts every few hours. Tried flashing to the latest Asus stock firmware - unsuccessful every time ( Version 3.0.0.4.386.48908 - 2022/05/24 ). Downgraded to Merlin 386.5_2 OK . Tried flashing Asus stock again - both RT-AX3000 and rt-AX58U - unsuccessful. Please help?

Try flashing the Asus stock firmware from 10/7/2021 first, Version 3.0.0.4.386.45898, Asus made some firmware changes and that version needs to be installed before any later Asus stock version can be installed (if it doesn't work you'll probably need the restoration tool as Jata sugested).

 

[AlFreid]

Try flashing the Asus stock firmware from 10/7/2021 first, Version 3.0.0.4.386.45898, Asus made some firmware changes and that version needs to be installed before any later Asus stock version can be installed (if it doesn't work you'll probably need the restoration tool as Jata sugested).

Good call, that worked like a charm without having to use the tool, thank you! Will wait to see if anyone else runs into constant reboot issue with 386.7 on AX58U/AX3000

 

[jata]

Try flashing the Asus stock firmware from 10/7/2021 first, Version 3.0.0.4.386.45898, Asus made some firmware changes and that version needs to be installed before any later Asus stock version can be installed (if it doesn't work you'll probably need the restoration tool as Jata sugested).

Thanks for this info. Much easier than restoration tool method that I have been using LOL.

 

[John Fitzgerald]

The size will vary between platforms and SDKs.


The RT-AX86U has been 47 MB for a long time, possibly since day one. 1 MB is reserved for crashlog dumping.

Today is the first time I've ever seen 47. The screenshots I posted in the Alpha thread showed 48 and the JFFS issue I reported showed the used portion about double what it was above. I've never seen the fluctuation before and it was 48 after the flash to final release and the initial wipe and restore. Afterwards I did another second JFFS wipe and restore, just for good measure a day later and it was running at 48. It also remained at 48 during both Beta's. I've been making new restore points all along and I've used the most recent point each time, rolling it forward. About 10 restore points.

Is the crash log cleared on its own? Time limit clear? How does it fluctuate and clear itself, if you don't mind explaining. Thanks.

 

[SomeWhereOverTheRainBow]

Today is the first time I've ever seen 47. The screenshots I posted in the Alpha thread showed 48 and the JFFS issue I reported showed the used portion about double what it was above. I've never seen the fluctuation before and it was 48 after the flash to final release and the initial wipe and restore. Afterwards I did another second JFFS wipe and restore, just for good measure a day later and it was running at 48. It also remained at 48 during both Beta's. I've been making new restore points all along and I've used the most recent point each time, rolling it forward. About 10 restore points.

Is the crash log cleared on its own? Time limit clear? How does it fluctuate and clear itself, if you don't mind explaining. Thanks.

Here was his best answer:

The size will vary between platforms and SDKs.

If the SDK just changed or was modified recently for your model, then so might have the size of your jffs.

drum roll.............

Here is where the SDK's changed:

build: build 5.02p1axhnd.675x models from the new 5.02L.07p2axhnd SDK… · RMerl/asuswrt-merlin.ng@6f82a1e

… directory

github.com

 

[isr25]

Are you using yazfi dhcp script as well?

No I am not using it, and never installed it. I didn't have time to do a clean wipe of my router to see if it helps to remove the crash.

I'm also have this on my log Asus AX86U. Is there anything I should be worried about?

Not that I can see - I have not pinned it down yet as to what is the likely culprit, other than it is caused by my work computer connecting to the network. It's not causing any adverse effect on my network - it's safe to ignore it for now.

 

[Serkan K.]

Removed USB dirty updated from 386.5_2, waited, rebooted.
All seemed working flawlessly until I realized 2.4Ghz devices were not connected to AC86U.
None of my devices can see Wifi 2.4Ghz.

I will do full reset and start over if I can't find a solution.

After a minimal and manual configuration (thank you L&LD) wifi 2.4Ghz is visible and usable to all clients again.

 

[Treadler]

Rt-AX88U owners do you see these continous logs after three days? I have no Aimesh setup just one addon(diversion lite) and guest clients.

Jun 26 10:30:54 kernel: CONSOLE: 171145.317 wlc_ap_authresp: status 0
Jun 26 10:30:54 kernel: CONSOLE: 171145.322 wlc_ap_process_assocreq_done status 0
Jun 26 10:30:54 kernel: CONSOLE: 171145.325 iov:SCB_DEAUTH
Jun 26 10:30:54 kernel: CONSOLE: 171145.327 tx:prep:802.1x
Jun 26 10:30:54 kernel: CONSOLE: 171145.334 wl0.2: wlc_send_bar: for d4:a6:51:xx:xx:xx seq 0x1 tid 5
Jun 26 10:30:54 kernel: CONSOLE: 171145.337 tx:prep:802.1x
Jun 26 10:30:54 kernel: CONSOLE: 171145.339 iov:SCB_AUTH
Jun 26 10:30:54 kernel: CONSOLE: 171145.365 wl0.2: wlc_send_bar: for d4:a6:51:xx:xx:xx seq 0x1 tid 6
Jun 26 10:30:55 kernel: CONSOLE: 171146.095 wl0.2: wlc_send_bar: for 84:e3:42:xx:xx:xx seq 0x16 tid 0
Jun 26 10:30:57 kernel: CONSOLE: 171147.547 wl0.2: wlc_send_bar: for d4:a6:51:xx:xx:xx seq 0x1 tid 0
Jun 26 10:30:57 kernel: CONSOLE: 171147.667 wl0.0: wlc_send_bar: for f0:72:ea:xx:xx:xx seq 0xc3 tid 3
Jun 26 10:30:57 kernel: CONSOLE: 171148.085 wl0: wlc_ampdu_recv_addba_resp: 54:60:09:xx:xx:xx: Failed. status 37 wsize 64 policy 1
Jun 26 10:30:59 kernel: CONSOLE: 171150.288 wl0.2: wlc_send_bar: for 84:e3:42:xx:xx:xx seq 0x18 tid 0
Jun 26 10:31:00 kernel: CONSOLE: 171151.071 wl0: dc:91:bf:xx:xx:xx: addba timed out 0
Jun 26 10:31:00 kernel: CONSOLE: 171151.358 wl0.2: wlc_send_bar: for dc:91:bf:xx:xx:xx seq 0x173 tid 0
Jun 26 10:31:01 kernel: CONSOLE: 171151.485 wl0.0: wlc_send_bar: for 54:60:09:xx:xx:xx seq 0x1 tid 3
Jun 26 10:31:14 kernel: CONSOLE: 171164.856 wl0.2: wlc_send_bar: for dc:91:bf:xx:xx:xx seq 0x17c tid 0
Jun 26 10:31:18 kernel: CONSOLE: 171169.113 wl0.2: wlc_send_bar: for dc:91:bf:xx:xx:xx seq 0xa tid 3
Jun 26 10:31:19 kernel: CONSOLE: 171170.196 wl0.2: wlc_send_bar: for 84:e3:42:xx:xx:xx seq 0x19 tid 0
Jun 26 10:31:21 kernel: CONSOLE: 171172.212 wl0.2: wlc_send_bar: for dc:91:bf:xx:xx:xx seq 0x18c tid 0
Jun 26 10:31:25 kernel: CONSOLE: 171175.491 wl0.0: wlc_ampdu_resp_timeout: 54:e0:19:xx:xx:xx: tid 0 cleaning up resp tid waiting for seq 0x50 for 200 ms
Jun 26 10:31:28 kernel: CONSOLE: 171178.374 wl0.2: wlc_send_bar: for dc:91:bf:xx:xx:xx seq 0x19c tid 0
Jun 26 10:31:30 kernel: CONSOLE: 171180.985 wl0: wlc_ampdu_recv_addba_resp: d4:a6:51:xx:xx:xx: Failed. status 37 wsize 16 policy 1
Jun 26 10:31:30 kernel: CONSOLE: 171180.985 wl0: wlc_ampdu_recv_addba_resp: d4:a6:51:xx:xx:xx: Failed. status 37 wsize 16 policy 1
Jun 26 10:31:30 kernel: CONSOLE: 171180.986 wl0: wlc_ampdu_recv_addba_resp: d4:a6:51:xx:xx:xx: Failed. status 37 wsize 16 policy 1

@RMerlin
These are the logs I was referring to from the already closed thread. Waited for awhile to post it until it comes out. New debug log from this GPL?

Yes, me too.

 

[RMerlin]

The screenshots I posted in the Alpha thread showed 48 and the JFFS issue I reported showed the used portion about double what it was above.

And as it was discussed later on, the new SDK was missing that 1 MB partition, which is what was causing all these corrupted JFFS partitions, which was resolved with beta 2 when the missing partition was re-added, reverting to the same 47 MB partition size as 386.5_2.

The 48 MB size was the incorrect size, and was only there for the alpha builds and beta 1. Both 386.5_2 and 386.7 final are 47 MB, as intended.

Is the crash log cleared on its own? Time limit clear?

It's a partition. There is nothing to clear. Data is written directly to the partition.

 

[dave14305]

dnsmasq will eventually restart itself if it was crashed.

I'll think about reverting the latest security fix in a future release, however the fact that no one else seems to experience the same issue is suspicious.

I just had this error twice in the last 2 hours, almost exactly one hour apart. Nothing else around it in the logs. Diversion active, but logging was disabled. Enabled now so I’ll see if any dns requests are logged prior to the next one.

Jun 26 20:23:28 kernel: net_ratelimit: 2 callbacks suppressed
Jun 26 20:23:28 kernel: <unknown>: hw csum failure
Jun 26 20:23:28 kernel: CPU: 0 PID: 32753 Comm: dnsmasq Tainted: P           O    4.1.27 #2
Jun 26 20:23:28 kernel: Hardware name: Broadcom-v8A (DT)
Jun 26 20:23:28 kernel: Call trace:
Jun 26 20:23:28 kernel: [<ffffffc0000876d8>] dump_backtrace+0x0/0x150
Jun 26 20:23:28 kernel: [<ffffffc00008783c>] show_stack+0x14/0x20
Jun 26 20:23:28 kernel: [<ffffffc000508b00>] dump_stack+0x90/0xb0
Jun 26 20:23:28 kernel: [<ffffffc0003be90c>] netdev_rx_csum_fault+0x3c/0x50
Jun 26 20:23:28 kernel: [<ffffffc0003b4078>] skb_copy_and_csum_datagram_msg+0xe8/0xf8
Jun 26 20:23:28 kernel: [<ffffffc0004b77c0>] udpv6_recvmsg+0x2a8/0x8b0
Jun 26 20:23:28 kernel: [<ffffffc000465464>] inet_recvmsg+0xa4/0xc8
Jun 26 20:23:28 kernel: [<ffffffc0003a137c>] sock_recvmsg+0x14/0x20
Jun 26 20:23:28 kernel: [<ffffffc0003a2f9c>] ___sys_recvmsg+0xac/0x1a8
Jun 26 20:23:28 kernel: [<ffffffc0003a59d8>] __sys_recvmsg+0x40/0x80
Jun 26 20:23:28 kernel: [<ffffffc0003e19e8>] compat_SyS_recvmsg+0x10/0x18

Jun 26 21:23:41 kernel: <unknown>: hw csum failure
Jun 26 21:23:41 kernel: CPU: 0 PID: 32753 Comm: dnsmasq Tainted: P           O    4.1.27 #2
Jun 26 21:23:41 kernel: Hardware name: Broadcom-v8A (DT)
Jun 26 21:23:41 kernel: Call trace:
Jun 26 21:23:41 kernel: [<ffffffc0000876d8>] dump_backtrace+0x0/0x150
Jun 26 21:23:41 kernel: [<ffffffc00008783c>] show_stack+0x14/0x20
Jun 26 21:23:41 kernel: [<ffffffc000508b00>] dump_stack+0x90/0xb0
Jun 26 21:23:41 kernel: [<ffffffc0003be90c>] netdev_rx_csum_fault+0x3c/0x50
Jun 26 21:23:41 kernel: [<ffffffc0003b4078>] skb_copy_and_csum_datagram_msg+0xe8/0xf8
Jun 26 21:23:41 kernel: [<ffffffc0004b77c0>] udpv6_recvmsg+0x2a8/0x8b0
Jun 26 21:23:41 kernel: [<ffffffc000465464>] inet_recvmsg+0xa4/0xc8
Jun 26 21:23:41 kernel: [<ffffffc0003a137c>] sock_recvmsg+0x14/0x20
Jun 26 21:23:41 kernel: [<ffffffc0003a2f9c>] ___sys_recvmsg+0xac/0x1a8
Jun 26 21:23:41 kernel: [<ffffffc0003a59d8>] __sys_recvmsg+0x40/0x80
Jun 26 21:23:41 kernel: [<ffffffc0003e19e8>] compat_SyS_recvmsg+0x10/0x18

 

[bluepoint]

After many hours of no log spamming, I too am being smashed with many ‘Console’ entries.
Operationally, everything seems fine though, wifi/everything good.
If I didn’t look at the log, I wouldn’t be aware of any issue.

Yes, me too.

And if you try this command, it'll show you the whole log.

cat /tmp/syslog.log | grep CONSOLE