Unable to flash firmware due to bad blocks

[rcfw]

Something is deffinetly wrong with this, is this the entire log? The upgrade isn't even starting in that log.
You have constant logs indicating:



Which to my understanding (someone correct me if I'm wrong) these repeated mismatch errors indicate the driver is hitting low-level issues when tearing down (or reinitializing) the wireless interface.
Seems like something in the broadcom driver is overwriting the interface: https://github.com/RMerl/asuswrt-me...s/net/wireless/brcm80211/brcmfmac/core.c#L784

This would likely indicate why your SSIDs are changing after the attempt.
You also have a log indicating a timeout action in the shutdown process:



According to this: https://android.googlesource.com/ke...aa5/drivers/net/wireless/bcmdhd/wl_cfg80211.c
The broadcom driver would timeout after about 1.5 seconds and give the error your seeing. Considering the last interface it was trying to tear down was wl3.1 I would say a safe bet is the 2.4GHz is your issue.

Something is wrong with your wireless interface, run this command:

wl -i wl3.1 status

to report the status of the interface.
You can always try to manually take the interface offline before doing the upgrade via LAN:

wl -i wl3.1 down

Wouldn't be a solve to the issue as much as work around if it works.
What tool did you use to recover? The official ASUS recovery tool? Or tftpd64? TFTP has worked for me in the past when the ASUS tool has failed. (More info here: https://www.snbforums.com/threads/i...ition-mounting-in-read-only.89499/post-914083)

You can always check the health using @JGrana 's script to do a NAND check: https://www.snbforums.com/threads/a...available-for-select-models.81644/post-801367 but I would be seriously surprised if you have such bad luck to have bad blocks after only a few months of use.

Ran the tool and I have 3 bad blocks just my luck

 

[ExtremeFiretop]

Ran the tool and I have 3 bad blocks just my luck

Doesn't mean it's the end of the road. Taking the discussion with you in the DMs

 

[ExtremeFiretop]

Doesn't mean it's the end of the road. Taking the discussion with you in the DMs

Just wanted to circle back

@rcfw has managed to flash the firmware update with some guidance... However he does have bad blocks within data, JFFS2, and defaults.

nand_read_bbt: bad block at 0x000004000000
nand_read_bbt: bad block at 0x000008020000

The device is doing a bunch of recoveries it shouldn't be while flashing. For example:

Jan 1 00:00:45 kernel: devtmpfs: mounted
Jan 1 00:00:45 kernel: Freeing unused kernel memory: 1280K
Jan 1 00:00:45 kernel: Checked W+X mappings: passed, no W+X pages found
Jan 1 00:00:45 kernel: Run /sbin/init as init process
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): background thread "ubifs_bgt0_10" started, PID 130
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): recovery needed
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): recovery completed
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): UBIFS: mounted UBI device 0, volume 10, name "data"
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): FS size: 19808256 bytes (18 MiB, 156 LEBs), journal size 1015809 bytes (0 MiB, 8 LEBs)
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): reserved for root: 935592 bytes (913 KiB)
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): media format: w5/r0 (latest is w5/r0), UUID 24F7B5EA-8D8F-4339-9026-BAD8B6302FD6, small LPT model
Jan 1 00:00:45 kernel: Initializing WLCSM Module
Jan 1 00:00:45 kernel: WLCSM Module loaded successfully
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): background thread "ubifs_bgt0_11" started, PID 241
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): recovery needed
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): recovery completed
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): UBIFS: mounted UBI device 0, volume 11, name "defaults"
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): FS size: 7237632 bytes (6 MiB, 57 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): reserved for root: 341850 bytes (333 KiB)
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): media format: w5/r0 (latest is w5/r0), UUID 707155B4-38FF-41B9-89B2-8B88CDD2FEEE, small LPT model
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): background thread "ubifs_bgt0_13" started, PID 272
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): recovery needed
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): recovery completed
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): UBIFS: mounted UBI device 0, volume 13, name "jffs2"
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): FS size: 51171328 bytes (48 MiB, 403 LEBs), journal size 2539520 bytes (2 MiB, 20 LEBs)
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): reserved for root: 2416947 bytes (2360 KiB)
Jan 1 00:00:45 kernel: UBIFS (ubi0:13)

Might be worth checking into a warranty replacement before you run out of time if this happens to you. Bad luck from the manufacturer in this case I think and nothing more though.

He is on the latest firmware, but I wouldn't call the issue solved, more worked around lol.

 

[visortgw]

Just wanted to circle back

@rcfw has managed to flash the firmware update with some guidance... However he does have bad blocks within data, JFFS2, and defaults.



The device is doing a bunch of recoveries it shouldn't be while flashing. For example:



Might be worth checking into a warranty replacement before you run out of time if this happens to you. Bad luck from the manufacturer in this case I think and nothing more though.

He is on the latest firmware, but I wouldn't call the issue solved, more worked around lol.

When is his replacement coming?

 

[ExtremeFiretop]

When is his replacement coming?

Good question LOL. I basically said the same thing. Even if the firmware is flashed it's probably worth replacing. Considering it's only a few months old, I don't think he should have a problem with the warranty process.

 

