Linksys E8450: Difference between revisions

From Leo's Notes
This page was last edited on 22 September 2022, at 20:20.
← Older editNewer edit →
VisualWikitext
No edit summary
Line 93: Line 93:
}}
}}


Updated from OpenWRT 22.03-SNAPSHOT to 22.03.0 but still can't read mtdblock2. No USB devices are mounted.
Updated from OpenWRT 22.03-SNAPSHOT to 22.03.0 but still can't read <code>mtdblock2</code>. No USB devices are mounted, in case that's relevant.


Looking through this very unwieldy discussion https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302, the developer (daniel) says "This error can show when trying to access areas in the flash with broken OOB/ECC data." and that mtdblock2 is the factory partition containing calibration data.
Looking through this very unwieldy discussion https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302, the developer (daniel) says "This error can show when trying to access areas in the flash with broken OOB/ECC data." and that mtdblock2 is the factory partition containing calibration data.


Restarting the 5GHz WiFi will trigger this error, despite me trying to make /dev/mtdblock2 chmod 000.
Restarting the 5GHz WiFi will trigger this error, despite me trying to make <code>/dev/mtdblock2</code> chmod <code>000</code>.


lsof shows the rpcd process having mtdblock2 open:
<code>lsof</code> shows the <code>rpcd</code> process having <code>/dev/mtdblock2</code> open:


{{Highlight
{{Highlight
Line 134: Line 134:
}}
}}


which is why it hangs. And since rpcd's used for handling other things like WiFi connections or luci, everything just stalls out.
This is likely what's causing things to hang since rpcd is used for handling other things like WiFi connections or luci.
 
Searching through the entire filesystem for <code>mtdblock2</code> returned nothing. The discussion mentioned that iwinfo might be reading <code>mtdblock2</code>. There is a string '<code>mtdblock%d</code>' in the <code>libiwinfo.so.20210430</code> library. The source for this does indeed show it try to read <code>/dev/mtdblockN</code> as seen here: https://git.openwrt.org/?p=project/iwinfo.git;a=blob_plain;f=iwinfo_utils.c;hb=3d38d1d17eba37b0985dd2857b4539410824a3e6 in order to determine the hardware information.
 
Perhaps a simple fix here would be to rename <code>/dev/mtdblock2</code> to <code>/dev/mtdblock2a</code> so it can't try reading from the device? Basically, <code>mv /dev/mtdblock2 /dev/mtdblock2a</code>


== See also ==
== See also ==


* https://openwrt.org/toh/linksys/e8450
* https://openwrt.org/toh/linksys/e8450

Revision as of 20:20, 22 September 2022

The Linksys E8450 is a Wi-Fi 6 (802.11ax) router. This router is based on MediaTek MT7622 SOC and a MT7531 switch. As of 2022, it is supported by a snapshot release of OpenWRT.

I purchased this switch on sale from Amazon for $109 CAD in mid 2022.

OpenWRT

Installing OpenWRT

If you are installing OpenWRT from the stock Linksys firmware, please refer to the instructions outlined at: https://github.com/dangowrt/owrt-ubi-installer

The steps that I used to install OpenWRT are as follows:

  1. Power on the device, navigate to http://192.168.1.1.
  2. Decline the terms and conditions and quit the setup wizard
  3. Login as 'admin' / 'admin'
  4. Go to Administration -> Firmware Upgrade
  5. Upload openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb (Not the installer)
  6. Once the device reboots, you should be able to see OpenWRT at 192.168.1.1
  7. SSH to OpenWRT and back up the flash.
# cd /dev
# for part in mtd[0123] ; do dd if=$part of=/tmp/$part; done

Copy the resulting mtd files to your computer in case you ever need it.

  1. Reboot the router. I had to power cycle the device a few times before it stopped going into OpenWRT.
  2. Back on the original Linksys firmware, upload the UBI based installer openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb.
  3. Once the device reboots, you should be able to see OpenWRT at 192.168.1.1
  4. Upgrade the OpenWRT firmware using the UBI sysupgrade file. Go to System -> Flash Firmware, under "Flash new firmware image", upload openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb.
  5. Once the device reboots, you should see OpenWRT again.

Upgrading OpenWRT

If you installed OpenWRT using the steps above (ie. OpenWRT with the UBI filesystem converted), you'll upgrade the system via OpenWRT using a UBI-enabled sysupgrade file. For example: openwrt-22.03-snapshot-r19451-2726c8c315-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb.

Note that you'll lose any installed packages once you do this upgrade. If you have any specific kernel modules or programs installed, you'll have to reinstall them again. The configs however should remain persistent.

