Flashing OpenWrt on Linksys MR8300 - partially bricked

I presume this is 19.07.4, however Released factory.bin size is 7.6MB and yours is 18.6MB.

What's up with the additional 11MB ?

Furthermore, I thought MR and EA were essentially identical except for RAM, what's different with respect to radios ?

Also, Advanced Reboot does not power EAs, it reboots both of mine, any way to fix ?

And, should be receiving MR9000 tomorrow, looking forward to cross flash to EA 19.07.4 and see what works.

Mine is built against Master, not 19.07.4. However Master has all the fixes/changes in 19.07.04 (and some).

For the size, I tried to explain that earlier, but it's very easy. Snapshots are only the core defaults for a unit, no additional packages. My build includes everything I use (already built in). Like wireguard, OpenVPN, VPR, Luci SSL, a couple themes, adblock, banip, mwan, statistics, upnp, advanced reboot, sqm, nextdns, USB is enabled, dnsmasq full, unbound, wpad-mesh-wolfssl, iperf, irqbalance, ddns etc.. etc.. etc.. hence the size difference. All the changes are listed in the .config file in my link.

As close as the units are, the EA8300 and MR8300 are not "just" 256 vs 512 MB, contrary to what was originally thought. The main differences so far are:

  1. LED's are different, EA8300 crossflash led on top does not work on MR8300. MR8300 has an RGB-ish led so has to be handled differently in the DTS file.
  2. Or course 256 vs 512
  3. The wireless radio calibration data is different between the EA8300 and MR8300. So while wireless may enable on the cross-flash, no guarantee you are not getting soft failures in the background.

Regardless, it's here to try if you want to. You are free to stick with the EA8300 build. I am just offering these as I progress through the PR to get MR8300 officially supported. Once this is complete, I will quiet back down again as you would have MR8300 buildbot builds at that time :slight_smile:

Thanks for getting MR8300 officially supported !

Not there yet, but close!

HI - I have been battling with my MR8300 for almost 24Hrs. I managed to flash both the standard EA8400 and the firmware you provided(thanks), however, it takes the router close to an hour or so to get on line. From initial install, what I observe is that my WAN goes up, assigned an IP address. I then configure the DHCP DNS, and my APs, all clients can associate and get IP adresses, however, I have no internet connectivity. I have looked in the logs I see no errors and I see the requests being forwarded but nothing back.. After a while the internet will start working.. If I reboot I get the same connection issues. I have rebooted a number of times and re-installed the software a number of times and It still takes a ridiculously long time to get on line. The load on the system looks normal and I see no errors in the system log.

I have tried with a backup router I have, a GLi-net MV1000, and it behaves as expected, connect to fibre box and I have no connection issues, sot I believe I have ruled out the telco

I am running the FW you provided in the link above (the one in the onedrive)

Even more frustrating is once it is up an running, and I reboot, I have the same connectivity issues, it takes a long to come on line, and sometimes, it doesn't at all, only remedy is to reflash the firmware

Only things I see in the kernel log are :

* workqueue: max_active 576 requested for napi_workq is out of range, clamping between 1 and 512[    0.039949] clocksource: Switched to clocksource arch_sys_counter

* ath10k_pci 0000:01:00.0: unsupported HTC service id: 1536
 793.137412] ------------[ cut here ]------------
