This didn't help my (admittedly different) issue but have you confirmed you have the new wireless driver packages installed? See this post above.
Thank you for doing all that digging. I used some of your commands to dig through my setup and could this be the problem, I wonder?!
Seems to be missing the entire configuration for wl0-ap0, which is probably why hostapd can't configure it?
Thanks. My report was not in response to your issue. I have not installed other drivers or firmware as I am on the 22.03.3 release. The only reason I was mentioned OpenWrt SNAPSHOT r18646-3869ccbcc was to indicate that I am still on https://github.com/dangowrt/owrt-ubi-installer/releases/tag/v0.6.2.
1 Like
That was my assumption, that the IO error in your log was that there was a mismatch somewhere in the generated names and config files. (This is all just wild speculation, as I'm treading paths that are completely new to me here.)
I believe that if the /var/run/hostapd/wl1-ap0 device is named exactly the same as the device entry in /etc/config/network then that part is okay. But... The difference between your /var/run/hostapd-<phy>.conf and mine is what prompted me to search for where the <phy> part comes from, and I still can't seem to locate it in any config files (/etc or elsewhere). Closest hit is below, and that doesn't explain where it comes from.
/var/state/wireless:wireless._phy0='phy'
/var/state/wireless:wireless._phy0.aplist='wlan0 '
/var/state/wireless:wireless._phy0.md5='1993e33076733ba474efe82c3cb170cf /var/run/hostapd-phy0.conf'
1 Like
As I understand it, mine is named wl0-ap0 instead of wlan0 because I'm running the latest snapshot, which uses a different naming convention by default. But there very well could be a mismatched name somewhere since I upgraded from 22.03.3 stable. I've already deleted /etc/config/wireless and started over but it may be somewhere else.
EDIT: I found this in /var/state/wireless and as you can see there's nothing about wl0-ap0 (the 2.4Ghz radio). The trailing space in the 'wl-ap0 ' seems not to have any effect. I removed it and wl1-ap0 (the 5Ghz radio) still initialized
root@OpenWrt:~# cat /var/state/wireless
wireless._wl1='phy'
wireless._wl1.aplist='wl1-ap0 '
wireless._wl1.md5='43b32df140f4e6525991be00a516a0a5 /var/run/hostapd-wl1.conf'
Hang on, my /etc/config/network has no entries like this at all, not even ones that say wl0-ap0 like how my devices are named.
config device
option name 'wlan1'
config device
option name 'wlan0'
Can you share your entire /etc/config/network if possible, so I can compare?
That looks like it might be the culprit, those last two blocks were my starting point when searching for generated files in /var/run/...
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd00:f00f:d00d::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '64'
option ipaddr '10.1.2.1'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option peerdns '0'
list dns '127.0.0.1'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option reqaddress 'try'
option ip6assign '64'
option peerdns '0'
list dns '::1'
option reqprefix '64'
config device
option name 'wlan1'
config device
option name 'wlan0'
Thanks, mine is similar enough and adding the bottom two config device sections with my names didn't do anything.
Hi all, installed OpenWRT on my new RT3200 yesterday.
All is working beautifully except that I am getting WiFi slowdowns.
I'm using 802.11ax 160Mhz channel 100, and I get all 500 Mbps of my available Internet bandwidth until maybe half an hour has passed when it becomes capped at ~120 Mbps.
I can fix it by simply clicking Restart against the radio device in the Wireless settings page.
Does anyone know how to prevent this happening at all? Thanks!
What version of OpenWrt are you running?
Today the same thing happened on another one of my RT3200's, this time when playing about with setting up a VLAN and joining it with br-lan:
Fri Jan 20 19:07:24 2023 kern.warn kernel: [954728.414514] print_req_error: 27298 callbacks suppressed
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.414523] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.431782] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.442866] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.454816] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.465700] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.477537] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.488533] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.499529] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.510388] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.522233] blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Fri Jan 20 19:07:24 2023 kern.warn kernel: [954728.614610] buffer_io_error: 27397 callbacks suppressed
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.614618] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.628156] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.636091] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.643830] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.652651] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.660383] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:24 2023 kern.err kernel: [954728.669072] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:25 2023 kern.err kernel: [954728.676820] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:25 2023 kern.err kernel: [954728.684450] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Fri Jan 20 19:07:25 2023 kern.err kernel: [954728.692381] Buffer I/O error on dev mtdblock2, logical block 32, async page read
root@OpenWrt:~/cake-autorate# reboot
results in LuCi becoming inaccessible. Reboot of router fixes things again.
So it seems adjusting certain settings can result in a kind of broken state resulting in these massive sequences of Buffer I/O errors.
I'm using 22.03.3
A downgrade back to 22.03.2 might help. I know it's different hardware, but FWIW, it did for my EA8500.
All those errors relate to the mtdblock2 that is known to have no ecc info flashed by the OEM. Daniel's install script only fixes the small part that we use, and the unmodified parts give that error when read with the new flash driver (since fall 2021). But that should not be harmful, as those regions contain no usable info. They should have to relation to making your router inaccessible, (at least with wired, as mtdblock2 contains WiFi calibration).
However, I have hunch that a commit today in master might remove at least some of those errors. The bmt driver's error reporting us slightly changed, and I wishfully interpret that change as demoting some errors into debug messages.
3 Likes
Thanks. Doesn't it seem rather a coincidence though that I see these errors at the same time router becomes inaccessible from LuCi but accessible via SSH? In this state the router will keep spamming these errors until I reboot.
On another matter I also found a reliable way to trigger a crash by enabling vlan filtering in a certain way. I extracted those fs pstore files. Would it be useful for me to upload them and make them available here? If not I'll just delete them.
1 Like
Well, they might be useful if somebody who actually develops the VLAN filtering part wouldsee them, but most of the actual developers read the forum rarely 
Most of them are mailing list guys. You would get more appropriate attention by mailing the pstore files and explanation to openwrt-devel where the development related discussion happens.
Or naturally, you could file a proper bug at the bug tracker...
1 Like
Thanks. Coming back to the I/O errors, what explains that the router can get into a state where these keep getting spammed pending a reboot filling up the entire system log? Is it that something WiFi related tries to read from a portion and has no timeout or read attempt limit and so once it pops it just can't stop?
Sometimes in these devices I see segmentation fault when running logread. Restarting the log service fixes that. Not sure whether this is related.
Might be.
Likely it is not related.
System log is completely in RAM, a (too) small circular buffer there.
Logread has no relation to flash.
Been trying various permutations of settings. It seems that downgrading to 802.11ac solves the problem. So it seems like there's something wrong with ax support.
3 Likes