Troubleshooting

Bad flash errors

The router recently started stalling. Luci doesn't respond and WiFi connections don't work.

Checking on the kernel dmesg logs show that some sectors are failing to write: 

[355545.032552] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x84700 phys_seg 32 prio class 0
[355545.045135] blk_update_request: I/O error, dev mtdblock2, sector 264 op 0x0:(READ) flags 0x84700 phys_seg 31 prio class 0
[355545.056711] blk_update_request: I/O error, dev mtdblock2, sector 272 op 0x0:(READ) flags 0x84700 phys_seg 30 prio class 0
[355545.068156] blk_update_request: I/O error, dev mtdblock2, sector 280 op 0x0:(READ) flags 0x84700 phys_seg 29 prio class 0
[355545.079640] blk_update_request: I/O error, dev mtdblock2, sector 288 op 0x0:(READ) flags 0x84700 phys_seg 28 prio class 0
[355545.091038] blk_update_request: I/O error, dev mtdblock2, sector 296 op 0x0:(READ) flags 0x84700 phys_seg 27 prio class 0
[355545.102418] blk_update_request: I/O error, dev mtdblock2, sector 304 op 0x0:(READ) flags 0x84700 phys_seg 26 prio class 0
[355545.113821] blk_update_request: I/O error, dev mtdblock2, sector 312 op 0x0:(READ) flags 0x84700 phys_seg 25 prio class 0
[355545.125211] blk_update_request: I/O error, dev mtdblock2, sector 320 op 0x0:(READ) flags 0x84700 phys_seg 24 prio class 0
[355545.136592] blk_update_request: I/O error, dev mtdblock2, sector 328 op 0x0:(READ) flags 0x84700 phys_seg 23 prio class 0
[355545.155734] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.164051] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.172324] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.180307] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.188286] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.196255] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.204253] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.213419] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.221699] Buffer I/O error on dev mtdblock2, logical block 32, async page read
[355545.231766] Buffer I/O error on dev mtdblock2, logical block 32, async page read

And the kernel logs just continue erroring with the Buffer I/O error message.

For some reason, /sbin/rpcd -s /var/run/ubus/ubus.sock -t 30 was using 25% CPU. Killing it brought back Luci?

/dev/mtdblock2 really can't be read: 

root@linksys:/# dd if=/dev/mtdblock2  of=/tmp/x conv=noerror
dd: /dev/mtdblock2: I/O error
dd: /dev/mtdblock2: I/O error
dd: /dev/mtdblock2: I/O error
dd: /dev/mtdblock2: I/O error
dd: /dev/mtdblock2: I/O error
...

root@linksys:/# dmesg
[149324.472780] print_req_error: 3434 callbacks suppressed
[149324.472788] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x84700 phys_seg 26 prio class 0
[149324.489773] blk_update_request: I/O error, dev mtdblock2, sector 264 op 0x0:(READ) flags 0x84700 phys_seg 25 prio class 0
[149324.501309] blk_update_request: I/O error, dev mtdblock2, sector 272 op 0x0:(READ) flags 0x84700 phys_seg 24 prio class 0
[149324.513110] blk_update_request: I/O error, dev mtdblock2, sector 280 op 0x0:(READ) flags 0x84700 phys_seg 23 prio class 0
[149324.524642] blk_update_request: I/O error, dev mtdblock2, sector 288 op 0x0:(READ) flags 0x84700 phys_seg 22 prio class 0
[149324.536136] blk_update_request: I/O error, dev mtdblock2, sector 296 op 0x0:(READ) flags 0x84700 phys_seg 21 prio class 0
[149324.547439] blk_update_request: I/O error, dev mtdblock2, sector 304 op 0x0:(READ) flags 0x84700 phys_seg 20 prio class 0
[149324.558870] blk_update_request: I/O error, dev mtdblock2, sector 312 op 0x0:(READ) flags 0x84700 phys_seg 19 prio class 0
[149324.570155] blk_update_request: I/O error, dev mtdblock2, sector 320 op 0x0:(READ) flags 0x84700 phys_seg 18 prio class 0
[149324.581596] blk_update_request: I/O error, dev mtdblock2, sector 328 op 0x0:(READ) flags 0x84700 phys_seg 17 prio class 0
[149324.604720] buffer_io_error: 3425 callbacks suppressed
[149324.604728] Buffer I/O error on dev mtdblock2, logical block 32, async page read

Updated from OpenWRT 22.03-SNAPSHOT to 22.03.0 but still can't read mtdblock2. No USB devices are mounted, in case that's relevant.