[  793.143302] WARNING: CPU: 0 PID: 1721 at target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/ath10k-ct-regular/ath10k-ct-2020-06-30-edfbf916/ath10k-5.4/htt_rx.c:1082 ath10k_htt_rx_pktlog_completion_handler+0x40c/0x241c [ath10k_core]
[  793.147740] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat ath10k_pci ath10k_core ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nft_redir nft_ct nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY wireguard ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda slhc sch_cake nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject_bridge nft_reject nft_quota nft_objref nft_numgen nft_meta_bridge nft_log nft_limit nft_hash nft_fwd_netdev nft_dup_netdev nft_counter nf_tables_set nf_tables nf_reject_ipv4 nf_log_ipv4 nf_dup_netdev nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw
[  793.147979]  iptable_mangle iptable_filter ipt_ECN ip_tables hwmon crc_ccitt compat sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred ledtrig_usbport ledtrig_heartbeat xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb ip6_udp_tunnel udp_tunnel vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp437 usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 crc32c_generic
[  793.314191] CPU: 0 PID: 1721 Comm: hostapd Not tainted 5.4.63 #0
[  793.336344] Hardware name: Generic DT based system
[  793.342531] [<c030e524>] (unwind_backtrace) from [<c030afa4>] (show_stack+0x10/0x14)
[  793.347125] [<c030afa4>] (show_stack) from [<c0848758>] (dump_stack+0x94/0xa8)
[  793.355021] [<c0848758>] (dump_stack) from [<c0321340>] (__warn+0xbc/0xd8)
[  793.362048] [<c0321340>] (__warn) from [<c03213ac>] (warn_slowpath_fmt+0x50/0x94)
[  793.369001] [<c03213ac>] (warn_slowpath_fmt) from [<bf6a2638>] (ath10k_htt_rx_pktlog_completion_handler+0x40c/0x241c [ath10k_core])
[  793.376676] [<bf6a2638>] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core]) from [<bf6a27d8>] (ath10k_htt_rx_pktlog_completion_handler+0x5ac/0x241c [ath10k_core])
[  793.388218] [<bf6a27d8>] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core]) from [<bf6a6aa4>] (ath10k_htt_rx_proc_rx_frag_ind_hl+0xb8c/0x1020 [ath10k_core])
[  793.403142] [<bf6a6aa4>] (ath10k_htt_rx_proc_rx_frag_ind_hl [ath10k_core]) from [<bf6a7718>] (ath10k_htt_txrx_compl_task+0x7e0/0x10e0 [ath10k_core])
[  793.417685] [<bf6a7718>] (ath10k_htt_txrx_compl_task [ath10k_core]) from [<bf6fecf8>] (ath10k_pci_napi_poll+0x50/0x13c [ath10k_pci])
[  793.431042] [<bf6fecf8>] (ath10k_pci_napi_poll [ath10k_pci]) from [<c0727ab4>] (__napi_poll+0x28/0x104)
[  793.442872] [<c0727ab4>] (__napi_poll) from [<c0727d1c>] (net_rx_action+0xf8/0x284)
[  793.451984] [<c0727d1c>] (net_rx_action) from [<c0302288>] (__do_softirq+0x120/0x2b0)
[  793.459624] [<c0302288>] (__do_softirq) from [<c032534c>] (irq_exit+0xb0/0xd4)
[  793.467610] [<c032534c>] (irq_exit) from [<c036b840>] (__handle_domain_irq+0x60/0xb4)
[  793.474730] [<c036b840>] (__handle_domain_irq) from [<c05a92fc>] (gic_handle_irq+0x4c/0x90)
[  793.482627] [<c05a92fc>] (gic_handle_irq) from [<c0301a8c>] (__irq_svc+0x6c/0x90)
[  793.490776] Exception stack(0xdddefcd8 to 0xdddefd20)
[  793.498413] fcc0:                                                       dde51b34 00000000
[  793.503458] fce0: 00000000 ddc2c200 de56a000 dde50c20 de56a4c0 dde50c20 dde51dd0 dddee000
[  793.511618] fd00: dde51b34 00000000 00000000 dddefd28 bf5580d8 c0861aa0 60000013 ffffffff
[  793.519781] [<c0301a8c>] (__irq_svc) from [<c0861aa0>] (mutex_lock+0x1c/0x3c)
[  793.528106] [<c0861aa0>] (mutex_lock) from [<bf5580d8>] (ieee80211_roc_purge+0x24/0xf4 [mac80211])
[  793.535344] [<bf5580d8>] (ieee80211_roc_purge [mac80211]) from [<bf5604a4>] (ieee80211_add_virtual_monitor+0x2a0/0xa7c [mac80211])
[  793.544110] [<bf5604a4>] (ieee80211_add_virtual_monitor [mac80211]) from [<bf560c90>] (ieee80211_stop+0x10/0x18 [mac80211])
[  793.555736] [<bf560c90>] (ieee80211_stop [mac80211]) from [<c071e1a0>] (__dev_close_many+0x90/0xf4)
[  793.566658] [<c071e1a0>] (__dev_close_many) from [<c0728af4>] (__dev_change_flags+0xa4/0x1a4)
[  793.575684] [<c0728af4>] (__dev_change_flags) from [<c0728c0c>] (dev_change_flags+0x18/0x48)
[  793.584362] [<c0728c0c>] (dev_change_flags) from [<c07b84bc>] (devinet_ioctl+0x6d8/0x708)
[  793.592869] [<c07b84bc>] (devinet_ioctl) from [<c07bb828>] (inet_ioctl+0x1f0/0x380)
[  793.600944] [<c07bb828>] (inet_ioctl) from [<c070437c>] (sock_ioctl+0x334/0x58c)
[  793.608408] [<c070437c>] (sock_ioctl) from [<c04560cc>] (do_vfs_ioctl+0x9c/0x8cc)
[  793.616044] [<c04560cc>] (do_vfs_ioctl) from [<c0456930>] (ksys_ioctl+0x34/0x60)
[  793.623421] [<c0456930>] (ksys_ioctl) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
[  793.630876] Exception stack(0xdddeffa8 to 0xdddefff0)
[  793.638262] ffa0:                   00000000 bebd7b08 0000000c 00008914 bebd7b08 bebd7af8
[  793.643474] ffc0: 00000000 bebd7b08 b6d91ef8 00000036 0000000c bebd7dac 008af058 008af020
[  793.651629] ffe0: 00569e60 bebd7ae0 004df4d0 b6f1ffa8
[  793.659879] ---[ end trace 6711fdf90d754294 ]---

