So, I have got a replacement - assuming my router itself was faulty, since it doesn't boot to even alt_firmware successfully.
With my second attempt at using OpenWRT on the E5600, I can confirm the reboot bug exists.
Steps to reproduce:
Open LUCI.
Navigate to: System>Reboot
Click on the Reboot button.
Expected behavior: Router should restart and boot up successfully.
Actual behavior: Router tries to reboot. All LEDs stay off, router is unresponsive, LUCI is not accessible via LAN, WiFi SSIDs don't show up.
So, I have discovered that this behavior occurs only when the WAN port of the router is disconnected. Reboot works as expected when WAN is connected to the internet via my primary router.
Also, is there a reason why wpad-mesh-openssl & wpad-mesh-wolfssl don't work with this build/router?
WiFi radios don't turn up, and I have this in my logs:
Fri Mar 5 08:46:03 2021 user.notice firewall: Reloading firewall due to ifup of wan6 (wan)
Fri Mar 5 08:46:03 2021 daemon.err odhcpd[1736]: Failed to send to ff02::1%lan@br-lan (Address not available)
Fri Mar 5 08:46:03 2021 daemon.debug dnsmasq[3720]: listening on wan(#7): fd57:9984:85c6:0:ea9f:80ff:fe35:a5c4 port 53
Fri Mar 5 08:59:32 2021 daemon.debug dnsmasq[3720]: listening on wan(#7): fd57:9984:85c6::17c port 53
Fri Mar 5 08:59:47 2021 daemon.err odhcpd[1736]: Failed to send to ff02::1%lan@br-lan (Address not available)
**Fri Mar 5 08:59:54 2021 daemon.notice netifd: radio0 (2426): Command failed: Request timed out**
**Fri Mar 5 08:59:54 2021 daemon.notice netifd: radio0 (2426): Command failed: Not found**
**Fri Mar 5 08:59:54 2021 daemon.notice netifd: radio0 (2426): Device setup failed: HOSTAPD_START_FAILED**
**Fri Mar 5 08:59:54 2021 daemon.notice netifd: radio1 (2428): Command failed: Request timed out**
**Fri Mar 5 08:59:54 2021 daemon.notice netifd: radio1 (2428): Command failed: Not found**
**Fri Mar 5 08:59:54 2021 daemon.notice netifd: radio1 (2428): Device setup failed: HOSTAPD_START_FAILED**
Fri Mar 5 09:00:03 2021 daemon.err odhcpd[1736]: Failed to send to ff02::1%lan@br-lan (Address not available)
Fri Mar 5 09:00:14 2021 daemon.err uhttpd[2293]: luci: accepted login on / for root from 192.168.1.130
Fri Mar 5 09:00:19 2021 daemon.err odhcpd[1736]: Failed to send to ff02::1%lan@br-lan (Address not available)
Fri Mar 5 09:00:31 2021 authpriv.info dropbear[4542]: Child connection from 192.168.1.130:47590
Fri Mar 5 09:00:32 2021 authpriv.notice dropbear[4542]: Auth succeeded with blank password for 'root' from 192.168.1.130:47590
Fri Mar 5 09:00:35 2021 daemon.err odhcpd[1736]: Failed to send to ff02::1%lan@br-lan (Address not available)
[UPDATE]
Possibly found a hint. I have this from hostapd:
root@OpenWrt:~# hostapd
Error loading shared library libubox.so.20210302: No such file or directory (needed by /usr/sbin/hostapd)
root@OpenWrt:~# opkg install libubox
Package libubox20201212 is already installed on root.
Note:
Issues started after I have removed wpad-basic-wolfssl, and installed wpad-mesh-openssl.
I think you will have to wait for the snapshot build. Once snapshot is out you will not have errors with libraries (though you will have to stay updated to install new libraries later if you need to).
We need to include the MT7663 STA kmod as well, to be able to use mesh mode over the 5Ghz radio.
Just for the reboot bug now! I can see this occuring occassionally when the WAN port is connected as well. For example, performing a sysupgrade hands doesn't reboot the router completely. It flashes the firmware, and the Ethernet ports function as a switch(able to access my primary router as well as internet, but the power LED is off and this router's LUCI/SSH is not accessible.
The AP firmware is still missing in the latest build commit but that’s easy to install. I will be building a new snapshot today on an x86 machine (as opposited to rpi I used for building the other image) that doesn’t come with luci such that I will install anything else directly from openwrt afterwards (probably a better way to do it). Anyway I will commit the new build in my repo. There seem to be some formal issues with the commit according to reviews but otherwise I hope it’s good to go so that I can stop building for it and rely on snapshots.
The master branch of my repository https://github.com/aashishkul/openwrt is now updated with lastest changes from openwrt/master. I have also pulled the development branch changes into master branch. I created a version of the firmware using master branch and found it to be very stable. Those who faced issues with the earlier firmware, may check using master branch.
I did built one from your branch merged into the official master. For now I cannot go back to stock anymore. Not sure why but I just can't manage it to boot from alternate version. I may have corrupted it or I have no way to find out which version is currently booted. Anyway my own build seems to be working fine (assuming I don't brick it due to corrupted alternate firmware). I think there is a NAND error like you mentioned the NAND is not used anywhere :
[ 22.634177] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.0
[ 22.641760] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.1
[ 22.646146] pppoe-wan: renamed from ppp0
[ 22.649258] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.2
[ 22.660325] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.3
I am wondering if there is a different NAND driver that must be used or if this is unrelated.
Also the new 5.10 kernel has mt76 driver improvements which apparently does have a testing flag for ramips so it could be interesting to test out the new driver on this device.
I think I do remember seeing something like 'backported 5.10' something in dmesg which makes sense since the wireless drivers seem to work well. I can't find the post where someone explained the difference between 7613 and 7615 driver which was minor. I wonder if there will be a kernel module for 7613 soon.
MT76 already supports MT7613 but it's still a bit rough (no DFS e.g.). You also need some mt7663 firmware instead (which OpenWrt offers BTW). Look at the build profile of the EAP235-Wall e.g.
Also, mt76 doesn't follow mac80211 but is pulled from its own repository, so it is/will often be newer than the mac80211 backport OpenWrt uses.
I seem to have issues trying to boot from Stock too. Somehow, the router just hangs if I do the "3 time power-on/power-off" trick, instead of booting to stock.
I do have my router booting to OpenWrt successfully at the moment. Is there anything I can do to fix the stock firmware partition? Anything I can do to verify the partition? How can I tell which partition the router booted from?
This is exactly what happens to me. Can't find a way to know which one I am booting from. I did manage it to get it to boot from stock once but that was it. I do not plan on going to stock but it would be great to know that its there in case I messed up something.