Looking through this very unwieldy discussion https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302, the developer (daniel) says "This error can show when trying to access areas in the flash with broken OOB/ECC data." and that mtdblock2 is the factory partition containing calibration data.

Restarting the 5GHz WiFi will trigger this error, despite me trying to make /dev/mtdblock2 chmod 000.

lsof shows the rpcd process having /dev/mtdblock2 open: 

root@linksys:~# lsof -p 3422
COMMAND  PID USER   FD      TYPE             DEVICE SIZE/OFF                NODE NAME
rpcd    3422 root  cwd       DIR               0,18      352                  67 /
rpcd    3422 root  rtd       DIR               0,18      352                  67 /
rpcd    3422 root  txt       REG               0,18    66139 9223372036854776300 /sbin/rpcd
rpcd    3422 root  mem       REG              259,1                          492 /sbin/rpcd (path dev=0,18, inode=9223372036854776300)
rpcd    3422 root  mem       BLK               31,8                           54 /dev/mtdblock2
rpcd    3422 root  mem       REG              259,1                         1122 /usr/lib/rpcd/rrdns.so (path dev=0,18, inode=9223372036854776930)
rpcd    3422 root  mem       REG              259,1                         1121 /usr/lib/rpcd/luci.so (path dev=0,18, inode=9223372036854776929)
rpcd    3422 root  mem       REG              259,1                          599 /usr/lib/libnl-tiny.so (path dev=0,18, inode=9223372036854776407)
rpcd    3422 root  mem       REG              259,1                          583 /usr/lib/libiwinfo.so.20210430 (path dev=0,18, inode=9223372036854776391)
rpcd    3422 root  mem       REG              259,1                         1120 /usr/lib/rpcd/iwinfo.so (path dev=0,18, inode=9223372036854776928)
rpcd    3422 root  mem       REG              259,1                         1119 /usr/lib/rpcd/file.so (path dev=0,18, inode=9223372036854776927)
rpcd    3422 root  mem       REG              259,1                          318 /lib/libgcc_s.so.1 (path dev=0,18, inode=9223372036854776126)
rpcd    3422 root  mem       REG              259,1                          588 /usr/lib/libjson-c.so.5.1.0 (path dev=0,18, inode=9223372036854776396)
rpcd    3422 root  mem       REG              259,1                          315 /lib/libblobmsg_json.so.20220515 (path dev=0,18, inode=9223372036854776123)
rpcd    3422 root  mem       REG              259,1                          325 /lib/libuci.so (path dev=0,18, inode=9223372036854776133)
rpcd    3422 root  mem       REG              259,1                          324 /lib/libubus.so.20220601 (path dev=0,18, inode=9223372036854776132)
rpcd    3422 root  mem       REG              259,1                          323 /lib/libubox.so.20220515 (path dev=0,18, inode=9223372036854776131)
rpcd    3422 root  mem       REG              259,1                          316 /lib/libc.so (path dev=0,18, inode=9223372036854776124)
rpcd    3422 root    0r      CHR                1,3      0t0                  26 /dev/null
rpcd    3422 root    1w      CHR                1,3      0t0                  26 /dev/null
rpcd    3422 root    2w      CHR                1,3      0t0                  26 /dev/null
rpcd    3422 root    3u  a_inode                0,8        0                  74 [eventpoll:4,6]
rpcd    3422 root    4r     FIFO                0,7      0t0               11701 pipe
rpcd    3422 root    5w     FIFO                0,7      0t0               11701 pipe
rpcd    3422 root    6u     unix 0x000000000aec3471      0t0               11702 type=STREAM
rpcd    3422 root    7u  netlink                         0t0               15712 GENERIC
rpcd    3422 root    8r      BLK               31,8      0t0                  54 /dev/mtdblock2

This is likely what's causing things to hang since rpcd is used for handling other things like WiFi connections or luci.

Searching through the entire filesystem for mtdblock2 returned nothing. The discussion mentioned that iwinfo might be reading mtdblock2. There is a string 'mtdblock%d' in the libiwinfo.so.20210430 library. The source for this does indeed show it try to read /dev/mtdblockN as seen here: https://git.openwrt.org/?p=project/iwinfo.git;a=blob_plain;f=iwinfo_utils.c;hb=3d38d1d17eba37b0985dd2857b4539410824a3e6 in order to determine the hardware information.

Perhaps a simple fix here would be to rename /dev/mtdblock2 to /dev/mtdblock2a so it can't try reading from the device? Basically, mv /dev/mtdblock2 /dev/mtdblock2a

See also