The throughput on this is also pretty bad - I am on a 1Gbs fibre link on my old router DIR-860L(and on backup router), I was I getting close to 700Mbs on the wired connection, on this one I only get at most 350Mbs.

Any help/suggestions will be appreciated.

Is this a new router and have you run OEM firmware for comparison ?

Also, there has been two sets of updates since, have you updated ?

I have s similar issue with my ADSL modem, as it takes 20-30 minutes to go on line and obtain an IP address from provider, failing to authorize during this time. Once authorized however, the issue disappears even when rebooting. This issue has been prevalent with different routers, I had it with a TP-LINK C60, an ASUS and various EA8300. So, I've narrowed to a modem/provider issue. I understand not same as your issue, but maybe it can help your thought process.

Hi, thanks for the reply, it is a brand new router, I didn’t try the stock firmware. I will look for the update ( navigate from the openwrt site?). I have managed to resurrect my old dir-860l (it was rebooting on its own recently, hence the new router), but with that I get 750mbs up and down on speed test, with the mr830 max out at 350... All other routers, connect immediately once I reset my telco switch(they have me in bridged mode, if I swap out the router, I need a reboot, and it just works).Just glad I have a stable-ish connection... Will post more info as and when I have.

Updates will show with Luci, System, Software, Update Lists, Update. The first updates won't show and most recent updates supersedes.

However, you should update via SSH and use CLl opkg :
https://openwrt.org/docs/guide-user/additional-software/opkg

opk update
opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade

Hopefully this will fix

Also, make sure you don't overwrite failover OEM partition, this will always allow you to revert to stock firmware.

HI - not having much success with the cli - inevitably the network connection goes down and the process fails.. Any suggestions ? I was looking at building an image, but a comment above by cybrnook regarding radio calibration and DTS - by building the image using his buildinfo file only give me the standard EA8300, less his tweaks? Again thanks for you help.

You can connect the MR8300 wan port to a working router lan port, just make sure MR8300 wan is configured as DHCP client.

