My internet has been really unreliable on new 21.02 firmware and it doesn't seem to be something that will change. I tried installing 19.x and it failed. Can someone tell me how to do this?
Several options.
- The WRT series is a dual flash layout. You can use power switch or SSH method if you haven't overwritten both partitions.
https://www.linksys.com/us/support-article?articleNum=316324 - Use one of the methods here:
https://openwrt.org/toh/linksys/wrt3200acm
Likely that does not work more, as the other partition now contains non-working 19.07:
You can just flash the factory image, using "force" option and unselect "keep settings". (using factory enables overriding the compatibility check)
You shouldn’t need a factory image to this. Just install a 19.07 system upgrade image and do not keep settings and check the force install.
with wrt3200 the trick is to have always the official firmware on one partition, and always flash the openwrt-factory.bin from official firmware. that way will always work.
2 Likes
Normally not, but I am not sure if that downgrade succeeds due to the mvebu DSA config change warning/prevention in sysupgrade (even with the force option).
mvebu factory images are without OpenWrt image metadata, so the "force" should work with it (even if it fails with a sysupgrade image).
I have tried that earlier this year on my wrt3200acm with success.
But it’s a long time ago and I don’t remember if there was 2 or 3 colored warnings in LuCi with checkboxes. I think I failed the first time also but when I checked the last warning it worked.
Okay this is really interesting that there are two partitions. I installed the tool and since I re-installed 21 so many times it just ends up that my backup partition was just a previous version of 21. If I had known this I could have just reverted immediately instead.
Is there a way to flash the image to the non-booted partition without rebooting my router? Also is it possible to migrate some of my settings to the other partition without having to clean install and then set them up manually? It's feasible really easy to copy some of the configs...
Flashing always goes to the other partition (non-booted), a round robin, that way if it is borked you can go back from whence you came. Just take a config backup, but pay attention to changes (i.e. DSA). if you want to control partition usage (i.e. 21.x on one and master on the other) CLI:
bootTaOther.sh
#!/bin/sh
#hacked from /lib/upgrade/linksys.sh
cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
target_firmware=""
if [ "$cur_boot_part" = "1" ]
then
target_firmware="kernel2"
fw_setenv boot_part 2
fw_setenv bootcmd "run altnandboot"
elif [ "$cur_boot_part" = "2" ]
then
target_firmware="kernel1"
fw_setenv boot_part 1
fw_setenv bootcmd "run nandboot"
fi
# re-enable recovery so we get back if the new firmware is broken
fw_setenv auto_recovery yes
echo "$target_firmware"
reboot
and there is also a GUI app to be installed.
1 Like
luci-app-advcanced-reboot
There is a little known mvebu-specific way: OpenWrt does not use the pretty large "syscfg" partition, where the Linksys OEM firmware stores intermediate files.
OpenWrt only uses that partition to store the config backup archive .tar.gz during sysupgrade. And after the sysupgrade the archive gets deleted.
But otherwise the partition is unutilised, but it is always mounted at /tmp/syscfg. That looks confusing, as /tmp is ramdisk, but yes, there is a permanently mounted large flash partition at /tmp/syscfg. And that is common and visible to both dual-boot partitions.
So, you could could make a backup from your settings (with the sysupgrade script) and store that to some new directory in /tmp/syscfg. You can then later easily restore them (with the sysupgrade script) to the then running partition.
2 Likes
Okay so I was able to flash over to 19.07.8, using the factory image was the trick and I didn't get the erorr I did previously. Now it's really weird because my AC wifi just doesn't work anymore. It originally worked fine when I was using 19.07.8, then I had my issues with 21.x, and now being back on 19.07.8 has somehow broken it.
Are you sure that you have not restored "newer" configs from a future firmware (21.02) to the old 19.07 ...
Some options do change between versions, e.g. the wifi band option is new in master and 21.02, but is not supported in 19.07
Example from my routers:
This is from a new style config (master): option band '5g'
config wifi-device 'radio1'
option type 'mac80211'
option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option cell_density '0'
option htmode 'HE40'
option channel '44'
While this is the old style: hwmode '11a'
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option country 'FI'
option log_level '2'
option cell_density '0'
option htmode 'VHT40'
option txpower '21'
option disabled '0'
Note that you can regerate the 19.07 default wifi config with wifi config, which only works if you have no /etc/config/wireless file.
root@router1:~# cd /etc/config/
root@router1:/etc/config# mv wireless wireless.backup
root@router1:/etc/config# wifi config
root@router1:/etc/config# ls -l wireless*
-rw-r--r-- 1 root root 707 Sep 23 19:14 wireless
-rwxr-xr-x 1 root root 1030 Sep 19 22:41 wireless.backup
There is now a new "wireless" with default contents. (in addition to your old settings in wireless.backup)
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
option channel '56'
option htmode 'VHT40'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option key 'xxx'
option ssid 'yyy'
option encryption 'psk-mixed'
This is what I have now, it looks like the old style. When I reflashed I made sure to exclude keeping the config, but it seemed inconsistent. At least the IP restarted with OpenWRT named AP and the IP reset as well
you are missing the country and txpower options. (I do not remember if they are mandatory)
what does you kernel and system logs show about wifi (and hostapd)? Usually there are explanations if you do "wifi up".
I added country code and power, it seemed like they were optional but I can't be sure. Still doesn't work.
Thu Sep 23 09:41:57 2021 daemon.notice hostapd: wlan0: INTERFACE-ENABLED
Thu Sep 23 09:41:57 2021 daemon.notice hostapd: wlan0: INTERFACE-DISABLED
Thu Sep 23 09:41:57 2021 daemon.err hostapd: nl80211: Could not configure driver mode
Thu Sep 23 09:41:57 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Thu Sep 23 09:41:57 2021 daemon.err hostapd: nl80211 driver initialization failed.
Thu Sep 23 09:41:57 2021 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Thu Sep 23 09:41:57 2021 daemon.notice hostapd: wlan0: AP-DISABLED
Thu Sep 23 09:41:57 2021 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Thu Sep 23 09:41:57 2021 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Thu Sep 23 09:41:57 2021 daemon.notice netifd: radio0 (6518): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Thu Sep 23 09:41:57 2021 daemon.notice netifd: radio0 (6518): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)
Thu Sep 23 09:41:57 2021 daemon.notice netifd: radio0 (6518): Command failed: Invalid argument
Thu Sep 23 09:41:57 2021 daemon.notice netifd: radio0 (6518): Device setup failed: HOSTAPD_START_FAILED
Thu Sep 23 09:41:57 2021 user.notice mac80211: Failed command: iw phy phy1 set antenna 0xffffffff 0xffffffff
Thu Sep 23 09:41:57 2021 daemon.notice netifd: radio1 (6595): command failed: Not supported (-95)
Thu Sep 23 09:41:57 2021 user.notice mac80211: Failed command: iw phy phy1 set distance 10
Thu Sep 23 09:41:58 2021 daemon.err hostapd: Configuration file: /var/run/hostapd-phy1.conf
Thu Sep 23 09:41:58 2021 kern.debug kernel: [ 7018.271941] ieee80211 phy1: change: 0xffffffff
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.360188] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.367155] br-lan: port 2(wlan1) entered blocking state
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.372526] br-lan: port 2(wlan1) entered disabled state
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.377960] device wlan1 entered promiscuous mode
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.382751] br-lan: port 2(wlan1) entered blocking state
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.388088] br-lan: port 2(wlan1) entered forwarding state
Thu Sep 23 09:41:58 2021 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Thu Sep 23 09:41:58 2021 daemon.err hostapd: Using interface wlan1 with hwaddr MAC and ssid "ssid"
Thu Sep 23 09:41:58 2021 kern.debug kernel: [ 7018.447121] ieee80211 phy1: change: 0x100
Thu Sep 23 09:41:58 2021 kern.debug kernel: [ 7018.460176] ieee80211 phy1: change: 0x42
Thu Sep 23 09:41:58 2021 kern.info kernel: [ 7018.609082] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Thu Sep 23 09:41:58 2021 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->ENABLED
Thu Sep 23 09:41:58 2021 daemon.notice hostapd: wlan1: AP-ENABLED
Thu Sep 23 09:41:58 2021 daemon.notice netifd: Network device 'wlan1' link is up
Thu Sep 23 09:42:05 2021 daemon.info hostapd: wlan1: STA <MAC> IEEE 802.11: associated (aid 1)
Thu Sep 23 09:42:05 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED <MAC>
Thu Sep 23 09:42:05 2021 daemon.info hostapd: wlan1: STA <MAC> WPA: pairwise key handshake completed (RSN)
Thu Sep 23 09:42:05 2021 daemon.info dnsmasq-dhcp[3260]: DHCPREQUEST(br-lan) 192.168.1.54 <MAC>
Thu Sep 23 09:42:05 2021 daemon.info dnsmasq-dhcp[3260]: DHCPACK(br-lan) 192.168.1.54 <MAC> work.lan
Thu Sep 23 09:42:05 2021 daemon.info hostapd: wlan1: STA <MAC> IEEE 802.11: authenticated
channel 56 is dfs, so make sure that you set contry code FR,and leave txpower to auto
CC, and TX power are ignored on the rango, but if the third radio is in play it has to be in agreement with CC of the mwlwifi radios.
Okay that's weird I guess I will choose another channel there really isn't any info there.
As for the third radio it's not enabled so I guess that doesn't matter?
Changing to a different channel seems to have no effect regardless of whether my computer should be able to connect I would assume that LUCI would tell me it's on and operational though no?