Does the fw available from the selector: https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=qualcommax%2Fipq60xx&id=linksys_mr7500 include your code (i.e. NSS)? Also wondering if the dependency packages for ksmbd and DLNA will ever be made available to install (or if there is a workaround/manual way to do this). These are pretty standard features.
Booting router with some devices plugged into LAN ports solved the problem, so I decided not to fight further. Thanks a lot!
By the way the WAN port seems to drop randomly every 20hrs+. Any reasons and any way to walk around? Causing cameras and speakers to drop...
@pppig236 In the case of Linksys devices, the kernel partition overlaps the rootfs partition. If you do not define all partitions this way manually, then partition overlap does not occur:
[ 1.228654] Creating 20 MTD partitions on "qcom_nand.0":
[ 1.234914] 0x000000000000-0x000000180000 : "0:sbl1"
[ 1.242480] 0x000000180000-0x000000280000 : "0:mibib"
[ 1.246741] 0x000000280000-0x000000600000 : "0:qsee"
[ 1.254421] 0x000000600000-0x000000680000 : "0:devcfg"
[ 1.256256] 0x000000680000-0x000000700000 : "0:rpm"
[ 1.261352] 0x000000700000-0x000000780000 : "0:cdt"
[ 1.266018] 0x000000780000-0x000000800000 : "0:appsblenv"
[ 1.270893] 0x000000800000-0x000000980000 : "0:appsbl"
[ 1.277326] 0x000000980000-0x000000a00000 : "0:art"
[ 1.281529] 0x000000a00000-0x000000a80000 : "0:ethphyfw"
[ 1.286200] 0x000000a80000-0x000000b00000 : "u_env"
[ 1.291815] 0x000000b00000-0x000000b40000 : "s_env"
[ 1.296143] 0x000000b40000-0x000000b80000 : "devinfo"
[ 1.301033] 0x000000b80000-0x000001380000 : "kernel"
[ 1.313348] 0x000001380000-0x000005d80000 : "rootfs"
[ 1.386409] 0x000005d80000-0x000006580000 : "alt_kernel"
[ 1.399094] 0x000006580000-0x00000af80000 : "alt_rootfs"
[ 1.468373] 0x00000af80000-0x00000b380000 : "sysdiag"
[ 1.472684] 0x00000b380000-0x00001f080000 : "syscfg"
[ 1.767622] 0x00001f080000-0x00001f580000 : "app_data"
and all serial port installation steps do not apply.
This is currently an issue with the MR7350 and MR7500.
so whats the issue, is it causing any problems
In general, this is not a issue, it's just that these instructions from the commit message cannot be executed:
Flash instructions (With Serial):
========
1. Installation using serial connection from OEM firmware (default login: root, password: admin):
...
After first boot install firmware on second partition:
- mtd -r -e kernel -n write openwrt-qualcommax-ipq60xx-linksys_mr7500-squashfs-factory.bin kernel
or:
- mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq60xx-linksys_mr7500-squashfs-factory.bin alt_kernel
2. Installation from initramfs image using USB drive:
...
Write firmware to the flash from initramfs:
- mtd -e kernel -n write openwrt-qualcommax-ipq60xx-linksys_mr7500-squashfs-factory.bin kernel
and:
- mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq60xx-linksys_mr7500-squashfs-factory.bin alt_kernel
3. Back to the OEM firmware:
- mtd -e kernel -n write FW_MR7500_1.1.12.211919_prod.img kernel
and:
- mtd -r -e alt_kernel -n write FW_MR7500_1.1.12.211919_prod.img alt_kernel
2 Likes
Upon reading your post, I configured a rsyslog server and connected MR7500 to remotely logging to it (mostly to filter the "BEACON-REQ-TX-STATUS" and "BEACON-RESP-RX" spam). Since then the ethernet ports have been seamlessly up for 40hrs+ with no drop at all.
I don't remember anything else being changed except for the remote logging (port 514 UDP). Could this be related? I do remember all previous drops happened when there was very little LAN activities (at sleep, or no one at home). Could UDP logging keep some powersave features from kicking in? I did solve some similar situations with MTK switches by disabling EEE and Tx-LPI.
Finally some logs caught here, WAN went down when nothing happened to it. No one was even touching the entire home network:
May 11 18:13:28 OpenWRT-MR7500 netifd: Network device 'wan' link is down
May 11 18:13:28 OpenWRT-MR7500 kernel: nss-dp 3a003000.dp5-syn wan: PHY Link is down
May 11 18:13:28 OpenWRT-MR7500 kernel: br-lan: port 5(wan) entered disabled state
May 11 18:13:32 OpenWRT-MR7500 kernel: nss-dp 3a003000.dp5-syn wan: PHY Link up speed: 2500
May 11 18:13:32 OpenWRT-MR7500 kernel: br-lan: port 5(wan) entered blocking state
May 11 18:13:32 OpenWRT-MR7500 kernel: br-lan: port 5(wan) entered forwarding state
May 11 18:13:32 OpenWRT-MR7500 netifd: Network device 'wan' link is up
May 11 18:13:38 OpenWRT-MR7500 watchcat[4151]: Could not reach 8.8.8.8 for 60. Rebooting after reaching 21600
[233465.009039] nss-dp 3a003000.dp5-syn wan: PHY Link is down
[233465.009278] br-lan: port 5(wan) entered disabled state
[233469.159425] nss-dp 3a003000.dp5-syn wan: PHY Link up speed: 2500
[233469.159590] br-lan: port 5(wan) entered blocking state
[233469.164511] br-lan: port 5(wan) entered forwarding state
Luckily also found some older logs:
Sun Apr 27 13:58:25 2025 daemon.notice netifd: Network device 'wan' link is down
Sun Apr 27 13:58:25 2025 kern.info kernel: [679459.525885] nss-dp 3a003000.dp5-syn wan: PHY Link is down
Sun Apr 27 13:58:25 2025 kern.info kernel: [679459.526116] br-lan: port 5(wan) entered disabled state
Sun Apr 27 13:58:27 2025 daemon.notice hostapd: phy0-ap0: AP-STA-POLL-OK 88:88:88:88:88:88
Sun Apr 27 13:58:28 2025 daemon.notice hostapd: phy2-ap0: BEACON-REQ-TX-STATUS 11:11:11:11:11:11 209 ack=1
Sun Apr 27 13:58:35 2025 kern.info kernel: [679468.886122] nss-dp 3a003000.dp5-syn wan: PHY Link up speed: 2500
Sun Apr 27 13:58:35 2025 kern.info kernel: [679468.886280] br-lan: port 5(wan) entered blocking state
Sun Apr 27 13:58:35 2025 kern.info kernel: [679468.891200] br-lan: port 5(wan) entered forwarding state
Sun Apr 27 13:58:35 2025 daemon.notice netifd: Network device 'wan' link is up
[679459.525885] nss-dp 3a003000.dp5-syn wan: PHY Link is down
[679459.526116] br-lan: port 5(wan) entered disabled state
[679468.886122] nss-dp 3a003000.dp5-syn wan: PHY Link up speed: 2500
[679468.886280] br-lan: port 5(wan) entered blocking state
[679468.891200] br-lan: port 5(wan) entered forwarding state
I plugged it into a Linux server with a soft bridge when these logs are generated. Here are what's logged from the server:
[2134471.822276] igc 0000:05:00.0 enp5s0: NIC Link is Down
[2134471.822645] br0: port 2(enp5s0) entered disabled state
[2134476.058471] igc 0000:05:00.0 enp5s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[2134476.058653] br0: port 2(enp5s0) entered blocking state
[2134476.058666] br0: port 2(enp5s0) entered forwarding state
[2134477.830252] igc 0000:05:00.0 enp5s0: NIC Link is Down
[2134477.830589] br0: port 2(enp5s0) entered disabled state
[2134487.102013] igc 0000:05:00.0 enp5s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[2134487.102201] br0: port 2(enp5s0) entered blocking state
[2134487.102218] br0: port 2(enp5s0) entered forwarding state
[2134488.093660] igc 0000:05:00.0 enp5s0: NIC Link is Down
[2134488.105615] br0: port 2(enp5s0) entered disabled state
[2134497.325370] igc 0000:05:00.0 enp5s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[2134497.325437] br0: port 2(enp5s0) entered blocking state
[2134497.325440] br0: port 2(enp5s0) entered forwarding state
The WAN port drop/reset happens where ever it is plugged into though.
When i use the image in https://github.com/PIPIPIG233666/openwrt-ipq/releases
is there Luci included?
I tried the snapshot but there seems no way to connect to the internet to download luci.
yes, there is luci included
I tried connecting to multiple upstreams, soft-bridged Debian servers, routers, switches, all experienced the same random drops, just random-random: sometimes it doesn't drop for days... Still can't figure out why.
My upstream is an openwrt vm running on a pve mini pc w i-225v, it hasnt dropped since i rebooted a month ago... check if your psu is stable?
When I plugged into my main router there is no PSU in the whole picture, so I highly suspect the drop is still on the MR7500 end. I tried using the slower LAN ports on MR7500 and there were still random drops if it decided to do so...
Still learning the MR7500 with OpenWrt, but I think the kernel and rootfs are switched?
It looks like on most devices kernel is bigger than rootfs and rootfs is within kernel, but on the MR7500 it seems like the opposite. I wasn't able to write any images to kernel (in my exact case it was alt_kernel as I was running on boot_part 1), but I was able to write linksys_mr7500-squashfs-factory.bin from the OpenWrt snapshots to alt_rootfs and boot into it.
Not recommending anyone do this, but it worked for me.
1 Like
Thanks for the clarification, I missed the message yours was replying to.
new NSS update after a hiatus of a semester (smh its finally over)
credit to qosmio for fixing the bug that I had a while back
1 Like
Just installed this version via serial interface.
Had some troubles with returning to stock first so tried this methode.
It seems to work but i have a continuous running ledshow on the lanports. Is that a result of direct flashing or something else?
wireless activation is a bit hit and miss. 2.4GHz without problem. 5GHz enabled but no signal.
Exploring further...
root@OpenWrt:~# [ 432.467351] br-lan: port 1(lan1) entered disabled state
[ 432.467885] nss-dp 3a001000.dp1 lan1: left allmulticast mode
[ 432.471458] nss-dp 3a001000.dp1 lan1: left promiscuous mode
[ 432.477562] br-lan: port 1(lan1) entered disabled state
[ 432.484480] nss-dp 3a001000.dp1 lan1: PHY Link is down
[ 432.490870] nss-dp 3a001200.dp2 lan2: left allmulticast mode
[ 432.493005] nss-dp 3a001200.dp2 lan2: left promiscuous mode
[ 432.498967] br-lan: port 2(lan2) entered disabled state
[ 432.507099] nss-dp 3a001400.dp3 lan3: left allmulticast mode
[ 432.509330] nss-dp 3a001400.dp3 lan3: left promiscuous mode
[ 432.515419] br-lan: port 3(lan3) entered disabled state
[ 432.523550] nss-dp 3a001600.dp4 lan4: left allmulticast mode
[ 432.525777] nss-dp 3a001600.dp4 lan4: left promiscuous mode
[ 432.531700] br-lan: port 4(lan4) entered disabled state
[ 432.639385] br-lan: port 1(lan1) entered blocking state
[ 432.639424] br-lan: port 1(lan1) entered disabled state
[ 432.643460] nss-dp 3a001000.dp1 lan1: entered allmulticast mode
[ 432.649129] nss-dp 3a001000.dp1 lan1: entered promiscuous mode
[ 432.657867] br-lan: port 2(lan2) entered blocking state
[ 432.660439] br-lan: port 2(lan2) entered disabled state
[ 432.665610] nss-dp 3a001200.dp2 lan2: entered allmulticast mode
[ 432.670985] nss-dp 3a001200.dp2 lan2: entered promiscuous mode
[ 432.679585] br-lan: port 3(lan3) entered blocking state
[ 432.682569] br-lan: port 3(lan3) entered disabled state
[ 432.687754] nss-dp 3a001400.dp3 lan3: entered allmulticast mode
[ 432.693213] nss-dp 3a001400.dp3 lan3: entered promiscuous mode
[ 432.701737] br-lan: port 4(lan4) entered blocking state
[ 432.704705] br-lan: port 4(lan4) entered disabled state
[ 432.709863] nss-dp 3a001600.dp4 lan4: entered allmulticast mode
[ 432.715268] nss-dp 3a001600.dp4 lan4: entered promiscuous mode
[ 433.170551] br-lan: port 5(phy0-ap0) entered blocking state
[ 433.170598] br-lan: port 5(phy0-ap0) entered disabled state
[ 433.175081] ath11k c000000.wifi phy0-ap0: entered allmulticast mode
[ 433.180837] ath11k c000000.wifi phy0-ap0: entered promiscuous mode
[ 433.186996] br-lan: port 5(phy0-ap0) entered blocking state
[ 433.193000] br-lan: port 5(phy0-ap0) entered forwarding state
[ 433.199232] br-lan: port 5(phy0-ap0) entered disabled state
[ 433.710141] br-lan: port 5(phy0-ap0) entered blocking state
[ 433.710188] br-lan: port 5(phy0-ap0) entered forwarding state
[ 435.765293] nss-dp 3a001000.dp1 lan1: PHY Link up speed: 1000
[ 435.766440] br-lan: port 1(lan1) entered blocking state
[ 435.770023] br-lan: port 1(lan1) entered forwarding state
[ 797.613673] ath11k c000000.wifi phy0-ap0: left allmulticast mode
[ 797.613725] ath11k c000000.wifi phy0-ap0: left promiscuous mode
[ 797.618878] br-lan: port 5(phy0-ap0) entered disabled state
[ 889.975817] ath11k c000000.wifi: No regulatory rules available in the event info
[ 889.975860] ath11k c000000.wifi: failed to extract regulatory info
[ 889.984018] ath11k c000000.wifi: No regulatory rules available in the event info
[ 889.988301] ath11k c000000.wifi: failed to extract regulatory info
[ 920.141599] br-lan: port 5(phy0-ap0) entered blocking state
[ 920.141640] br-lan: port 5(phy0-ap0) entered disabled state
[ 920.146059] ath11k c000000.wifi phy0-ap0: entered allmulticast mode
[ 920.151889] ath11k c000000.wifi phy0-ap0: entered promiscuous mode
[ 1174.302281] ubi1: attaching mtd16
[ 1174.686989] ubi1: scanning is finished
[ 1174.745584] ubi1: attached mtd16 (name "alt_rootfs", size 74 MiB)
[ 1174.745626] ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 1174.750665] ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 1174.757458] ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 1174.764294] ubi1: good PEBs: 592, bad PEBs: 0, corrupted PEBs: 0
[ 1174.771073] ubi1: user volume: 2, internal volumes: 1, max. volumes count: 128
[ 1174.777320] ubi1: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1688401815
[ 1174.784355] ubi1: available PEBs: 8, total reserved PEBs: 584, PEBs reserved for bad PEB handling: 80
[ 1174.793653] ubi1: background thread "ubi_bgt1d" started, PID 7749
[ 1174.794403] block ubiblock1_0: created from ubi1:0(rootfs)
> Blockquote
Some more testing..
LED lights on lanports keep looping. Nice to see and it seems no harm but strange.
Trying to build a mesh802S on 5GHZ radio together with a normal SSID openwrt5.
It does not always work both. It is possible in DD-WRT to do this (and had it running) But it activated itself later it seems.. strange..
So its a Mesh802S OR a 5GHz SSID both seems problematic.
signal 0 dBm so no transmitting?
Mode: Client | SSID: Mesh802S
BSSID: DA:EC:xxxxxx
Encryption: -
Channel: 100 (0 GHz)
Tx-Power: 25 dBm
Signal: 0 dBm | Noise: -95 dBm
Bitrate: 0 Mbit/s | Country: NL
The Mesh itself even when WPA3 AES is active shows as encryption: "none". Strange.
reading about mesh support ( it kind of worked in dd-wrt):
It is recommended that you use firmware selector to request a custom firmware build that removes the -ct module (ex: kmod-ath10k-ct) and the -ct firmware (ex: ath10k-firmware-qca9984-ct) and replaces them with the non-ct versions (ex: kmod-ath10k and ath10k-firmware-qca9984) to get reliable mesh support.
Use the following to determine if your hardware supports 802.11s mesh.
iw list | grep "Supported interface modes" -A 9
$ iw list | grep "Supported interface modes" -A 9
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* P2P-client
* P2P-GO
* P2P-device
Band 1:
So no support in this snapshot?