This will allow the MR8300 to connect to internet via working router, hopefully with stable connection.

Then update as connection should be stable. Also safer to connect workstation via Ethernet cable to lan port of MR8300 for update process...

What you suggested is what I am doing re connecting router to working port - even at this file things go pearshaped :

opkg upgrade base-files
Upgrading base-files on root from 228-r14438+1-4d747f5495 to 230-r14522-8cfb839907...
Downloading http://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/packages/base-files_230-r14522-8cfb839907_arm_cortex-a7_neon-vfpv4.ipk
Command failed: Not found
Command failed: Not found
umount: tmpfs busy - remounted read-only
umount: can't remount tmpfs read-only
umount: proc busy - remounted read-only
Collected errors:
 * copy_file: unable to open `/etc/group-opkg.backup': Read-only file system.
 * file_copy: Failed to copy file /etc/group to /etc/group-opkg.backup.
 * backup_make_backup: Failed to copy /etc/group to /etc/group-opkg.backup
 * pkg_write_filelist: Failed to open //usr/lib/opkg/info/base-files.list: Read-only file system.

You are free to build an image.

My staged PR is here: https://github.com/cybrnook/openwrt/commit/3e614882ca4c529dd755a56cc218c743347e6d6f

You can use that to create yourself a clean build if you wish.

I would think you have something else happening, especially if you are seeing strange behavior on both the EA8300 cross flash and my build.

If you want to check my link again to one drive, I uploaded my latest build from today (same as the screenshot below). One thing I changed is I removed MWAN3. I could build you a base image if you wish to help you. Core build with nothing but Luci.

I have no issues reaching my full link bandwidth and my WAN connection is instant (I have cable internet):

Looks like your install went berserk. Failover to OEM firmware, upload standard EA8300 factory, not the custom MR8300 from cybernook as it has a lot that can break in this case. All this as a DHCP client to working router.

Update via SSH as per my prior post in bold, reboot remaining client of working router. The MR8300 should now be ready at this point, run speed tests from workstation or from SSH CLI as follows :

Install test software :
opkg update && opkg install speedtest-netperf

Run rest software :
speedtest-netperf.sh -H netperf-west.bufferbloat.net -t 20

If all seems ok, you can now try the MR8300 as intended purpose.

Cybernook/Bobcat

Bobcat - the updating packages as per your instructions doesn't work - at some point the file system becomes read-only or the interface goes down and the update fails. Any time I attempt any kmod- updates that fails, individual components work (I have tried luci) coreutils turns the fs into ro. I will try the latest ea8300 from the repo with kernel 5.4.65 and attempt your speedtest. and see how that behaves and advise.

Cybernook - the latest file on the ondrive, openwrt-snapshot-r14484+47-673062fc56-ipq40xx-generic-linksys_mr8300-squashfs-factory - are still kernel 5.4.63, - https://onedrive.live.com/?authkey=!AE3A5sVnvWUUvCU&id=7F92809699F2E051!40396&cid=7F92809699F2E051

I'll mess around with the standard EA8300, Linux OpenWrt 5.4.65 and see how that behaves.. and let you know.

Thank you both for your help.

Honestly, seems your unit is defective if it goes nuts and can't update normally. The base software can't update without going nuts, no wonder want connection unworkable. I have two EA8300 and one MR8300 and they all installed without a hitch and updating was straitforward.

Almost looks like ram and flash are flaky. If you revert to stock, does unit function normally ?

Bobcat
I installed the standard EA8300 - connected it directly to my cable switch(restarted it), with just my laptop it worked - ran speedtest (from web got 488 down, 717 up) - rebooted, waited for 15 minutes, it had a lease but would not resolve any names - put dnsmasq in no-daemon and it would just timed out - I gave up.

Sat Sep 19 20:35:26 2020 daemon.err uhttpd[1161]: luci: accepted login on /admin/network/network for root from 192.168.1.158
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: reading /tmp/resolv.conf.d/resolv.conf.auto
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain test
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain onion
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain localhost
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain local
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain invalid
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain bind
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using only locally-known addresses for domain lan
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using nameserver 8.8.8.8#53
Sat Sep 19 20:36:35 2020 daemon.info dnsmasq[1766]: using nameserver 8.8.2.2#

oot@OpenWrt:/# nslookup google.com
;; connection timed out; no servers could be reached

root@OpenWrt:/# arp -a
IP address       HW type     Flags       HW address            Mask     Device
64.137.130.129   0x1         0x0         00:00:00:00:00:00     *        eth1
64.137.130.235   0x1         0x0         00:00:00:00:00:00     *        eth1
192.168.1.158    0x1         0x2         00:50:b6:21:f8:89     *        br-lan
root@OpenWrt:/# netstat -at
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:www             0.0.0.0:*               LISTEN
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN
tcp        0      0 64.137.130.204:domain   0.0.0.0:*               LISTEN
tcp        0      0 OpenWrt.lan:domain      0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 OpenWrt.lan:www         192.168.1.158:54695     TIME_WAIT
tcp        0      0 OpenWrt.lan:www         192.168.1.158:54696     TIME_WAIT
tcp        0      0 OpenWrt.lan:www         192.168.1.158:54704     TIME_WAIT
tcp        0      0 OpenWrt.lan:www         192.168.1.158:54705     TIME_WAIT
tcp        0      0 :::12865                :::*                    LISTEN
tcp        0      0 :::www                  :::*                    LISTEN
tcp        0      0 localhost:domain        :::*                    LISTEN
tcp        0      0 fe80::c641:1eff:feab:227f:domain :::*                    LISTEN
tcp        0      0 fdc9:dae:cc48::1:domain :::*                    LISTEN
tcp        0      0 fe80::c641:1eff:feab:227e:domain :::*                    LISTEN
tcp        0      0 :::ssh                  :::*                    LISTEN
root@OpenWrt:/#

I plugged my old router in, rebooted the provider's box plugged in everything is working..Plugged the MR8300 into one of the ports of the DIR860 Speedtest is now 800Mbs down and 700Up - which is what I normally see.

I am going to try to put the original FW on and see how that works.. Unfortunately I opened up the box to put a serial cable (misunderstood the http://routerip - would not resolve :wink: ). So my options are limited..

Once again thank you very much for your help, sincerely appreciated...

I have not used serial, my boxes are still and will always remain foctory sealed, for warranty purposes.

As I always used http://192.168.1.1/fwupdate.html backdoor to upgrade to OpenWRT using factory file for MR8300 19.07.3 and.4, The difficulties/issues of serial upgrade are totally bypassed here, as it becomes a straitforward flash upgrade via the OEM flash back door (meaning not readily updatable via OEM standard http interface).

This method of upgrading was the only one I would consider for the MR8300, as I already had 2 working EA8300 with OpenWRT.

I suggest once you revert to OEM, you upgrade via HTTP backdoor, hopefully this will fix all for you.

Bobcat/Cybernook

I was trying to re-flash the factory firmware :

root@OpenWrt:/tmp# mtd write /tmp/FW_MR8300_1.1.7.201281_prod.img kernel
Unlocking kernel ...

Writing from /tmp/FW_MR8300_1.1.7.201281_prod.img to kernel ...  [e]
Skipping bad block at 0x007e000
root@OpenWrt:/tmp# mtd write /tmp/FW_MR8300_1.1.7.201281_prod.img alt_kernel
Unlocking alt_kernel ...

The badblock is a bit suspicious - I have booted it back to the stock firmware so will see what happens.. through the stock firmware the performance is similar.. I suspect I have a dodgly device..

There are two boot partitions, if you never use sysupgrade, the other partition remains with OEM firmware.

Perform failover procédure :
Power up 15 seconds, power off 10 seconds
Repeat 3 times power up/down 15u, 10d sequentially.

Power up one last time and let it boot completely, the failover OEM partition should have booted.

I never use sysupgrade just to make sure I have an OEM failover solution.