divested wrt (r16965) on partition 1
flashed 21.02.rc3 to other partition without saving configuration, got red/yello box warning, proceeded to flash
21.02rc3 on partition 2, booted successfully
manually configured, including disabling WAN ports and reconfiguring LAN IP to 192.168.1.4 (set up as access point)
reboot to same partion: all config lost, reverted to 192.168.1.1
this is reproducible.
snapshot builds including newest r17019 do not have this apparent bug
Indeed the u-boot settings for nand read were wrong. I changed the kernel size from 2MiB to 3MiB, as described in your link, and now I could sysupgrade. I checked, the kernel of the previous OS (19.07.0rc2) was slightly smaller than 2MiB, so that didn't need it.
However, the initramfs-kernel still won't boot, due to the same lzma error. I tried both loadaddr 0x80B00000 as you suggested, and 0x80800000 because the nand load command uses that address.
Another problem is that wireless doesn't work. it doesn't show up in dmesg at all. In 19.07.7 it shows:
[ 11.809300] PCI: Enabling device 0000:00:0e.0 (0000 -> 0002)
[ 11.813792] ieee80211 phy0: rt2x00lib_request_eeprom_file: Info - Loading EEPROM data from 'RT3062.eeprom'.
[ 11.826545] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3572, rev 0223 detected
[ 11.832975] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0008 detected
[ 11.841042] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 11.852389] kmodloader: done loading kernel modules from /etc/modules.d/*
but in 21.01.0rc3 there is no trace of it. I wanted to check if that problem is solved in snapshot, but that brought me again to an lzma error:
NAND read: device 0 offset 0x60000, size 0x300000
3145728 bytes read: OK
## Booting kernel from Legacy Image at 80800000 ...
Image Name: MIPS OpenWrt Linux-5.4.124
Created: 2021-06-23 6:22:19 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 2625859 Bytes = 2.5 MiB
Load Address: 80002000
Entry Point: 80002000
Verifying Checksum ... OK
Uncompressing Kernel Image ... LZMA: uncompress or overwrite error 7 - must RESET b
Your config looks mostly OK, that dmz port is the only thing that doesn't seem to fit.
What's the output of brctl show ?
If you can debug that problem and tell us what's missing in the 21.02 branch. It may be hard to just guess (without any debugging) why 21.02 branch doesn't work.
I think that @RaylynnKnight has a problem with wired ports, so WLAN bridging should not matter.
Still what you described sounds like a bug. Please kindly provide config:
Before migration
After migration
After manual fixup
That hopefully will let us understand the problem and fix it so other users don't hit it.
Actually there is a 64 bit version of the official Raspberry Pi distro. And now, with the UEFI firmware for RPi4 running your own 64bit (aarch64) distro like Ubuntu, Debian, Fedora, hell even Windows 10 ARM has become much easier and accessible.
I'm running Fedora 34 on my 8GB Pi right now as a security system.
Hoping to help debugging, I collected some logs from the same device, but with different images.
TL;DR: Where snapshot netifd and/or usbmuxd seem to kick in, rc3 logs just stop at this: Thu Jun 24 14:19:14 2021 kern.info kernel: [ 312.497790] usb 2-1: new high-speed USB device number 2 using ehci-platform
Full logs from snapshot:
:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r16925-b721579842'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r16925-b721579842'
DISTRIB_TAINTS=''
5.4.124 #0 Thu Jun 10 08:34:44 2021 mips GNU/Linux
usbmuxd v 1.1.1-1
Thu Jun 24 14:08:21 2021 kern.info kernel: [ 392.740142] usb 2-1: new high-speed USB device number 5 using ehci-platform
Thu Jun 24 14:08:21 2021 daemon.notice netifd: Interface 'iphone' is enabled
Thu Jun 24 14:08:21 2021 kern.info kernel: [ 392.959037] ipheth 2-1:4.2: Apple iPhone USB Ethernet device attached
Thu Jun 24 14:08:21 2021 daemon.err usbmuxd[2081]: [14:08:21.624][3] Connecting to new device on location 0x20005 as ID 2
Thu Jun 24 14:08:21 2021 daemon.err usbmuxd[2081]: [14:08:21.626][3] Connected to v2.0 device 2 on location 0x20005 with serial number 80f66e5727181cc208850bbdd9680d43ddae4671
Thu Jun 24 14:08:22 2021 daemon.notice netifd: Network device 'eth1' link is up
Thu Jun 24 14:08:22 2021 daemon.notice netifd: Interface 'iphone' has link connectivity
Thu Jun 24 14:08:22 2021 daemon.notice netifd: Interface 'iphone' is setting up now
Thu Jun 24 14:08:22 2021 kern.info kernel: [ 394.102005] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Thu Jun 24 14:08:23 2021 daemon.notice netifd: iphone (3548): udhcpc: started, v1.33.1
Thu Jun 24 14:08:23 2021 daemon.notice netifd: iphone (3548): udhcpc: sending discover
Thu Jun 24 14:08:23 2021 daemon.notice netifd: iphone (3548): udhcpc: sending select for 172.20.10.3
Thu Jun 24 14:08:23 2021 daemon.notice netifd: iphone (3548): udhcpc: lease of 172.20.10.3 obtained, lease time 85536
Thu Jun 24 14:08:23 2021 daemon.notice netifd: Interface 'iphone' is now up
Full logs from rc3:
:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='21.02.0-rc3'
DISTRIB_REVISION='r16172-2aba3e9784'
DISTRIB_TARGET='ath79/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt 21.02.0-rc3 r16172-2aba3e9784'
DISTRIB_TAINTS=''
5.4.124 #0 Sun Jun 13 22:02:19 2021 mips GNU/Linux
usbmuxd v 1.1.1-1
Thu Jun 24 14:19:14 2021 kern.info kernel: [ 312.497790] usb 2-1: new high-speed USB device number 2 using ehci-platform
Ehh... I find it's been so long (and maybe I'm trying to forget about it at this point) that I'm not 100% sure of all the symptoms. As I recall, the 2.4ghz connected stuff will lose net access. Maybe for a brief interval that repairs itself, to dropping connectivity and staying down until a reset. Not as sure if they disconnect from the radio, I think they usually stay connected. Nothing much shows in the log files, especially as an AP. In my separate router logs, (both, really) I might see all wifi1 items disappear activity.wise.
I finally took the approach of some other's, and have a chron script to bring the 2.4ghz radio down and back, every night at 4am, and gave up. This has prevented the radio going down and staying down. which used to happen every 2-4 days. I still do have the occasional time where things seem to not have access, and then minutes later its OK. There are several threads on here where people have tried to figure this out. Seems to have started somewhere around the 18.x.x.x series, back earlier C7's one of the most used and popular OpenWRT routers, and they were rock solid perfect. I'd have no problems, with uptime determined by me playing with stuff, to one time the 3-4 months between the next OpenWRT release.
On my ea6530v3, cherry-picking this commit: https://github.com/openwrt/openwrt/commit/4b37e3bc2b2a079c996b6d97b8d3dbbd4ba6eb62 into openwrt-21.02 fixes the issue entirely, but it seems as though it doesn't work for all boards, per @pennyweight's last post. I'm not even sure if I can say it's applicable to all ipq40xx devices, but the patch in this commit is at least a part of the solution.
After two days of uptime test, encountered an android smartphone on 5 GHz WiFi displaying: Connected, no internet.
Signal strength was excellent.
Connecting to 2.4 GHz WiFi then switching back to 5 GHz resolved issue.
Occupied at the time of the incident so did not check logs but will keep an eye out for any repeat error.
I think, a few hours ago I ran into the same bug on a DIR-1960 with rc3. Disconnect and reconnect of the client fixed it.
882 and 1960 are MediaTek MT7615N
Edit: for me it was around 48 hours after first flashing OpenWRT, the uptime at the time of error must have been around 20h
Sat Jun 26 09:09:42 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0)
Sat Jun 26 09:09:42 2021 daemon.err hostapd: Interface name wlan0 already in use
Sat Jun 26 09:09:42 2021 daemon.notice netifd: radio0 (6254): Command failed: Invalid argument
Sat Jun 26 09:09:42 2021 daemon.notice netifd: radio0 (6254): Device setup failed: HOSTAPD_START_FAILED
Sat Jun 26 09:09:42 2021 daemon.notice netifd: radio0 (6317): WARNING: Variable 'data' does not exist or is not an array/object
Sat Jun 26 09:09:45 2021 daemon.notice hostapd: wlan0: ACS-COMPLETED freq=2437 channel=6
Sat Jun 26 09:09:45 2021 kern.info kernel: [ 798.359661] mwifiex_pcie 0000:01:00.0: CMD_RESP: cmd 0xb1 error, result=0x1
Sat Jun 26 09:09:45 2021 kern.info kernel: [ 798.366970] mwifiex_pcie 0000:01:00.0: Failed to start the BSS
Sat Jun 26 09:09:45 2021 kern.info kernel: [ 798.373001] mwifiex_pcie 0000:01:00.0: Failed to start AP
Sat Jun 26 09:09:45 2021 daemon.notice hostapd: wlan0: interface state ACS->ENABLED
Sat Jun 26 09:09:45 2021 daemon.notice hostapd: wlan0: AP-ENABLED
Sat Jun 26 09:09:51 2021 kern.info kernel: [ 804.360006] mwifiex_pcie 0000:01:00.0: CMD_RESP: cmd 0xb1 error, result=0x1
Sat Jun 26 09:09:51 2021 kern.info kernel: [ 804.367431] mwifiex_pcie 0000:01:00.0: Failed to start the BSS
Sat Jun 26 09:09:51 2021 kern.info kernel: [ 804.373511] mwifiex_pcie 0000:01:00.0: Failed to start AP
Sat Jun 26 09:09:57 2021 kern.info kernel: [ 810.385323] mwifiex_pcie 0000:01:00.0: CMD_RESP: cmd 0xb1 error, result=0x1
Sat Jun 26 09:09:57 2021 kern.info kernel: [ 810.392770] mwifiex_pcie 0000:01:00.0: Failed to start the BSS
Sat Jun 26 09:09:57 2021 kern.info kernel: [ 810.398860] mwifiex_pcie 0000:01:00.0: Failed to start AP
I also use Newifi 3 D2 but I cannot success to use ocserv 1.1.3 (openconnect).
The server only return the same sha256 number whatever I use diff. cert. .