[visortgw]

Good question LOL. I basically said the same thing. Even if the firmware is flashed it's probably worth replacing. Considering it's only a few months old, I don't think he should have a problem with the warranty process.

And he deserves one sent as advanced replacement given the cost of the device!

 

[rcfw]

Good question LOL. I basically said the same thing. Even if the firmware is flashed it's probably worth replacing. Considering it's only a few months old, I don't think he should have a problem with the warranty process.

And he deserves one sent as advanced replacement given the cost of the device!

Don’t think ASUS will accept the warranty as the device is from the us and I’m in the uk they basically said to go to newegg and that the warranty is only covered under local warranty

 

[rcfw]

Big thanks to ExtremeFiretop for helping me and showing me a very dangerous but effective method on how to flash it

 

[visortgw]

Big thanks to ExtremeFiretop for helping me and showing me a very dangerous but effective method on how to flash it

It wasn't working before flashing, so sometimes you need to live on the edge for a potential fix!

 

[rcfw]

Update the router randomly stopped booting so I downgraded again and unplugged and bought a new openwrt linskys WiFi 7 router and it’s excellent no problems

 

[visortgw]

Don’t think ASUS will accept the warranty as the device is from the us and I’m in the uk they basically said to go to newegg and that the warranty is only covered under local warranty

If Newegg shipped it to UK address, they may be on the the hook to replace it for you.

 

[JGrana]

Ran the tool and I have 3 bad blocks just my luck

As @ExtremeFiretop mentioned, not the end of the road.

Most routers will have a few bad blocks. It’s the nature of flash memory devices. The mtd driver manages attempts at correcting (and re-mapping) a bad block. There a numerous free blocks for mtd to remap to.

Running mtd_check -b (just get the # of bad blocks) every few days will likely more tell if there is a growing issue.
If the bad blocks count stays the same over time - everything is fine.
If, on the other hand, the bad blocks count increases, you have a growing problem.
Backup quickly and be prepared ;-)

Quick note - this only applies to JFFS2/mtd file systems. The new UBIFS used on recent routers handles bad blocks management another way. You can use the tool /usr/sbin/ubinfo to get information.

 

[rcfw]

If Newegg shipped it to UK address, they may be on the the hook to replace it for you.

That’s next on my list to contact newegg and hopefully get a replacement

 

[ExtremeFiretop]

As @ExtremeFiretop mentioned, not the end of the road.

Quick note - this only applies to JFFS2/mtd file systems. The new UBIFS used on recent routers handles bad blocks management another way. You can use the tool /usr/sbin/ubinfo to get information.

I'll file this info away as a useful tool for UBIFS systems.
Based on his system logs when flashing, it looks to me like the bad blocks are likely apart of defaults, data, and JFFS2 and causing a recovery while flashing

I don't believe this should be happening, or at least, it doesn't for me when I test flashing:

Jan 1 00:00:45 kernel: UBIFS (ubi0:10): background thread "ubifs_bgt0_10" started, PID 130
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): recovery needed
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): recovery completed
Jan 1 00:00:45 kernel: UBIFS (ubi0:10): UBIFS: mounted UBI device 0, volume 10, name "data"

Things like this shouldn't be happening ( at least they aren't for me):
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): background thread "ubifs_bgt0_11" started, PID 241
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): recovery needed
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): recovery completed
Jan 1 00:00:45 kernel: UBIFS (ubi0:11): UBIFS: mounted UBI device 0, volume 11, name "defaults"

Jan 1 00:00:45 kernel: UBIFS (ubi0:13): background thread "ubifs_bgt0_13" started, PID 272
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): recovery needed
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): recovery completed
Jan 1 00:00:45 kernel: UBIFS (ubi0:13): UBIFS: mounted UBI device 0, volume 13, name "jffs2"

 

[bibikalka]

...
Running mtd_check -b (just get the # of bad blocks) every few days will likely more tell if there is a growing issue.
If the bad blocks count stays the same over time - everything is fine.
If, on the other hand, the bad blocks count increases, you have a growing problem.

...

Yeah, I have AC86U with a known bad block that stays there. So no issues:

Jan 21 04:05:05 kernel: nand_read_bbt: bad block at 0x000000280000

I also have AC68U which had nvram forget everything from time to time. So I just hammered that section with many writes, forcing those blocks out of service for good:

AC68u fast blinking power light from time to time (nvram issue)

I have this flaky AC68u which from time to time totally forgets its NVRAM. Usually power light is blinking rapidly. I can usually restore the router after multiple attempts of pressing WPS button upon turning on. It'll come back up fully factory reset. But it'll forget again soon. I am using...

www.snbforums.com

I think this command hit those failing blocks many times, 256k times if I count correctly given each time it wrote a 512 byte block it re-wrote the whole mtd1:

dd if=/dev/urandom of=/dev/mtd1 bs=512

I guess I killed these blocks for good if I understand this correctly:
Single-level cell (SLC) flash, designed for higher performance and longer endurance, can typically operate between 50,000 and 100,000 cycles.