I found it, thank you!
With you being on 100-112 that’s Band B range in the UK, it’s seem like that DFS (Dynamic Frequency Selection) best to check your logs to see if DFS kicked in. I know if auto is not selected the router will just keep trying to reconnect on the same channel.
Any news on when the next master snapshot will be branched? I believe 5.15 is the kernel version for the mt7622 target?
I'm trying to guess what the next one will be 23.XX-SNAPSHOT, I'm not having much luck:
https://downloads.openwrt.org/releases/23.01-SNAPSHOT/targets/
Generally, the devs want all targets on the same kernel for a stable release. So the 5.15 kernel version is not specific to just the MT7622 w.r.t a stable release.
As to when, while the first 22.03 release candidate was tagged near the end of April 2022, it was not released until September 2022. In other words, it is really early days for trying to predict when the next stable release will be out.
In the end it depends on the goals for the next release and how long it take to implement them. Maybe that is everything on kernel 5.15 with dnsmasq 2.87; maybe that is kernel 6.1? Only the devs know what their plans are.
1 Like
i don't get the real iusse here on stable branch mt7622 , this devices are runnig good on stable. mabie i'm missing something
1 Like
I just got this router and it works fine so far ...
Is there a way to make sure the beamforming works?
I added those lines under the 5ghz radio: (taken from tips to do after installing openwrt)
option he_su_beamformee '1'
option he_bss_color '8'
That. It's why I wrote that section of the wiki page.
2 Likes
I saw that there are ax issues but I don't think it affects me or my use, we live in a very small place <600 sq ft. I thing I wonder is that I before yesterday I used an TP-Link Archer7 v2 (old) but I only pay for 75/7mb internet so it was fine. The only thing is that if I watched a hockey game or any streamed sports frequently it would become very pixelated and then comeback to normal. I blamed the internet since the TP-Link's resources looked ok. But last night with this new router it just went flawlessly for 3h. I guess it's the better performance of this new router? Using Apple TV 4k 2nd gen. (Maybe wifi6 beamforming helps)
1 Like
Has anyone run into random crashes?
Unit seemed to be stable for a couple weeks but now dies spontaneously from various processes and Luci becomes unavailable as well, but SSH remains. All say the same Tainted message. sometimes hostapd and various other processes, not always the same. Tried re-installing the UBI firmware in case some files were corrupted.
Currently running: OpenWrt 22.03.2, r19803-9a599fee93
Example crash in log.
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.325054] ------------[ cut here ]------------
Mon Nov 21 09:48:12 2022 kern.warn kernel: [68749.329679] WARNING: CPU: 1 PID: 5082 at 0xffffffc0088caa58 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.338366] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7915e mt7615e mt7615_common mt76_connac_lib mt76 mac80211 cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c hwmon crc_ccitt compat seqiv leds_gpio xhci_plat_hcd gpio_button_hotplug
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.397239] CPU: 1 PID: 5082 Comm: kworker/u4:0 Tainted: G S W 5.10.146 #0
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.405231] Hardware name: Linksys E8450 (UBI) (DT)
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.410106] Workqueue: phy1 0xffffffc0088d0870 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.417669] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.423668] pc : 0xffffffc0088caa58 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.430273] lr : 0xffffffc0088ca904 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.436877] sp : ffffffc013a3bc70
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.440182] x29: ffffffc013a3bc70 x28: 000000000000001e
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.445487] x27: ffffffc00892a2b0 x26: 0000000000000005
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.450791] x25: ffffffc010acf000 x24: ffffff80021590a0
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.456095] x23: ffffff800237c610 x22: ffffffc0088cadf8
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.461399] x21: 0000000000000002 x20: ffffff8001a64300
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.466703] x19: ffffff8001bc1000 x18: 00000000000001b6
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.472007] x17: 00000000ffffffff x16: 0000000000000000
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.477312] x15: ffffffc010a09998 x14: 0000000000000522
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.482617] x13: 00000000000001b6 x12: ffffffc013a3b768
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.487921] x11: ffffffc010a61998 x10: 00000000fffff000
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.493225] x9 : ffffffc010a61998 x8 : 00000000000009bc
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.498529] x7 : ffffffc010a09998 x6 : 0000000000000001
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.503834] x5 : 0000000000000000 x4 : 0000000000000000
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.509138] x3 : ffffff8000d6ad00 x2 : 0000000000000000
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.514441] x1 : ffffff8000d6ad00 x0 : 00000000ffffff92
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.519747] Call trace:
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.522190] 0xffffffc0088caa58 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.528450] 0xffffffc0088cadf8 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.534709] 0xffffffc0088c9738 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.540967] 0xffffffc0088d0c34 [mac80211@00000000a52ffb88+0x79000]
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.547223] 0xffffffc010045494
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.550355] 0xffffffc0100457a8
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.553486] 0xffffffc01004c530
Mon Nov 21 09:48:12 2022 kern.debug kernel: [68749.556617] 0xffffffc010005f68
Mon Nov 21 09:48:12 2022 kern.warn kernel: [68749.559749] ---[ end trace 3d2fcfdc6c34b1db ]---
I'm at 22 days of uptime and everything is working. However, i'm running a snapshot build.
Rock solid here.
Actually by chance running the same version: `OpenWrt 22.03-SNAPSHOT, r19803-9a599fee93
$ uptime
17:01:39 up 24 days, 22:58
This is my main router, running
sqm, vlan, DAWN, wireguard, adblock
Some config optinons:
5GHz AC 80 MHz (not AX, since I observed a significant degradtion of throughput already at -65dB a while back)
irq balancing
no SW/HW offloading
Allthough I have to admit that this is not serving many wireless clients (located in the basement)
My main APs use WED and hence have a more recent SNAPSHOT running:
OpenWrt SNAPSHOT, r21306-49bbfd9968
which is only a few days old.
I still feel kind of lost understanding the UBI story. I mean I do understand, how UBI is different.
I just seem to have missed the decisions and reasons, why UBI-conversion and repartitioning of this device now is mandatory?
Especially as for all other devices, it was always insisted to stay on vendor partition schema at all cost, even though other devices could profit as well from enlarged partitions or UBI.
This one now even further relies on a project-external UBI-conversion tool. So is this like a long-term UBI pilot platform? If so, will other plattforms someday also be UBI‘ed?
I am kinda perplexed on the path the devs chose regarding the reinventing of the wheel, aka conversion to UBI, in the first place for this device. However, from what I understand, this was the best way to get openwrt working on the RT3200/E8450. I have always liked the ability to revert back to stock on previous devices and there is a method to do this as described in the wiki provided you backup the factory firmware and partitioning table before conversion to UBI but it's not for the faint of heart.
Nope, it's actually kinda easy.
The reason for this move is explained here: https://openwrt.org/toh/linksys/e8450
Thank you, I think i got it now. Learned something. I have seen the wiki page countless times, but I always misses to click on the gitdiff link, which does explain it.
So basically:
- before: old slow driver was used, that one was compatible to flash format of manufacturer partition format and manufacturer images. THe old driver had defect management in the flash driver.
- 2021-08-27 a new more performant more low level flash driver was introduced. That driver is faster, but incompatible to the older flash low level cell addressing. New one also requires UBI layer on top, as now UBI does the cell defect management.
So switching from old to new driver now has side effects:
- Defect management now has to be taken over by UBI driver layer above that
- as the defect management layer is removed from the driver, the flash address layout changes, requiring all partition data to be rewritten
- A new different bootloader must be rewritten as well (am I right?)
As a minor side bonus, since the partition table had to be completely rewritten anyway, the 2 alternating firmware partitions got enlarged, to better use available flash space utilization.
So it was not the plain wish to just enlarge partitions that caused the migration pain, it was the driver architecture change that started it. And that change was due to performance reasons.
…So thats what the effort and script was all about.
4 Likes
@darksky Thanks again for maintaining this page.
I have no editor rights, but I do have some suggestions:
- add: install and enable irqbalance
- add: enable packet steering in global network options
- add: a word on colors for beam forming (btw, is there a way to find used colors on a given frequency?)
Thank you, I think i got it now. Learned something. I have seen the wiki page countless times, but I always misses to click on the gitdiff link, which does explain it.
So all older RT/Linksys OpenWRT firmware images had relied on using a flash driver that was slow, but compatible to the original flash driver from the manufacturer firmware images.
Performance really wasn't an issue with either of the three drivers for
MediaTek SPI-NAND.
The old driver did the defect management via some flash-persisted mapping table and indirection pointers, defect management handled in driver layer itself.
2021-08-27 a new more performant flash driver had been commited to the master. This new driver skips the pointer indirection to address flash, it works one layer lower and does not do defect management on driver level.
MediaTek's BMT is also supported with the new driver and also that
wasn't the reason for the switch. After all, the very same driver is
also used for other devices which do depend on BMT as the original
bootloader uses that.
That change now has side effects:
- Defect management now has to be taken over by UBI driver layer above that
Yes, that's correct. We use UBI instead of BMT (One can also use UBI
on top of BMT, though this can have unwanted side effects)
- as there is now no more indirect adressing on driver level, the old physical cell data addresses not longer matches the physical cell address expectations as used by the new driver. Thats why completely new partition data has to be written.
It's unlcear to me what you mean by this, probably this is a
misunderstanding about how flash memory is partitioned, see below.
- A new different bootloader must be rewritten as well (am I right?)
Yes, and this was also most of the original motivation to begin with: To
have a bootloader with a meaningful dual-boot scheme which actually
prevents soft-bricking the device. The vendor loader, despite supporting
an A/B dual-boot scheme, often ended up in a condition where the user
would have to connect the serial adapter to revive the device.
As a minor side bonus, since the partition table had to be completely rewritten anyway, the 2 alternating firmware partitions got enlarged, to better use available flash space.
There is no such a thing as a partition table on raw NAND flash. This
terminology only makes sense on block storage where we use MBR or GPT
partition table. On raw flash, the partitioning is defined in device
tree, ie. not stored on a fixed block of the flash memory itself.
So it was not the plain wish to just enlarge partitions that caused the migration pain, it was the driver architecture change that started it. And that change was due to performance reasons.
That's wrong. Performance has never been a significant factor in the
whole process.
…So thats what the effort and script was all about.
Not quite. My original intention was to have the option to replace the
bootloader for something 100% built from source, more robust and yet
also more flexible than the vendor's approach. Later on the change of
the NAND driver resulted in read errors of the 'factory' partition
which, because the ECC data in OOB area didn't match the new drivers
expectations. This problem initially affected both, the UBI and non-UBI
builds. However, as the UBI installer was already re-writing most of the
flash it was easy to also make it re-write the 'factory' partition to
fix the ECC errors.
This is why most users at this point switched to the UBI version because
also for using the non-UBI version one had to re-write the factory data
to get rid of the read errors and installation became non-trivial for
that reason.
6 Likes
I do not believe that irqbalance does anything the that the system isn't doing without it. Try looking are cat /proc/interrupts after some uptime without it then add it enabled it and repeat.
I may have missed something obvious, but when the UBI change became permanent did that drop the -ubi from the firmware image name?
I'm trying to go from 22.03.0 -> 22.03.2
On that same note, is there not something similar for updating to official releases like how we could use an updater within LUCI for snapshot versions?
No.
The "UBI" is still prominently in the ubi variant file names.
You have the wrong file.
https://downloads.openwrt.org/releases/22.03.2/targets/mediatek/mt7622/