OpenWrt/LEDE Project

Welcome to the OpenWrt Project bug reporting and issue tracking system

Problems to be reported here are for the current OpenWrt and legacy LEDE Project’s targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to openwrt-bugs@infradead.org.

OpenedIDCategoryTask Type  ascPrioritySeveritySummaryReported InStatus
29.11.20214164Base systemBug ReportVery LowCriticalASUS RT-N56U reboots unexpectedly on OpenWrt 21.02.1openwrt-21.02Unconfirmed Task Description

Device the problem occurs on: Asus RT-N56U.

Software versions of OpenWrt/LEDE release, packages, etc.: the latest version of OpenWrt to date, 21.02.1. The previous one, OpenWrt 21.02, suffers from this problem as well. All packages are on their default versions for this releases, nothing has been updated.

Steps to reproduce:
1. Install OpenWrt 21.02.1 on Asus RT-N56U (version A1).
2. Either load the router with some heavy task or wait a day or so. In my case the router reboots when I’m trying to download a big file (e.g game or film) on the speed of 200 Mbits (which is the speed of my internet connection). Or it reboots randomly after somewhere like 24 hours of uptime. The best uptime I’ve got on this version of firmware was around 48 hours, so only 2 days.

Unfortunately, I’m not able to provide logs, as they are erased every time the router reboots, which happens exactly after the problem occurs. However, I might try to set up persistent logging, if it’s necessary.

Workaround: use OpenWrt 19.07, the oldstable version. The latest version at the moment is 19.07.8. I moved here from 21.02 and everything works fine so far. I had also used it for 1.5 years before 21.02 released, and had a very solid uptime then. Even if it has ever crashed, it was such a rare occurence I don’t remember it at all.

29.11.20214163Base systemBug ReportVery LowHighwrt1200ac - Unstable 5GHz after upgrading to OpenWrt 21...openwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on Linksys WRT1200AC
- Software versions of OpenWrt/LEDE release, packages, etc.

 OpenWrt 21.02.1, r16325-88151b8303

- Steps to reproduce - just upgrade to OpenWrt 21.02.1, r16325-88151b8303

 

More details https://github.com/kaloz/mwlwifi/issues/404


29.11.20214162PackagesBug ReportVery LowLowlibrt missing from ath79 21.20.0 but present in 21.20.1openwrt-21.02Unconfirmed Task Description

- Device: TP-Link Archer C6
- Software versions: 21.20.0 (fixed in 21.20.1), missing librt preventing nfs and other packages from installing
- Steps to reproduce: try installing nfs-utils on generic ath79 21.20.0, see the same not occuring on 21.20.1

 Merely updating the link for the installation to the updated 21.20.1 will save some people headaches: https://openwrt.org/toh/tp-link/archer_c6_v2 ... others based on 21.20.0 generic ath79 should probably be updated as well.


28.11.20214161Base systemBug ReportVery LowLowRTL838x: Netgear GS108T v3 - Ring contentionopenwrt-21.02Unconfirmed Task Description
Device problem occurs on:

Netgear GS108T v3

Software versions of OpenWrt/LEDE release, packages, etc.:

Release 21.01.1 + packages: collectd-mod-ping luci-app-statistics collectd-mod-uptime htop iperf3

Steps to reproduce:

Also posted in the OpenWRT forum: https://forum.openwrt.org/t/rtl838x-netgear-gs108t-v3-ring-contention/111421.

A switch (Netgear GS108T v3, 21.01.1) shows warnings in the log and drops packets aimed towards the device. Traffic entering a port and leaving another port is unaffected/fine, that is why i consider this a low prio issue, but a potential issue nevertheless:

Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.851532] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a700003c, cur a700004c
Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.866290] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a7000040, cur a700004c
Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.889970] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a7000044, cur a700004c
Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.969803] rtl838x-eth bb00a300.ethernet eth0: Ring 
...
Tue Nov  9 17:30:28 2021 kern.info kernel: [88234.247018] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:30:28 2021 kern.info kernel: [88234.252886] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:30:28 2021 kern.info kernel: [88234.258510] RX buffer overrun: status 1, mask: ffeff

The error just occurs after a while: Graph of Ping Log

The issue can be triggered by running iperf3:

iperf3 -c 192.168.xx.254 -t0
Connecting to host 192.168.xx.254, port 5201
[  5] local 192.168.xx.13 port 44924 connected to 192.168.xx.254 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.69 MBytes  39.2 Mbits/sec    0    233 KBytes       
[  5]   1.00-2.05   sec  2.75 MBytes  22.1 Mbits/sec    0    369 KBytes       
[  5]   2.05-3.26   sec  3.57 MBytes  24.7 Mbits/sec    0    533 KBytes       
[  5]   3.26-4.03   sec  1.12 MBytes  12.3 Mbits/sec    1    551 KBytes       
[  5]   4.03-5.00   sec  0.00 Bytes  0.00 bits/sec    1    551 KBytes       
[  5]   5.00-6.00   sec  1.11 MBytes  9.34 Mbits/sec    0    420 KBytes       
[  5]   6.00-7.00   sec  1.37 MBytes  11.5 Mbits/sec    0    451 KBytes       
...
[  5]  99.00-100.00 sec  0.00 Bytes  0.00 bits/sec    0   1.72 MBytes       
[  5] 100.00-101.00 sec  0.00 Bytes  0.00 bits/sec    0   1.72 MBytes       
^C[  5] 101.00-101.93 sec  0.00 Bytes  0.00 bits/sec    0   1.72 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-101.93 sec  66.2 MBytes  5.45 Mbits/sec    6             sender
[  5]   0.00-101.93 sec  0.00 Bytes  0.00 bits/sec                  receiver
iperf3: interrupt - the client has terminated

On a separate console the log shows this while iperf3 is active:

Tue Nov  9 17:49:50 2021 kern.info kernel: [  903.051213] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:50 2021 kern.info kernel: [  903.057182] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:50 2021 kern.info kernel: [  903.063026] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.937196] RX buffer overrun: status 101, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.943113] RX buffer overrun: status 1, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.948754] RX buffer overrun: status 1, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.954392] RX buffer overrun: status 101, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.960362] RX buffer overrun: status 101, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.966204] RX buffer overrun: status 1, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.056387] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.062297] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.067934] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.073570] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.079537] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.085384] RX buffer overrun: status 1, mask: ffeff

After terminating iperf3 the message changes and it remains as follows even though the high load situation is now gone:

Tue Nov  9 17:49:59 2021 kern.warn kernel: [  911.986238] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:49:59 2021 kern.warn kernel: [  911.996379] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.020755] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.030895] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.242054] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000d0, cur a70000d8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.258000] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000d4, cur a70000d8
Tue Nov  9 17:50:01 2021 kern.warn kernel: [  914.217759] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000e8, cur a70000ec
Tue Nov  9 17:50:01 2021 kern.warn kernel: [  914.227900] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000e8, cur a70000ec
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.623829] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.633968] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.830442] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.840583] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8

Traffic passing the switch from one port to another is not affected, it seems to pause traffic to eth0 for brief moments. To observe that a ping -A 192.168.xx.254 can be used.

It is surprising, that the device enters a state where it is loosing packets, even if high traffic stops and remains in this poor state.

Thank you for reading.

27.11.20214160Base systemBug ReportVery LowMediumLeaking host IP addresses to unrelated dnsmasq instance...AllUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
All openWRT devices with version 20+. Tested on raspberry pi, x86_64 and xiaomi mi aiot router

- Software versions of OpenWrt/LEDE release, packages, etc.
Multiple, including snapshot r18191-b92a9f607b

- Steps to reproduce
1. Create multiple dnsmasq instances by creating ‘main’ and ‘guest’ configs in /etc/config/dhcp
2. in the ‘main’ instance, create static host, set the option ‘dns’ to ‘1’ and the option ‘instance’ to ‘main’ 3. restart the dnsmasq
4. both dnsmasq instances will run, but they will include configuration option “addn-hosts /tmp/hosts” 5. the file /tmp/hosts/dhcp.guest will have no static records, the /tmp/hosts/dhcp.main will have the record from step 2
6. connect to the guest network, try to resolve the record from step 2 (e.g. server.mainlan)

Problem: the resolver will work as the addn-hosts folder is shared with both instances. This “leaks” the dns responses to the guest lan from the main lan and vice-versa, despite this is not wanted.
I created a pull request with dirty workaround - changed the HOSTFILE variable in a way that it will create a separate directory (/tmp/hosts/dhcp/main/main and /tmp/hosts/dhcp/guest/guest), working around the problem - no more shared folders.

27.11.20214159Base systemBug ReportVery LowHighhostapd-common update breaks WiFi completely when using...openwrt-21.02Unconfirmed Task Description

- Device problem occurs on

Linksys EA8300 AC2200 (advanced WiFi config - 802.11r related settings and a lots of other advanced settings are also modified compared to the default)
Raspberry Pi 4B+ (simple WiFi config - only SSID and password settings are modified)

- Software versions of OpenWrt/LEDE release, packages, etc.

Linksys EA8300: 21.02
Raspberry Pi 4B+: 21.02.1

- Steps to reproduce

`opkg upgrade hostapd-common`

It happened for me when I upgraded to 2020-06-08-5a8b3662-35 (the current latest release published on 2021-11-25) from the previous version or the one before that, I don’t exactly know, but I’m sure that I kept my packages up-to-date on a weekly basis recently, so my previous version cannot be older than 7 days.

I’ve got this error message in the system log on both of my devices:

Sat Nov 27 16:05:40 2021 daemon.notice netifd: radio0 (10527): command failed: No error information (-524)
Sat Nov 27 16:05:40 2021 daemon.notice netifd: radio0 (10527): command failed: I/O error (-5)
Sat Nov 27 16:05:41 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) –> new PHY
Sat Nov 27 16:05:41 2021 daemon.err hostapd: Line 47: unknown configuration item ‘snoop_iface’ Sat Nov 27 16:05:41 2021 daemon.err hostapd: Line 54: unknown configuration item ‘vlan_no_bridge’ Sat Nov 27 16:05:41 2021 daemon.err hostapd: Line 56: unknown configuration item ‘qos_map_set’ Sat Nov 27 16:05:41 2021 daemon.err hostapd: 3 errors found in configuration file ‘/var/run/hostapd-phy0.conf’ Sat Nov 27 16:05:41 2021 daemon.err hostapd: Failed to set up interface with /var/run/hostapd-phy0.conf
Sat Nov 27 16:05:41 2021 daemon.notice netifd: radio0 (10527): Command failed: Invalid argument
Sat Nov 27 16:05:41 2021 daemon.notice netifd: radio0 (10527): Device setup failed: HOSTAPD_START_FAILED
Sat Nov 27 16:05:41 2021 daemon.notice netifd: Wireless device ‘radio0’ set retry=0
Sat Nov 27 16:05:41 2021 daemon.crit netifd: Wireless device ‘radio0’ setup failed, retry=0
Sat Nov 27 16:05:42 2021 daemon.notice netifd: Wireless device ‘radio0’ is now down

27.11.20214158KernelBug ReportVery LowCriticalMaster regression - boot loop due to kernel panic (mt76...TrunkUnconfirmed Task Description

I just did a build yesterday for the Archer C6 v3.2 from master, and now it is not booting anymore due to a boot loop issue (kernel panic).

Running OpenWRT SNAPSHOT custom build from master (r18195-d1c7df9c4b)

To reproduce, just install the build and reboot the device.

Attaching a UART I can see the kernel panic error below:

(...)
[    0.797651] CPU 1 Unable to handle kernel paging request at virtual address 5050404, epc == 80588ef8, ra == 801fe360
[    0.808162] Oops[#1]:
[    0.810387] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.159 #0
[    0.816345] $ 0   : 00000000 00000001 8fc304a4 00000108
[    0.821525] $ 4   : 05050404 80621000 8064d18f 00000061
[    0.826712] $ 8   : fffffffc 80594b3c 00000045 006d6873
[    0.831893] $12   : 015ede76 08fca8f3 9715a5ed 5c2e1039
[    0.837079] $16   : 8ff9cc00 8fc2523c 05050404 8064d184
[    0.842261] $20   : 0000000b 8fc06e00 8ff9cc8c 806ebd24
[    0.847448] $24   : 00000010 76ec2f43
[    0.852629] $28   : 8fc40000 8fc41d50 38e38e39 801fe360
[    0.857816] Hi    : 00000000
[    0.860665] Lo    : 006c0400
[    0.863546] epc   : 80588ef8 strlen+0x0/0x2c
[    0.867771] ra    : 801fe360 insert_header+0x140/0x4f8
[    0.872847] Status: 11007c03 KERNEL EXL IE
[    0.876997] Cause : 40800008 (ExcCode 02)
[    0.880969] BadVA : 05050404
[    0.883821] PrId  : 0001992f (MIPS 1004Kc)
[    0.887882] Modules linked in:
[    0.890910] Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), ts=00000000)
[    0.898940] Stack : 08fca8f3 00000000 2ab4a599 00000dc0 00000000 8fc06e30 8f06e00 801fc880
[    0.907235]         80862190 00000000 00000000 8fe57007 00000000 8ff9cc00 8f06e00 80860000
[    0.915528]         8fc06e00 00000001 00000000 801feaec 806f0000 80830000 8024aec 00000000
[    0.923822]         8064d008 8fd64a00 806eb18c 8fc06e00 8063ab2c 8063ab50 0000001 8fc06e00
[    0.932118]         8fe57007 806ebc4c 8fe57000 806ebc04 00000001 806eb18c 8030000 80830000
[    0.940412]         ...
[    0.942832] Call Trace:
[    0.945261] [<80588ef8>] strlen+0x0/0x2c
[    0.949146] [<801fe360>] insert_header+0x140/0x4f8
[    0.953897] [<801feaec>] __register_sysctl_table+0x30c/0x630
[    0.959516] [<801ff154>] __register_sysctl_paths+0xf4/0x1e8
[    0.965067] [<8070de10>] ipc_sysctl_init+0x14/0x24
[    0.969793] [<800015c8>] do_one_initcall+0x50/0x1a8
[    0.974641] [<806fbeec>] kernel_init_freeable+0x1ec/0x2d0
[    0.979997] [<80594e78>] kernel_init+0x10/0xf8
[    0.984398] [<80006478>] ret_from_kernel_thread+0x14/0x1c
[    0.989755] Code: a066ffff  1000fff7  00000000 <80820000> 10400007  00000000 00801025  80430001  1460fffe
[    0.999424]
[    1.000995] ---[ end trace d1818afedd9795ac ]---
```

Reverting to a build I did a couple of weeks ago (also from master) solves the problem.

I believe I have already identified the root cause.

It seems that the amount of RAM memory sometimes is not correctly identified. When the boot fails, the boot loader seems to be identifying a “HighMem” memory that does not exist in this device:

Wrong HighMem Memory Detected causes Kernel Panic during boot:

(...)
[    0.000000] MIPS secondary cache 256kB, 8-way, linesize 32 bytes.
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x000000000fffffff]
[    0.000000]   HighMem  [mem 0x0000000010000000-0x0000000023ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000001bffffff]
[    0.000000]   node   0: [mem 0x0000000020000000-0x0000000023ffffff]
(...)
[    0.000000] Memory: 510004K/524288K available (5739K kernel code, 200K rwdata, 1196K rodata, 1236K init, 226K bss, 14284K reserved, 0K cma-reserved, 262144K highmem)

Per log above the identified amount of RAM memory is 512MB, when in fact this device has only 128MB of RAM. When the above situation happens the boot fails with kernel panic.

After a couple of power cycles, the memory is correctly identified as 128MB (no HighMem) per below and the device boots OK:

Correct Memory Size Detected boots OK:

(...)
[    0.000000] MIPS secondary cache 256kB, 8-way, linesize 32 bytes.
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
(...)
[    0.000000] Memory: 120916K/131072K available (5739K kernel code, 200K rwdata, 1196K rodata, 1236K init, 226K bss, 10156K reserved, 0K cma-reserved, 0K highmem)
(...)

Full log is attached.

25.11.20214156KernelBug ReportVery LowLowenable CONFIG_NF_CT_NETLINK_* in kernelTrunkUnconfirmed Task Description

The following options seems to be missing in trunk kernels of OpenWRT:
CONFIG_NF_CT_NETLINK_HELPER = m
CONFIG_NF_CT_NETLINK_TIMEOUT = m

There are no drawback (that I’m aware of) of adding them to OpenWRT builds. Can they be added using this ticket or a PR must must be created in order to do so?

Best regards,
Adam

25.11.20214155PackagesBug ReportVery LowMedium<dnsmasq_2.86-10_aarch64_cortex-a53.ipk>: unable to sta...TrunkUnconfirmed Task Description

Linksys e8450 on OpenWrt SNAPSHOT, r18161-00ce13490a

A bug in dnsmasq 2.86-10 would render the whole DHCP system down. Once you modify the /etc/dnsmasq.conf with additional line:

conf-dir=/etc/dnsmasq.d/

Your dnsmasq will refuse to start

Workaround: Add following lines to /etc/config/dhcp to bypass this bug:
option confdir ‘/etc/dnsmasq.d/’

This workaround will change the default behavior which dnsmasq was including the conf files in the /tmp/dnsmasq.d
And I’m not sure if the option confdir ‘/etc/dnsmasq.d/’ actually works.

The dnsmasq 2.85-8 package shipped with 21.02.1 has no such bug.

24.11.20214154Base systemBug ReportVery LowLowprocd-ujail: makes dnsmasq refuse to answer dns queriesTrunkUnconfirmed Task Description

22/11/2021 compile for ramips device Ubiquiti EdgeRouter X sfp ; snapshot: r18166-e2c4998f6d
Choosing TARGET_ramips_mt7621_DEVICE_ubnt_edgerouter-x-sfp selects default the inclusion of procd-ujail .
This has the effect of dnsmasq being put in a jail.
The device can still make dns queries to upstream. But, depite dnsmasq listening on all interfaces, any incoming queries get the reply ‘REFUSED’. Easily tested on the device itself e.g. with the command ‘nslookup <some fqdn> localhost’ This leaves any devices downstream in the dark that via dhcp got the news to fetch their dns information from this jailed dnsmasq.
Exactly same configuration compile, but with procd-ujail manually removed, restores complete functionality of dnsmasq.


23.11.20214153Base systemBug ReportVery LowLowap + sta wpa_supplicant fail to connect if wrong configTrunkUnconfirmed Task Description

1. setup wireless AP + STA, and STA connect ok
2. change /etc/config/wireless and set the STA password key to ‘’ then /etc/init.d/network reload
3. again change /etc/config/wireless and set STA password key to the correct password
4. /etc/init.d/network reload, STA would never works again.

logread:

Tue Nov 23 19:53:49 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-DISCONNECTED bssid=bc:1a:e4:3f:77:74 reason=3 locally_generated=1
Tue Nov 23 19:53:49 2021 daemon.err wpa_supplicant[1876]:  Failed to stop hostapd AP interfaces
Tue Nov 23 19:53:49 2021 daemon.err wpa_supplicant[1876]:  Failed to stop hostapd AP interfaces
Tue Nov 23 19:53:49 2021 daemon.notice wpa_supplicant[1876]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Line 8: Invalid passphrase length 0 (expected: 8..63) '"'.
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Line 8: failed to parse psk '""'.
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Line 11: failed to parse network block.
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Failed to read or parse configuration '/var/run/wpa_supplicant-wlan0.conf'.
Tue Nov 23 19:53:54 2021 daemon.notice netifd: radio0 (7740): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process  path (/proc/exe)
Tue Nov 23 19:54:44 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Tue Nov 23 19:54:45 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Tue Nov 23 19:54:46 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Tue Nov 23 19:54:48 2021 daemon.notice wpa_supplicant[1876]: wlan0: SME: Trying to authenticate with bc:1a:e4:3f:77:74 (SSID='HUAWEI-E101QX' freq=2462 MHz)
Tue Nov 23 19:54:48 2021 daemon.notice wpa_supplicant[1876]: wlan0: SME: Authentication request to the driver failed
Tue Nov 23 19:54:49 2021 daemon.notice wpa_supplicant[1876]: wlan0: SME: Trying to authenticate with bc:1a:e4:3f:77:74 (SSID='HUAWEI-E101QX' freq=2462 MHz)
Tue Nov 23 19:54:49 2021 daemon.notice wpa_supplicant[1876]: wlan0: Trying to associate with bc:1a:e4:3f:77:74 (SSID='HUAWEI-E101QX' freq=2462 MHz)
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: Associated with bc:1a:e4:3f:77:74
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: Unknown event 37
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: WPA: Key negotiation completed with bc:1a:e4:3f:77:74 [PTK=CCMP GTK=CCMP]
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-CONNECTED - Connection to bc:1a:e4:3f:77:74 completed [id=0 id_str=]
Tue Nov 23 19:54:51 2021 daemon.notice wpa_supplicant[1876]: wlan0: Unknown event 37
Tue Nov 23 20:00:58 2021 daemon.notice wpa_supplicant[1876]: CTRL_IFACE: Detach monitor that cannot receive messages: /var/run/iwinfo-wlan0-1581\x00
Tue Nov 23 20:03:17 2021 daemon.notice wpa_supplicant[1876]: CTRL_IFACE: Detach monitor that cannot receive messages: /var/run/iwinfo-wlan0-1581\x00
Tue Nov 23 20:06:48 2021 daemon.notice wpa_supplicant[1876]: CTRL_IFACE: Detach monitor that cannot receive messages: /var/run/iwinfo-wlan0-10082\x00
23.11.20214152Base systemBug ReportVery LowLowap + sta wpa_supplicant fail to connect if wrong configTrunkUnconfirmed Task Description

1. setup wireless AP + STA, and STA connect ok
2. change /etc/config/wireless and set the STA password key to '' then /etc/init.d/network reload
3. again change /etc/config/wireless and set STA password key to the correct password
4. /etc/init.d/network reload, STA would never works again.

logread:

Tue Nov 23 19:53:49 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-DISCONNECTED bssid=bc:1a:e4:3f:77:74 reason=3 locally_generated=1
Tue Nov 23 19:53:49 2021 daemon.err wpa_supplicant[1876]:  Failed to stop hostapd AP interfaces
Tue Nov 23 19:53:49 2021 daemon.err wpa_supplicant[1876]:  Failed to stop hostapd AP interfaces
Tue Nov 23 19:53:49 2021 daemon.notice wpa_supplicant[1876]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Line 8: Invalid passphrase length 0 (expected: 8..63) '"'.
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Line 8: failed to parse psk '""'.
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Line 11: failed to parse network block.
Tue Nov 23 19:53:54 2021 daemon.err wpa_supplicant[1876]: Failed to read or parse configuration '/var/run/wpa_supplicant-wlan0.conf'.
Tue Nov 23 19:53:54 2021 daemon.notice netifd: radio0 (7740): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process  path (/proc/exe)
Tue Nov 23 19:54:44 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Tue Nov 23 19:54:45 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Tue Nov 23 19:54:46 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-16 retry=1
Tue Nov 23 19:54:48 2021 daemon.notice wpa_supplicant[1876]: wlan0: SME: Trying to authenticate with bc:1a:e4:3f:77:74 (SSID='HUAWEI-E101QX' freq=2462 MHz)
Tue Nov 23 19:54:48 2021 daemon.notice wpa_supplicant[1876]: wlan0: SME: Authentication request to the driver failed
Tue Nov 23 19:54:49 2021 daemon.notice wpa_supplicant[1876]: wlan0: SME: Trying to authenticate with bc:1a:e4:3f:77:74 (SSID='HUAWEI-E101QX' freq=2462 MHz)
Tue Nov 23 19:54:49 2021 daemon.notice wpa_supplicant[1876]: wlan0: Trying to associate with bc:1a:e4:3f:77:74 (SSID='HUAWEI-E101QX' freq=2462 MHz)
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: Associated with bc:1a:e4:3f:77:74
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: Unknown event 37
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: WPA: Key negotiation completed with bc:1a:e4:3f:77:74 [PTK=CCMP GTK=CCMP]
Tue Nov 23 19:54:50 2021 daemon.notice wpa_supplicant[1876]: wlan0: CTRL-EVENT-CONNECTED - Connection to bc:1a:e4:3f:77:74 completed [id=0 id_str=]
Tue Nov 23 19:54:51 2021 daemon.notice wpa_supplicant[1876]: wlan0: Unknown event 37
Tue Nov 23 20:00:58 2021 daemon.notice wpa_supplicant[1876]: CTRL_IFACE: Detach monitor that cannot receive messages: /var/run/iwinfo-wlan0-1581\x00
Tue Nov 23 20:03:17 2021 daemon.notice wpa_supplicant[1876]: CTRL_IFACE: Detach monitor that cannot receive messages: /var/run/iwinfo-wlan0-1581\x00
Tue Nov 23 20:06:48 2021 daemon.notice wpa_supplicant[1876]: CTRL_IFACE: Detach monitor that cannot receive messages: /var/run/iwinfo-wlan0-10082\x00
22.11.20214150Base systemBug ReportVery LowLow./script/feeds does not return error on failureTrunkUnconfirmed Task Description

Hello,

Script feeds always returns 0, no matter if it did what it was asked to or not

$ ./scripts/feeds install foobar && echo ok || echo err
WARNING: No feed for package 'foobar' found
ok


22.11.20214149ToolchainBug ReportVery LowHighbinutils: unable to build toolchain with v2.37TrunkUnconfirmed Task Description

Summary: Building from master for ipq806x or for ramips targets on Arch Linux results getting a fatal error building the toolchain occurring on binutils. The bug has been reported and confirmed by other users. Additionally, it has been reported against binutils upstream.

Here is a sample output trying to build on my machine.

Proposed action: Revert this commit to binutils updating it from 2.35.2 to 2.37 until the issue is fixed. Doing this restores functionality.

22.11.20214147PackagesBug ReportVery LowMediumkmod-skge driver not included in the base system on x86...openwrt-21.02Unconfirmed Task Description

openwrt-21.02.1-x86-64-generic-ext4-combined.img doesn’t include the kmod-skge package preinstalled. It needs to be manually installed.

skge is the driver used for the following gigabit NIC:

04:05.0 Ethernet controller [0200]: D-Link System Inc Gigabit Ethernet Adapter [1186:4c00] (rev 11)


22.11.20214146KernelBug ReportVery LowCriticale1000e: Detected Hardware Unit Hang, Reset adapter unex...openwrt-21.02Unconfirmed Task Description

System is a Fujitsu Esprimo C5731 with Intel Core2Duo E7500 and 4 GB RAM.

The problem NIC:

00:19.0 Ethernet controller [0200]: Intel Corporation 82567LF-3 Gigabit Network Connection [8086:10df] (rev 02)

Openwrt:
OpenWrt x86_64 21.02.1 r16325-88151b8303

System is configured as a simple router with the e1000e NIC as WAN and a skge NIC [Ethernet controller [0200]: D-Link System Inc Gigabit Ethernet Adapter [1186:4c00] (rev 11)] as LAN.
When doing a speedtest through the router (bredbandskollen.se) the hang occurs during the upload test (when the e1000e NIC sends data and the skge NIC receives data). The download test does not cause the error.

Similar (identical?) problems were reported previously:
https://serverfault.com/questions/616485/e1000e-reset-adapter-unexpectedly-detected-hardware-unit-hang https://serverfault.com/questions/193114/linux-e1000e-intel-networking-driver-problems-galore-where-do-i-start https://web.archive.org/web/20160205153351/http://ehc.ac:80/p/e1000/bugs/378/

Turning TSO off is a workaround.

ethtool -K eth0 tso off

but pcie_aspm=off does not help.

[49573.954931] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[49573.954931]   TDH                  <2>
[49573.954931]   TDT                  <1a>
[49573.954931]   next_to_use          <1a>
[49573.954931]   next_to_clean        <ff>
[49573.954931] buffer_info[next_to_clean]:
[49573.954931]   time_stamp           <100bbf478>
[49573.954931]   next_to_watch        <2>
[49573.954931]   jiffies              <100bbf6f8>
[49573.954931]   next_to_watch.status <0>
[49573.954931] MAC Status             <80083>
[49573.954931] PHY Status             <796d>
[49573.954931] PHY 1000BASE-T Status  <3800>
[49573.954931] PHY Extended Status    <3000>
[49573.954931] PCI Status             <10>
[49575.970909] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[49575.970909]   TDH                  <2>
[49575.970909]   TDT                  <1a>
[49575.970909]   next_to_use          <1a>
[49575.970909]   next_to_clean        <ff>
[49575.970909] buffer_info[next_to_clean]:
[49575.970909]   time_stamp           <100bbf478>
[49575.970909]   next_to_watch        <2>
[49575.970909]   jiffies              <100bbf8f0>
[49575.970909]   next_to_watch.status <0>
[49575.970909] MAC Status             <80083>
[49575.970909] PHY Status             <796d>
[49575.970909] PHY 1000BASE-T Status  <3800>
[49575.970909] PHY Extended Status    <3000>
[49575.970909] PCI Status             <10>
[49577.954909] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[49577.954909]   TDH                  <2>
[49577.954909]   TDT                  <1a>
[49577.954909]   next_to_use          <1a>
[49577.954909]   next_to_clean        <ff>
[49577.954909] buffer_info[next_to_clean]:
[49577.954909]   time_stamp           <100bbf478>
[49577.954909]   next_to_watch        <2>
[49577.954909]   jiffies              <100bbfae0>
[49577.954909]   next_to_watch.status <0>
[49577.954909] MAC Status             <80083>
[49577.954909] PHY Status             <796d>
[49577.954909] PHY 1000BASE-T Status  <3800>
[49577.954909] PHY Extended Status    <3000>
[49577.954909] PCI Status             <10>
[49578.082559] e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
[49578.254005] e1000e: eth0 NIC Link is Down
[49581.083429] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
21.11.20214145PackagesBug ReportVery LowLowopkg full disk corrupts installed package listTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: x86 ext4-combined compiled with glib2
- opkg version 2021-06-13-1bf042dd-1
- Steps to reproduce

 1. Boot a fresh install of x86 without growing the image to a reasonable size.
 2. Attempt to run `opkg update && opkg install gst1-plugins-{bad,good,ugly}`
 3. Run `opkg list-installed | grep kernel` and note the empty result.

Any future attempts to install kmods will cause dependency errors because the kernel package will no longer show up in the installed package list.

I assume this is because opkg attempts to re-write the package list to disk and fails midway through due to a full disk.

21.11.20214144Base systemBug ReportVery LowLowRaspberry Pi Zero W | wifi adhoc not working with HT20 ...TrunkUnconfirmed Task Description

Just for documenting the issue for others:

tested with r18155 (2021-nov-21) the wifi interface
does not come up in adhoc mode when HT20 is enabled.

uci set wireless.radio0.htmode=HT20
wifi
⇒ not working

uci del wireless.radio0.htmode
wifi
⇒ OK/working

The relevent log collected with /lib/netifd/wireless/mac80211.sh
is here, it fails at the last ‘iw’ call:

rc:244 | iw dev wlan0 del
command failed: No error information (-524)
rc:0 | iw phy0 info
rc:0 | iw reg get
rc:0 | iw reg set US
rc:161 | iw phy phy0 set antenna 0xffffffff 0xffffffff
command failed: Not supported (-95)
rc:161 | iw phy phy0 set antenna_gain 0
command failed: Not supported (-95)
rc:251 | iw phy phy0 set distance 0
command failed: I/O error (-5)
rc:251 | iw phy phy0 set txpower fixed 2300
command failed: I/O error (-5)
rc:233 | iw phy phy0 interface add wlan0 type adhoc
command failed: Too many open files in system (-23)
rc:233 | iw phy phy0 interface add wlan0 type adhoc
command failed: Too many open files in system (-23)
rc:0 | iw dev wlan0 info
rc:244 | iw dev wlan0 del
command failed: No error information (-524)
rc:0 | iw dev wlan0 set type ibss
rc:234 | iw dev wlan0 ibss join ffintern.2GHz 2432 HT20 fixed-freq 02:ca:ff:ee:ba:be beacon-interval 250 mcast-rate 6
command failed: Invalid argument (-22)

without HT20 mode enabled:

[...]
rc:0 | iw dev wlan0 set type ibss
rc:0 | iw dev wlan0 ibss join ffintern.2GHz 2432 fixed-freq 02:ca:ff:ee:ba:be beacon-interval 250 mcast-rate 6

removing mcast-rate or beacon-interval does not change the behavior.

21.11.20214143Base systemBug ReportVery LowLowImage check failed TL-WR1043ND v4openwrt-21.02Unconfirmed Task Description

Device: TPLink TL-WR1043ND(EU)Ver:4.0

The device is running custom-built 19.07.3 (r11182-5af8da3787) openwrt-ar71xx-generic-tl-wr1043nd-v4-squashfs-factory.bin image.

I want to flash custom built 21.02.1 (r16325-88151b8303) openwrt-ath79-generic-tplink_tl-wr1043nd-v4-squashfs-sysupgrade.bin,
but get “Image check failed” error.

Opening this ticket as per https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79#if_your_device_is_not_supported_by_the_image

The output of sysupgrade looks like this:

# sysupgrade -n /tmp/openwrt-ath79-generic-tplink_tl-wr1043nd-v4-squashfs-sysupgrade.bin
Invalid image, hardware ID mismatch, hw:10430004 00000001 image:10430004 00000000.
Image check failed.

18.11.20214141KernelBug ReportVery LowLowWifi unstable Kernel warning in mac80211/rate.copenwrt-21.02Unconfirmed Task Description

Wifi unstable Kernel warning in mac80211/rate.c

Is this related to https://patchwork.kernel.org/project/linux-wireless/patch/20180117101405.16700-1-nbd@nbd.name/

Name the tree/revision/version = 21.02.1 and 21.02.2
Name the affected device = WDR4900 4 units all the same
What does it do that it should not do / what does it not do that it should do = Wifi becomes unstable fails and restarts with error shown
Steps to reproduce = leave it on for a couple of days
What you have already done to workaround/fix the problem = Revert to v19

————[ cut here ]———— [723741.978905] WARNING: CPU: 0 PID: 0 at backports-5.10.68-1/net/mac80211/rate.c:677 0xc9636ea0 [mac80211@880b69f1+0xa2660]
[723741.989848] Modules linked in: tun ath9k ath9k_common xt_connlimit pppoe ppp_async nf_conncount iptable_nat ath9k_hw ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT wireguard pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_netlink nf_conntrack mac80211 libchacha20poly1305 libblake2s ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY slhc sch_cake nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libpoly1305 libcurve25519_generic libchacha libblake2s_generic iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport
[723741.989980] ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb ip6_udp_tunnel udp_tunnel kpp gpio_keys leds_gpio fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd button_hotplug input_core usbcore usb_common
[723742.120347] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.154 #0
[723742.126256] NIP: c9636ea0 LR: c9594104 CTR: c006d108
[723742.131385] REGS: c7ff5ca8 TRAP: 0700 Not tainted (5.4.154)
[723742.137292] MSR: 00029000 <CE,EE,ME> CR: 48048882 XER: 00000000
[723742.143555]
[723742.143555] GPR00: 00000000 c7ff5d60 c068ba40 00000100 ffffffff 000000c7 00000001 00000001
[723742.143555] GPR08: 0000000a c448ae58 000007c6 c47583e0 88044482 00000000 c068fcac c0690000
[723742.143555] GPR16: 00200002 00000000 c06b0000 c05b1b04 00000009 00000000 fffff000 00000001
[723742.143555] GPR24: c3914cf8 00000000 c4480130 c4a3b708 c3914cf8 00000004 c448ae58 c47583c0
[723742.178843] Call Trace:
[723742.181368] [c7ff5d60] [c7ff5d64] 0xc7ff5d64 (unreliable)
[723742.186847] [c7ff5dd0] [c95940c4] 0xc95940c4 [ath9k@814d09d6+0x1f4f8]
[723742.193368] [c7ff5e10] [c958b980] 0xc958b980 [ath9k@814d09d6+0x1f4f8]
[723742.199890] [c7ff5e50] [c96498fc] 0xc96498fc [mac80211@880b69f1+0xa2660]
[723742.206671] [c7ff5e90] [c9649ae0] 0xc9649ae0 [mac80211@880b69f1+0xa2660]
[723742.213453] [c7ff5eb0] [c96518e4] 0xc96518e4 [mac80211@880b69f1+0xa2660]
[723742.220235] [c7ff5f10] [c96535bc] 0xc96535bc [mac80211@880b69f1+0xa2660]
[723742.227013] [c7ff5f60] [c002e6e0] 0xc002e6e0
[723742.231361] [c7ff5f90] [c05a9d3c] 0xc05a9d3c
[723742.235709] [c7ff5ff0] [c000d294] 0xc000d294
[723742.240058] [c06afe88] [c00057b8] 0xc00057b8
[723742.244405] [c06afea8] [c000f4ac] 0xc000f4ac
[723742.248754] — interrupt: 501 at 0xc00084e8
[723742.248754] LR = 0xc00084e8
[723742.256312] [c06aff70] [c0054c00] 0xc0054c00 (unreliable)
[723742.261790] [c06aff80] [c0052c6c] 0xc0052c6c
[723742.266138] [c06affa0] [c0052de4] 0xc0052de4
[723742.270485] [c06affb0] [c0660ae4] 0xc0660ae4
[723742.274833] [c06afff0] [c000038c] 0xc000038c
[723742.279178] Instruction dump:
[723742.282227] 40820010 891f002d 71080040 40820054 7f9d3800 40bdfe44 39290003 4bfffde4
[723742.290061] 54c6073e 2b86000a 38c00001 7cc0371e <0f060000> 7f9d3800 40bdfe20 39290003
[723742.298068] —[ end trace 2b9045ebeb5ab14c ]—

 


17.11.20214140PackagesBug ReportVery LowMediumumdns does not respect legacy queries (not from port 53...TrunkUnconfirmed Task Description

According to Section 6.7 of the RFC, if the query was sent not from port 5353, the responder MUST respond over unicast and, most importantly, to the same port that the query was sent from.

This is what currently prevents

dig -p 5353 @224.0.0.251 <hostname>

from working, since dig is expecting the response on the random port it sent its query from, but umdns, contrary to the specifiation, always sends to port 5353.

17.11.20214139PackagesBug ReportVery LowLowiwlwifi: Microcode SW error detected.TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

X64 Proxmox (qemu) VM

- Software versions of OpenWrt/LEDE release, packages, etc.

Linux OpenWrt 5.4.154 #0 SMP Sun Oct 24 09:01:35 2021 x86_64 GNU/Linux
OpenWrt 21.02.1, r16325-88151b8303
kmod-iwlwifi - 5.4.154+5.10.68-1-1
iwlwifi-firmware-iwl8260c - 20201118-3

- Steps to reproduce

Have configured both AP and STA yesterday. This worked for several hours since, but crashed overnight.

[18211.488837] iwlwifi 0000:00:10.0: Queue 10 is active on fifo 1 and stuck for 10000 ms. SW [119, 54] HW [119, 54] FH TRB=0x0c011107a
[18211.493968] iwlwifi 0000:00:10.0: Microcode SW error detected.  Restarting 0x2000000.
[18211.496629] iwlwifi 0000:00:10.0: Start IWL Error Log Dump:
[18211.498455] iwlwifi 0000:00:10.0: Status: 0x00000040, count: 6
[18211.500301] iwlwifi 0000:00:10.0: Loaded firmware version: 36.ad812ee0.0 8000C-36.ucode
[18211.502497] iwlwifi 0000:00:10.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
[18211.504528] iwlwifi 0000:00:10.0: 0x000000E3 | trm_hw_status0
[18211.507031] iwlwifi 0000:00:10.0: 0x00000000 | trm_hw_status1
[18211.509576] iwlwifi 0000:00:10.0: 0x0002438C | branchlink2
[18211.511743] iwlwifi 0000:00:10.0: 0x00039C06 | interruptlink1
[18211.514053] iwlwifi 0000:00:10.0: 0x00004B86 | interruptlink2
[18211.516209] iwlwifi 0000:00:10.0: 0x00000000 | data1
[18211.518231] iwlwifi 0000:00:10.0: 0x00000080 | data2
[18211.519939] iwlwifi 0000:00:10.0: 0x07830000 | data3
[18211.521507] iwlwifi 0000:00:10.0: 0x26404625 | beacon time
[18211.523079] iwlwifi 0000:00:10.0: 0xE8E669DE | tsf low
[18211.524473] iwlwifi 0000:00:10.0: 0x0000000C | tsf hi
[18211.525970] iwlwifi 0000:00:10.0: 0x00000000 | time gp1
[18211.527540] iwlwifi 0000:00:10.0: 0xEF89D2A4 | time gp2
[18211.528932] iwlwifi 0000:00:10.0: 0x00000001 | uCode revision type
[18211.530420] iwlwifi 0000:00:10.0: 0x00000024 | uCode version major
[18211.532032] iwlwifi 0000:00:10.0: 0xAD812EE0 | uCode version minor
[18211.533568] iwlwifi 0000:00:10.0: 0x00000201 | hw version
[18211.534925] iwlwifi 0000:00:10.0: 0x00489008 | board version
[18211.536486] iwlwifi 0000:00:10.0: 0x116B001C | hcmd
[18211.537928] iwlwifi 0000:00:10.0: 0x02E62002 | isr0
[18211.539310] iwlwifi 0000:00:10.0: 0x01800000 | isr1
[18211.540638] iwlwifi 0000:00:10.0: 0x08001812 | isr2
[18211.541981] iwlwifi 0000:00:10.0: 0x0041F480 | isr3
[18211.543396] iwlwifi 0000:00:10.0: 0x00000000 | isr4
[18211.544817] iwlwifi 0000:00:10.0: 0x116A001C | last cmd Id
[18211.546303] iwlwifi 0000:00:10.0: 0x00000000 | wait_event
[18211.547699] iwlwifi 0000:00:10.0: 0x00004988 | l2p_control
[18211.549094] iwlwifi 0000:00:10.0: 0x00009C20 | l2p_duration
[18211.550572] iwlwifi 0000:00:10.0: 0x000003BF | l2p_mhvalid
[18211.552072] iwlwifi 0000:00:10.0: 0x00009110 | l2p_addr_match
[18211.553549] iwlwifi 0000:00:10.0: 0x0000001D | lmpm_pmg_sel
[18211.554872] iwlwifi 0000:00:10.0: 0x14100651 | timestamp
[18211.556213] iwlwifi 0000:00:10.0: 0x00340828 | flow_handler
[18211.557650] iwlwifi 0000:00:10.0: Start IWL Error Log Dump:
[18211.558952] iwlwifi 0000:00:10.0: Status: 0x00000040, count: 7
[18211.560317] iwlwifi 0000:00:10.0: 0x00000070 | NMI_INTERRUPT_LMAC_FATAL
[18211.561882] iwlwifi 0000:00:10.0: 0x00000000 | umac branchlink1
[18211.563291] iwlwifi 0000:00:10.0: 0xC0086B3C | umac branchlink2
[18211.564775] iwlwifi 0000:00:10.0: 0xC0083D08 | umac interruptlink1
[18211.566262] iwlwifi 0000:00:10.0: 0xC0083D08 | umac interruptlink2
[18211.567754] iwlwifi 0000:00:10.0: 0x00000800 | umac data1
[18211.569116] iwlwifi 0000:00:10.0: 0xC0083D08 | umac data2
[18211.570374] iwlwifi 0000:00:10.0: 0xDEADBEEF | umac data3
[18211.571608] iwlwifi 0000:00:10.0: 0x00000024 | umac major
[18211.572920] iwlwifi 0000:00:10.0: 0xAD812EE0 | umac minor
[18211.574126] iwlwifi 0000:00:10.0: 0xC088628C | frame pointer
[18211.575451] iwlwifi 0000:00:10.0: 0xC088628C | stack pointer
[18211.576629] iwlwifi 0000:00:10.0: 0x00CD014E | last host cmd
[18211.577767] iwlwifi 0000:00:10.0: 0x00000000 | isr status reg
[18211.578979] iwlwifi 0000:00:10.0: Fseq Registers:
[18211.580105] iwlwifi 0000:00:10.0: 0xA349E85B | FSEQ_ERROR_CODE
[18211.581237] iwlwifi 0000:00:10.0: 0xE1EAA921 | FSEQ_TOP_INIT_VERSION
[18211.582405] iwlwifi 0000:00:10.0: 0x6F978347 | FSEQ_CNVIO_INIT_VERSION
[18211.583702] iwlwifi 0000:00:10.0: 0x0000A056 | FSEQ_OTP_VERSION
[18211.585072] iwlwifi 0000:00:10.0: 0x2602412E | FSEQ_TOP_CONTENT_VERSION
[18211.586554] iwlwifi 0000:00:10.0: 0x7660E6DE | FSEQ_ALIVE_TOKEN
[18211.588094] iwlwifi 0000:00:10.0: 0xC1001788 | FSEQ_CNVI_ID
[18211.589535] iwlwifi 0000:00:10.0: 0xBEB2DE9C | FSEQ_CNVR_ID
[18211.590793] iwlwifi 0000:00:10.0: 0x03000000 | CNVI_AUX_MISC_CHIP
[18211.592088] iwlwifi 0000:00:10.0: 0x0BADCAFE | CNVR_AUX_MISC_CHIP
[18211.593408] iwlwifi 0000:00:10.0: 0x0BADCAFE | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[18211.595082] iwlwifi 0000:00:10.0: 0x0BADCAFE | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[18211.596946] iwlwifi 0000:00:10.0: Collecting data: trigger 2 fired.
[18211.598413] ieee80211 phy0: Hardware restart was requested
[18212.159886] iwlwifi 0000:00:10.0: Failed updating beacon data
[18212.161346] iwlwifi 0000:00:10.0: Failed to send MAC context (action:2): -5
[18212.162815] iwlwifi 0000:00:10.0: failed to update MAC f4:8c:50:93:28:4a
 


17.11.20214138Base systemBug ReportVery LowLowprocd requires seccomp in certain configurationsopenwrt-21.02Unconfirmed Task Description

If CONFIG_PACKAGE_procd-seccomp=y, procd will be built with -DSECCOMP_SUPPORT.

In practice, this means that if some service’s init script tries to set a seccomp policy, procd will call the /sbin/seccomp-trace binary (relevant code). The problem is that this binary, which is part of procd, is not installed by the procd package, it is contained in a separate procd-seccomp package. So, the service which tries to set the policy will fail to start.

I can see the following options:

1. Any package that wants to do procd_set_param seccomp in its init script needs to explicitly depend on procd-seccomp (and this needs to be documented somewhere).
2. Init scripts should request seccomp conditionally, only if it is available (if procd-seccomp is installed? or what should the test be?).
3. procd-seccomp needs to be installed by default whenever CONFIG_PACKAGE_procd-seccomp=y.

Currently, I am aware of two packages affected: umdns (https://bugs.openwrt.org/index.php?do=details&task_id=3355) and transmission (https://github.com/openwrt/packages/issues/16972), but, I imagine, eventually there will be more.

14.11.20214137Base systemBug ReportVery LowLowOpenWRT 21.02.1 doesn't completely boot on RaidSonic IB...TrunkUnconfirmed Task Description

Device: RaidSonic IB-NAS4220-B
OpenWRT version: 21.02.1

Problem:

When OpenWRT 21.02.1 is flashed to the RaidSonic IB-NAS4220-B by using the following file...
https://downloads.openwrt.org/releases/21.02.1/targets/gemini/generic/openwrt-21.02.1-gemini-raidsonic_ib-4220-b-squashfs-factory.bin

It results in a system which will not boot and hangs on...

[    7.047812] Waiting for root device /dev/mtdblock3...

Steps to reproduce:

Once you’ve extracted the .bin file (linked to above... which is actually a .tar.gz in disguise)... you’ll have files zImage, rd.gz and hddapp.tgz which you can put on a TFTP server so that the boot loader can access them.

e.g. on my Linux desktop, I might download, extract and host those files via a temporary TFTP server (using dnsmasq)...

mkdir ~/owrt-tftp
cd ~/owrt-tftp
wget -O- https://downloads.openwrt.org/releases/21.02.1/targets/gemini/generic/openwrt-21.02.1-gemini-raidsonic_ib-4220-b-squashfs-factory.bin | tar -zx
sudo dnsmasq -i enx001060b1d868 –enable-tftp –tftp-root=”$(pwd)” -d -p0

Then via serial this is how flashing it and booting it went...

Storlink SL351x Boot Loader [Linux], version 1.0.9
Built by linux, 17:27:04, Dec 19 2007

Processor: SL3516c2
CPU Rate: 300000000
AHB Bus Clock:150MHz    Ratio:2/1
MAC 1 Address: 00:01:D2:07:0D:BD
MAC 2 Address: 00:50:C2:2B:D0:02
inet addr: 192.168.0.200/255.255.255.0
==> enter ^C to abort booting within 3 seconds ...... 
PHY 0 Addr 1 Vendor ID: 0x01410e11
mii_write: phy_addr=0x1 reg_addr=0x4 value=0x5e1 
mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 
mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 

                              Boot Menu
==============================================================================
0: Reboot                                   1: Start the Kernel Code
2: List Image                               3: Delete Image
4: Create New Image                         5: Enter Command Line Interface
6: Set IP Address                           7: Set MAC Address
8: Show Configuration                       F: Create Default FIS
X: Upgrade Boot                             Y: Upgrade Kernel
Z: Upgrade Firmware                         A: Upgrade Application
R: Upgrade RAM Disk                         

=> Select: 8

Processor: SL3516c2
CPU Rate: 300000000
AHB Bus Clock:150MHz    Ratio:2/1
MAC 1 Address: 00:01:D2:07:0D:BD
MAC 2 Address: 00:50:C2:2B:D0:02
inet addr: 192.168.0.200/255.255.255.0

                              Boot Menu
==============================================================================
0: Reboot                                   1: Start the Kernel Code
2: List Image                               3: Delete Image
4: Create New Image                         5: Enter Command Line Interface
6: Set IP Address                           7: Set MAC Address
8: Show Configuration                       F: Create Default FIS
X: Upgrade Boot                             Y: Upgrade Kernel
Z: Upgrade Firmware                         A: Upgrade Application
R: Upgrade RAM Disk                         

=> Select: Y



1  : Download by X-modem
2  : Download by TFTP
ESC: Return 
==> 2
TFTP Server IP Address: 192.168.0.66
Image Path and name(e.g. /images/zImage): zImage
TFTP Download zImage from 192.168.0.66 .....................

Successful to download by TFTP! Size=2097152

Do not power-off this device while flash programming is proceeding!!
==> enter ^C to abort program flash 0x30020000 within 3 seconds ...... 

Erase flash (0x30020000): Size=3145728 ........................ OK!
Program flash (0x30020000): Size=2097152 ................ OK!

Start Update FIS data......
Erase flash (0x30fe0000): Size=131072 . OK!
Program flash (0x30fe0000): Size=5120 . OK!
Successful to upgrade (0x30020000)!

                              Boot Menu
==============================================================================
0: Reboot                                   1: Start the Kernel Code
2: List Image                               3: Delete Image
4: Create New Image                         5: Enter Command Line Interface
6: Set IP Address                           7: Set MAC Address
8: Show Configuration                       F: Create Default FIS
X: Upgrade Boot                             Y: Upgrade Kernel
Z: Upgrade Firmware                         A: Upgrade Application
R: Upgrade RAM Disk                         

=> Select: A



1  : Download by X-modem
2  : Download by TFTP
ESC: Return 
==> 2
TFTP Server IP Address: 192.168.0.66
Image Path and name(e.g. /hddapp.tgz): hddapp.tgz
TFTP Download hddapp.tgz from 192.168.0.66 .......................................................

Successful to download by TFTP! Size=6291456

Do not power-off this device while flash programming is proceeding!!
==> enter ^C to abort program flash 0x30920000 within 3 seconds ...... 

Erase flash (0x30920000): Size=6291456 ................................................ OK!
Program flash (0x30920000): Size=6291456 ................................................ OK!

Start Update FIS data......
Erase flash (0x30fe0000): Size=131072 . OK!
Program flash (0x30fe0000): Size=5120 . OK!
Successful to upgrade (0x30920000)!

                              Boot Menu
==============================================================================
0: Reboot                                   1: Start the Kernel Code
2: List Image                               3: Delete Image
4: Create New Image                         5: Enter Command Line Interface
6: Set IP Address                           7: Set MAC Address
8: Show Configuration                       F: Create Default FIS
X: Upgrade Boot                             Y: Upgrade Kernel
Z: Upgrade Firmware                         A: Upgrade Application
R: Upgrade RAM Disk                         

=> Select: R



1  : Download by X-modem
2  : Download by TFTP
ESC: Return 
==> 2
TFTP Server IP Address: 192.168.0.66
Image Path and name(e.g. /images/zImage): rd.gz
TFTP Download rd.gz from 192.168.0.66 ...........

Successful to download by TFTP! Size=955102

Do not power-off this device while flash programming is proceeding!!
==> enter ^C to abort program flash 0x30320000 within 3 seconds ...... 

Erase flash (0x30320000): Size=6291456 ................................................ OK!
Program flash (0x30320000): Size=955102 ........ OK!

Start Update FIS data......
Erase flash (0x30fe0000): Size=131072 . OK!
Program flash (0x30fe0000): Size=5120 . OK!
Successful to upgrade (0x30320000)!

                              Boot Menu
==============================================================================
0: Reboot                                   1: Start the Kernel Code
2: List Image                               3: Delete Image
4: Create New Image                         5: Enter Command Line Interface
6: Set IP Address                           7: Set MAC Address
8: Show Configuration                       F: Create Default FIS
X: Upgrade Boot                             Y: Upgrade Kernel
Z: Upgrade Firmware                         A: Upgrade Application
R: Upgrade RAM Disk                         

=> Select: 0

Reboot system...

Failed to change IP address due to illegal value
Failed to change IP Gateway due to illegal value




Storlink SL351x Boot Loader [Linux], version 1.0.9
Built by linux, 17:27:04, Dec 19 2007

Processor: SL3516c2
CPU Rate: 300000000
AHB Bus Clock:150MHz    Ratio:2/1
MAC 1 Address: 00:01:D2:07:0D:BD
MAC 2 Address: 00:50:C2:2B:D0:02
inet addr: 192.168.0.200/255.255.255.0
==> enter ^C to abort booting within 3 seconds ...... 
Load Kern image from 0x30020000 to 0x1600000 size 2097152
Load Ramdisk image from 0x30320000 to 0x800000 size 955102
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.4.154 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16325-88151b8303)) #0 PREEMPT Sun Oct 24 09:01:35 2021
[    0.000000] CPU: FA526 [66015261] revision 1 (ARMv4), cr=0000397f
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] OF: fdt: Machine model: Raidsonic NAS IB-4220-B
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 16 MiB at 0x07000000
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32480
[    0.000000] Kernel command line: console=ttyS0,19200n8 root=/dev/mtdblock3 rw rootfstype=squashfs,jffs2 rootwait
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 103620K/131072K available (6060K kernel code, 217K rwdata, 1644K rodata, 1024K init, 238K bss, 11068K reserved, 16384K cma-reserved, 0K highmem)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] random: get_random_bytes called from start_kernel+0x29c/0x498 with crng_init=0
[    0.000000] clocksource: FTTMR010-TIMER2: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns
[    0.000029] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns
[    0.000127] Switching to timer-based delay loop, resolution 40ns
[    0.000761] Console: colour dummy device 80x30
[    0.000918] Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
[    0.000981] pid_max: default: 32768 minimum: 301
[    0.001859] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.001950] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.005045] CPU: Testing write buffer coherency: ok
[    0.009061] Setting up static identity map for 0x100000 - 0x100048
[    0.009648] rcu: Hierarchical SRCU implementation.
[    0.022636] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.022712] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.026641] pinctrl core: initialized pinctrl subsystem
[    0.033627] NET: Registered protocol family 16
[    0.041654] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.053778] No ATAGs?
[    0.064247] pinctrl-gemini 40000000.syscon:pinctrl: detected 3516 chip variant
[    0.064320] pinctrl-gemini 40000000.syscon:pinctrl: GLOBAL MISC CTRL at boot: 0x83c22037
[    0.064367] pinctrl-gemini 40000000.syscon:pinctrl: flash pin is set
[    0.065952] pinctrl-gemini 40000000.syscon:pinctrl: initialized Gemini pin control driver
[    0.257678] pl08xdmac 67000000.dma-controller: FTDMAC020 1.16 rel 1
[    0.257740] pl08xdmac 67000000.dma-controller: FTDMAC020 4 channels, has built-in bridge, AHB0 and AHB1, supports linked lists
[    0.258001] pl08xdmac 67000000.dma-controller: initialized 4 virtual memcpy channels
[    0.259615] pl08xdmac 67000000.dma-controller: DMA: PL080 rev0 at 0x67000000 irq 28
[    0.260081] Gemini SoC 3516 revision c2, set arbitration 00200030
[    0.268005] vgaarb: loaded
[    0.271989] SCSI subsystem initialized
[    0.287129] workqueue: max_active 576 requested for napi_workq is out of range, clamping between 1 and 512
[    0.293429] clocksource: Switched to clocksource FTTMR010-TIMER2
[    0.384678] thermal_sys: Registered thermal governor 'step_wise'
[    0.385986] NET: Registered protocol family 2
[    0.386509] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.389778] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    0.389942] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.390045] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.390127] TCP: Hash tables configured (established 1024 bind 1024)
[    0.390624] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.390738] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.391643] NET: Registered protocol family 1
[    0.391784] PCI: CLS 0 bytes, default 32
[    0.400259] workingset: timestamp_bits=14 max_order=15 bucket_order=1
[    0.513343] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.513390] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.699187] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    0.699929] io scheduler mq-deadline registered
[    0.699976] io scheduler kyber registered
[    0.706151] ftgpio010-gpio 4d000000.gpio: FTGPIO010 @(ptrval) registered
[    0.711817] ftgpio010-gpio 4e000000.gpio: FTGPIO010 @(ptrval) registered
[    0.714713] ftgpio010-gpio 4f000000.gpio: FTGPIO010 @(ptrval) registered
[    0.724974] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[    0.753268] printk: console [ttyS0] disabled
[    0.754208] 42000000.serial: ttyS0 at MMIO 0x42000000 (irq = 18, base_baud = 3000000) is a 16550A
[    3.632841] printk: console [ttyS0] enabled
[    3.665802] Loading iSCSI transport class v2.0-870.
[    3.704501] gemini_sata_bridge 46000000.sata: SATA ID 00000e00, PHY ID: 01000100
[    3.750173] gemini_sata_bridge 46000000.sata: set up the Gemini IDE/SATA nexus
[    3.795569] pata_ftide010 63000000.ide: set up Gemini PATA0
[    3.830157] pata_ftide010 63000000.ide: device ID 00000500, irq 26, reg [mem 0x63000000-0x63000fff]
[    3.885078] pata_ftide010 63000000.ide: SATA0 (master) start
[    4.093523] gemini_sata_bridge 46000000.sata: SATA0 PHY ready
[    4.128025] pata_ftide010 63000000.ide: brought 1 bridges online
[    4.170153] scsi host0: pata_ftide010
[    4.195220] ata1: SATA max UDMA/133 irq 26
[    4.222317] pata_ftide010 63400000.ide: set up Gemini PATA1
[    4.256481] pata_ftide010 63400000.ide: device ID 00000500, irq 27, reg [mem 0x63400000-0x63400fff]
[    4.311250] pata_ftide010 63400000.ide: SATA1 (master) start
[    4.429812] ata1.00: HPA detected: current 976771055, native 976773168
[    4.469031] ata1.00: ATA-8: WDC WD5000AAJS-22YFA0, 12.01C02, max UDMA/133
[    4.509766] ata1.00: 976771055 sectors, multi 0: LBA48 NCQ (depth 0/32)
[    4.549510] gemini_sata_bridge 46000000.sata: SATA1 PHY ready
[    4.584596] pata_ftide010 63400000.ide: brought 1 bridges online
[    4.623998] scsi 0:0:0:0: Direct-Access     ATA      WDC WD5000AAJS-2 1C02 PQ: 0 ANSI: 5
[    4.677790] scsi host1: pata_ftide010
[    4.701723] ata2: SATA max UDMA/133 irq 27
[    4.733205] sd 0:0:0:0: [sda] 976771055 512-byte logical blocks: (500 GB/466 GiB)
[    4.782402] physmap-flash 30000000.flash: no enabled pin control state
[    4.825925] physmap-flash 30000000.flash: no disabled pin control state
[    4.866174] sd 0:0:0:0: [sda] Write Protect is off
[    4.895772] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.950469] physmap-flash 30000000.flash: initialized Gemini-specific physmap control
[    5.022102] physmap-flash 30000000.flash: physmap platform flash device: [mem 0x30000000-0x30ffffff]
[    5.079830] ata2.00: HPA detected: current 976771055, native 976773168
[    5.121754] 30000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101
[    5.183973] sd 0:0:0:0: [sda] Attached SCSI disk
[    5.213017] ata2.00: ATA-7: SAMSUNG HD502IJ, 1AA01113, max UDMA7
[    5.249280] Amd/Fujitsu Extended Query Table at 0x0040
[    5.280265] ata2.00: 976771055 sectors, multi 0: LBA48 NCQ (depth 0/32)
[    5.320148]   Amd/Fujitsu Extended Query version 1.3.
[    5.351156] number of CFI chips: 1
[    5.373939] scsi 1:0:0:0: Direct-Access     ATA      SAMSUNG HD502IJ  1113 PQ: 0 ANSI: 5
[    5.427677] Searching for RedBoot partition table in 30000000.flash at offset 0x0
[    5.479262] sd 1:0:0:0: [sdb] 976771055 512-byte logical blocks: (500 GB/466 GiB)
[    5.548038] No RedBoot partition table detected in 30000000.flash
[    5.585180] sd 1:0:0:0: [sdb] Write Protect is off
[    5.618553] Searching for RedBoot partition table in 30000000.flash at offset 0x0
[    5.664307] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    5.739093] No RedBoot partition table detected in 30000000.flash
[    5.800769] sd 1:0:0:0: [sdb] Attached SCSI disk
[    5.831336] mdio-gpio mdio: failed to get alias id
[    5.862316] libphy: GPIO Bitbanged MDIO: probed
[    5.889523] random: fast init done
[    5.916359] libphy: Fixed MDIO Bus: probed
[    5.988044] gmac-gemini 60000000.ethernet: Ethernet device ID: 0x000, revision 0x1
[    6.035869] gemini-ethernet-port 60008000.ethernet-port: probe 60008000.ethernet-port ID 0
[    6.087301] gemini-ethernet-port 60008000.ethernet-port: using a random ethernet address
[    6.139202] gemini-ethernet-port 60008000.ethernet-port eth0: irq 31, DMA @ 0x0x60008000, GMAC @ 0x0x6000a000
[    6.293890] Marvell 88E1118 gpio-0:01: attached PHY driver [Marvell 88E1118] (mii_bus:phy_addr=gpio-0:01, irq=POLL)
[    6.358786] gemini-ethernet-port 6000c000.ethernet-port: probe 6000c000.ethernet-port ID 1
[    6.410065] gemini-ethernet-port 6000c000.ethernet-port: using a random ethernet address
[    6.461878] gemini-ethernet-port 6000c000.ethernet-port eth1: irq 32, DMA @ 0x0x6000c000, GMAC @ 0x0x6000e000
[    6.522095] gemini-ethernet-port 6000c000.ethernet-port eth1: PHY init failed, deferring to ifup time
[    6.582733] rtc-ftrtc010 45000000.rtc: registered as rtc0
[    6.619257] gemini-poweroff 4b000000.power-controller: Gemini poweroff driver registered
[    6.731823] ftwdt010-wdt 41000000.watchdog: FTWDT010 watchdog driver enabled
[    6.785919] NET: Registered protocol family 10
[    6.818572] Segment Routing with IPv6
[    6.841325] NET: Registered protocol family 17
[    6.868323] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[    6.946599] 8021q: 802.1Q VLAN Support v1.8
[    6.983395] rtc-ftrtc010 45000000.rtc: setting system clock to 2019-11-08T09:18:18 UTC (1573204698)
[    7.039504] Waiting for root device /dev/mtdblock3...

Some seconds later you’ll also get...

[  124.733643] random: crng init done

But ultimately I think it’s still waiting on that ‘Waiting for root device’ message.

Additionally I also went back to the original firmware that this device came with (flashing it via the same method as above)... this worked (I also made a RAID 1 from the two disks this NAS has, formatted them... just to see if it would make a difference). Then I tried to flash the 21.02.1 .bin file again, but this time via the original firmware’s own upgrade web page... which flashed it perfectly fine. But I could see via serial that booting up got stuck at the same point.

I’m about to try the ext4 version of that .bin file (which is oddly named .bin.gz... lovely consistency!) and see if I get the same problem.

Any tips most welcome... but this file just doesn’t work.

14.11.20214136KernelBug ReportVery LowHigherror loading ifbopenwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

Xiaomi Mi Router 3G (MediaTek MT7621)

OpenWrt 21.02.0, r16279-5cc0535800

# insmod ifb
failed to insert ifb

# modinfo ifb
invalid endianess: 110
failed to load the .modinfo section from ifb

In dmesg:
[108588.487809] Module has invalid ELF structures

# opkg info kmod-ifb
Package: kmod-ifb
Version: 5.4.143-1
Depends: kernel (= 5.4.143-1-ecc7515846d9a85938da6124aee98749)
Status: install user installed
Architecture: mipsel_24kc
Installed-Time: 1636901589

# ll /lib/modules/5.4.143/ifb.ko
-rw-r–r– 1 root root 6748 Jul 2 14:31 /lib/modules/5.4.143/ifb.ko

09.11.20214135Base systemBug ReportVery LowLowATH79 - AR9331 gadget mode bugopenwrt-21.02Unconfirmed Task Description

At this week i have installed the last version of OpenWRT (21.02.1) at my modded TP-Link MR3020 v1 (8MB SPI Flash, 64MB DDR SDRAM).
I switched USB port to ‘device’ mode with hardware mod (GPIO13) and turn on kmod modules for gadget mode with ‘make menuconfig’. also I slightly corrected the config file ‘ar9331_tplink_mr-3020_v1.dts for usb controller mode: ‘host’→ ‘peripheral’.

Firmware starts normally.
When i prompt command ‘insmod g_mass_storage file=/image’, host detects the new mass storage device with correct attributes (name, serial, sectors count).

For prevent buffer overload bugs, i check this module with very small image file (64KB).

Log for that stage:

root@OpenWrt:/# insmod g_mass_storage file=backing_file
[  348.897602] Mass Storage Function, version: 2009/09/11
[  348.901303] LUN: removable file: (no medium)
[  348.905837] LUN: file: /backing_file
[  348.909104] Number of LUNs=1
[  348.923787] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[  348.929305] g_mass_storage gadget: userspace failed to provide iSerialNumber
[  348.936379] g_mass_storage gadget: g_mass_storage ready
root@OpenWrt:/# [  349.412682] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage


But if i try to read sectors from that device - it is not succesfull. My host pc freezes for some seconds, and after pause device disconnected from host.
At this moment i see a restart of the OpenWRT with watchdog:

root@OpenWrt:/# [  349.412682] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage


***************************************
*     U-Boot 1.1.4-e5984195-clean     *
*          Build: 2017-02-24          *
***************************************
......
[    3.927282] init: Console is alive
[    3.930007] init: - watchdog -
[    3.932844] init: Watchdog has previously reset the system
.......
[   15.135549] procd: - early -
[   15.137533] procd: - watchdog -
[   15.140670] procd: Watchdog has previously reset the system
[   16.233851] procd: - watchdog -
[   16.236135] procd: Watchdog has previously reset the system
[   16.244006] procd: - ubus -
[   17.216758] urandom_read: 3 callbacks suppressed

i compiled the previous version (19.07.8 - Atheros AR7xxx/AR9xx → Devices with small flash → MR3020v1) - gadget mode (g_mass_storage) works fine at that board.

09.11.20214134Base systemBug ReportVery LowLowKernel warning in mac80211/rate.cTrunkUnconfirmed Task Description

- Device problem occurs on
Netgear WNDR3800

- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 21.02.1 r16325-88151b8303

- Steps to reproduce
Unknown

[687920.680709] ------------[ cut here ]------------
[687920.685494] WARNING: CPU: 0 PID: 0 at backports-5.10.68-1/net/mac80211/rate.c:677 0x8769e700 [mac80211@1c74b09d+0x7cdb0]
[687920.696451] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat ath9k_hw ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 ath9k_pci_owl_loader xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 sit tunnel4 ip_tunnel ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
[687920.761828] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.154 #0
[687920.767735] Stack : 87700000 800b98ec 80660000 805fa498 00000000 00000000 00000000 00000000
[687920.776172]         00000000 00000000 00000000 00000000 00000000 00000001 87c0bc30 08119e6b
[687920.784607]         87c0bcc8 00000000 00000000 000000ff 00000038 8057ac04 352e342e 31353420
[687920.793048]         000000ff 9a3bffbc 00000000 73776170 00000000 87c0bc10 00000000 8769e700
[687920.801490]         00000009 876f6760 870501fc 80630000 00000002 8032041c 00000000 80790000
[687920.809926]         ...
[687920.812459] Call Trace:
[687920.812473] [<87700000>] 0x87700000 [ath9k_hw@e11bb2b5+0x55560]
[687920.820987] [<800b98ec>] 0x800b98ec
[687920.824561] [<80660000>] 0x80660000
[687920.828150] [<8057ac04>] 0x8057ac04
[687920.831738] [<8769e700>] 0x8769e700 [mac80211@1c74b09d+0x7cdb0]
[687920.837755] [<8032041c>] 0x8032041c
[687920.841339] [<87700000>] 0x87700000 [ath9k_hw@e11bb2b5+0x55560]
[687920.847337] [<80069364>] 0x80069364
[687920.850904] [<8006936c>] 0x8006936c
[687920.854482] [<800824f4>] 0x800824f4
[687920.858064] [<8769e700>] 0x8769e700 [mac80211@1c74b09d+0x7cdb0]
[687920.864058] [<8008259c>] 0x8008259c
[687920.867638] [<800bb0cc>] 0x800bb0cc
[687920.871216] [<8769e700>] 0x8769e700 [mac80211@1c74b09d+0x7cdb0]
[687920.877208] [<800bb120>] 0x800bb120
[687920.880776] [<800c3f10>] 0x800c3f10
[687920.884357] [<8766991c>] 0x8766991c [ath9k@c64b0025+0x19450]
[687920.890113] [<8766cc84>] 0x8766cc84 [ath9k@c64b0025+0x19450]
[687920.895853] [<800ba7e4>] 0x800ba7e4
[687920.899444] [<87664664>] 0x87664664 [ath9k@c64b0025+0x19450]
[687920.905177] [<802bfc1c>] 0x802bfc1c
[687920.908773] [<876b0d9c>] 0x876b0d9c [mac80211@1c74b09d+0x7cdb0]
[687920.914799] [<876b0ef0>] 0x876b0ef0 [mac80211@1c74b09d+0x7cdb0]
[687920.920811] [<876b8bf0>] 0x876b8bf0 [mac80211@1c74b09d+0x7cdb0]
[687920.926833] [<876ba838>] 0x876ba838 [mac80211@1c74b09d+0x7cdb0]
[687920.932836] [<803e1450>] 0x803e1450
[687920.936414] [<87664eb8>] 0x87664eb8 [ath9k@c64b0025+0x19450]
[687920.942149] [<80660000>] 0x80660000
[687920.945715] [<80660000>] 0x80660000
[687920.949284] [<80085380>] 0x80085380
[687920.952853] [<80580170>] 0x80580170
[687920.956419] [<800bf374>] 0x800bf374
[687920.959989] [<802bfc1c>] 0x802bfc1c
[687920.963564] [<80064f78>] 0x80064f78
[687920.967140] 
[687920.968707] ---[ end trace 297acf7eefa0c6ff ]---
09.11.20214133Base systemBug ReportVery LowLowIGMP snooping doesn't work on mvebu/cortexa9openwrt-21.02Unconfirmed Task Description

When IGMP snooping is enabled on a Linksys WRT1900ACS device, no multicast is running at all.
When it’s disabled, multicast packets floods my wifi interface.

This happens with openwrt 21.02.0 and 21.02.1 too. With openwrt 19.07 worked well on same device.
I am using 21.02.1 latest stable release.
My setup uses bridge in LAN and WiFi device.
As a workaround udpxy was used.

09.11.20214131Base systemBug ReportVery LowLow21.02.1 squashfs overlay retained rpi4TrunkUnconfirmed Task Description

Upgrading from 21.02.0 to 21.02.1 leads to whacky opkg state where previous packages are listed

see:
https://forum.openwrt.org/t/rpi-4-sysupgrade-21-02-1-squashfs-overlay-retained/110586?u=wulfy23 for further information

 


08.11.20214129ToolchainBug ReportVery LowLowscripts/env: not working with differnet defaultBranch n...TrunkUnconfirmed Task Description

the tool scripts/env uses git to manage multiple configs and environments. unfortunately, it was created with the default branch name “master” in mind. this name is configurable for some time now, and the default also changed with newer versions now. The new default is “main”. this breaks the env script, which assumes master as first branch.

07.11.20214128Base systemBug ReportVery LowHighipv6 broken on Xiaomi Redmi AC2100openwrt-21.02Unconfirmed Task Description

Most of my clients can’t connect with my dual stack internet connection with IPv6.

I tested now a lot, but cant get it working on my Xiaomi Redmi AC2100.

When I ping outside (eg. to google.com) with IPv6 I never get a answer back.

When I run tcpdump on the Gateway running OpenWRT 21.02 (tested now with rc4 to .1) I see the packets leaving the wan interface and I also see the answers on the wan interface.

But the answers don’t come back to the lan interface.

I tested to enable/disable source based policy routing
I tested to enable/disable network.globals.packet_steering

I also have flow offloading switched off!

First I was thinking, is works with windows, but this seams just we random - what is working and what not... now it is also not working on my windows - where it was working before (the screenshots come from that installation)

The problem is also reported to the forum at https://forum.openwrt.org/t/ipv6-issue-with-dsa/107138

07.11.20214127Base systemBug ReportVery LowMediumEthernet EEE autodetection broken on Xiaomi Redmi AC210...openwrt-21.02Unconfirmed Task Description

Starting with OpenWRT 21.02.0 my cable modem is unable to connect to my Router.
I figured out, that it works when I run `ethtool –set-eee wan eee off`
But this was not need with 19.07.7 - and after a firmware update ethtool is missed and so I cant connect to the internet again.

I have already reported this at the forum:

https://forum.openwrt.org/t/redmi-ac2100-dsa-and-cable-modem-no-dhcp-answer/104273

06.11.20214126KernelBug ReportVery LowMediumksoftirqd kernel problem - device very slow in respondi...openwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
root@OpenWRT:~# head /tmp/sysinfo/*

> /tmp/sysinfo/board_name <

tplink,tl-wdr3600-v1

> /tmp/sysinfo/model <

TP-Link TL-WDR3600 v1
root@OpenWRT:~#

- Software versions of OpenWrt/LEDE release, packages, etc.
21.02.1, no added packages but with config snippets for packages usually installed with snapshot builds.
snapshot packages added by command “opkg update; opkg install luci-ssl apinger snmpd luci-app-sqm netperf avahi-nodbus-daemon avahi-daemon-service-http avahi-daemon-service-ssh” after new snapshot sysupgrade image installed.
[ 0.000000] Linux version 5.4.154 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16325-88151b8303)) #0 Sun Oct 24 09:01:35 2021
[ 0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
[ 0.000000] MIPS: machine is TP-Link TL-WDR3600 v1
[ 0.000000] SoC: Atheros AR9344 rev 2
[ 0.000000] Memory: 122180K/131072K available (5252K kernel code, 191K rwdata, 688K rodata, 1220K init, 205K bss, 8892K reserved, 0K cma-reserved)
[ 0.000000] NR_IRQS: 51
[ 0.000000] CPU clock: 560.000 MHz

- Steps to reproduce
not known yet

[625492.253977] ————[ cut here ]———— [625492.254022] WARNING: CPU: 0 PID: 7 at backports-5.10.68-1/net/mac80211/rate.c:688 0x8779e72c [mac80211@8f714d2c+0x7cdb0]
[625492.254027] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat ath9k_hw ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
[625492.254175] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 5.4.154 #0
[625492.254180] Stack : 87800000 800b98ec 80660000 805fa498 00000000 00000000 00000000 00000000
[625492.254203] 00000000 00000000 00000000 00000000 00000000 00000001 87c47b20 6c8b5f7c
[625492.254222] 87c47bb8 00000000 00000000 000000e6 00000038 8057ac04 00000004 00000000
[625492.254241] 000000e6 cbf12d42 807b0000 6b736f66 00000000 87c47b00 00000000 8779e72c
[625492.254261] 00000009 877f6760 871481fc 80630000 00000010 00000000 00000000 80790000
[625492.254281] ...
[625492.254287] Call Trace:
[625492.254296] [<800b98ec>] 0x800b98ec
[625492.254302] [<80660000>] 0×80660000 [625492.254312] [<8057ac04>] 0x8057ac04
[625492.254328] [<8779e72c>] 0x8779e72c [mac80211@8f714d2c+0x7cdb0]
[625492.254351] [<80069364>] 0×80069364 [625492.254358] [<8006936c>] 0x8006936c
[625492.254365] [<800824f4>] 0x800824f4
[625492.254380] [<8779e72c>] 0x8779e72c [mac80211@8f714d2c+0x7cdb0]
[625492.254387] [<8008259c>] 0x8008259c
[625492.254407] [<8779e72c>] 0x8779e72c [mac80211@8f714d2c+0x7cdb0]
[625492.254432] [<800c3f10>] 0x800c3f10
[625492.254444] [<8706b894>] 0x8706b894 [ath9k@185558b4+0×19450]
[625492.254461] [<8706991c>] 0x8706991c [ath9k@185558b4+0×19450]
[625492.254489] [<8706cc84>] 0x8706cc84 [ath9k@185558b4+0×19450]
[625492.254520] [<87064664>] 0×87064664 [ath9k@185558b4+0×19450]
[625492.254554] [<877b0d9c>] 0x877b0d9c [mac80211@8f714d2c+0x7cdb0]
[625492.254580] [<877b0ef0>] 0x877b0ef0 [mac80211@8f714d2c+0x7cdb0]
[625492.254604] [<877b8bf0>] 0x877b8bf0 [mac80211@8f714d2c+0x7cdb0]
[625492.254635] [<877ba838>] 0x877ba838 [mac80211@8f714d2c+0x7cdb0]
[625492.254642] [<803e1450>] 0x803e1450
[625492.254649] [<800aaa14>] 0x800aaa14
[625492.254656] [<80660000>] 0×80660000 [625492.254663] [<80660000>] 0×80660000 [625492.254669] [<80085380>] 0×80085380 [625492.254677] [<80580170>] 0×80580170 [625492.254686] [<800a2d20>] 0x800a2d20
[625492.254693] [<800854e4>] 0x800854e4
[625492.254699] [<8057c050>] 0x8057c050
[625492.254706] [<800a2e64>] 0x800a2e64
[625492.254712] [<8009e7ec>] 0x8009e7ec
[625492.254718] [<8057c2c0>] 0x8057c2c0
[625492.254725] [<8009eb88>] 0x8009eb88
[625492.254732] [<8009ea50>] 0x8009ea50
[625492.254739] [<8009ea50>] 0x8009ea50
[625492.254746] [<80064bf8>] 0x80064bf8
[625492.254758]
[625492.254793] —[ end trace 2881b0fce86b8e15 ]—

diagnostic informations collected, see attachments:
dmesg
logread

additional requests:
- could “-T” option be added to busybox “dmesg” command (readable time stamps instead of “seconds since start”)?

05.11.20214125Base systemBug ReportVery LowLowdnsmasq(-dhcpv6)TrunkUnconfirmed Task Description

dnsmasq can’t read the “Additional servers file” (from the “DHCP and DNS” “Advanced Settings” tab; dhcp.@dnsmasq[0].serversfile) because it isn’t added to jail mounts in the init script.

04.11.20214123Base systemBug ReportVery LowLowpppoe - Unknown error (USER_REQUEST)openwrt-21.02Unconfirmed Task Description

Device: Ubiquiti EdgeRouter X
Version: OpenWrt 21.02.1 r16325-88151b8303

After fresh sysupgrade I switch protocol of WAN interface to pppoe with my credentials and it throws an error “Unknown error (USER_REQUEST)“.

Support of my ISP told me that they didn’t see my MAC address. But they saw it when I connected my laptop directly.

No issues when I run version 19.07

I’m happy to provide additional if necessary.

 


04.11.20214121Base systemBug ReportVery LowLowuhttpd: checked and used certificate are different in u...TrunkUnconfirmed Task Description

uhttpd init script checks different certificate files then it finally uses in some situations. This causes uhttpd fail to start.

In the init script, there are lines

config_get UHTTPD_KEY  "$cfg" key  /etc/uhttpd.key
config_get UHTTPD_CERT "$cfg" cert /etc/uhttpd.crt

Some checks are performed on UHTTPD_KEY and UHTTPD_CERT and later, there is

append_arg "$cfg" cert "-C"
append_arg "$cfg" key  "-K"

This can cause problem if key or cert option is missing. In the first place, defalt value is used and in the second place, empty string is used.

Deleting key and cert option and restarting uhttpd will pass all checks, new certificate and key will be generated in default location and later, empty certificate and key paths are passed to uhttpd which will fail.

I would like to send PR to fix this but I would like to ask for the best solution. Naive approach would be to just do

append_arg "$cfg" cert "-C" "$UHTTPD_CERT"
append_arg "$cfg" key  "-K" "$UHTTPD_KEY"

So it will fallback to already resolved values and at least don’t fail, if key and cert are both missing.

Unfortunately, this can cause other problems comes with LuCI, where there is easily possible to screw up the upload completely and for example delete the certificate option and keeping the key option.

In this example UHTTPD_KEY will contain new key and UHTTPD_CERT will contain unrelated old certificate, which is wrong and again uhttpd fail to start completely.

After reading the source code of the init script, it seems, that the default fallback values never worked, so it would be safe to do solution like this

config_get UHTTPD_KEY  "$cfg" key
config_get UHTTPD_CERT "$cfg" cert

This is also more robust to wrong configurations from LuCI because at least pure HTTP will be available in most cases.

Default values /etc/uhttpd.key and /etc/uhttpd.crt are still present in default uci config, so nothing should change for anybody and it will just be more robust to wrong configuration from LuCI.

02.11.20214118Base systemBug ReportVery LowLowlogread crashes sometimesTrunkUnconfirmed Task Description

logread is dying several times a day here.
This is with r17950 and at least ath79 and mpc85xx and ramips.

Tue Nov  2 17:12:05 2021 kern.info kernel: [ 3745.330244] do_page_fault(): sending SIGSEGV to logread for invalid write access to 00000000
Tue Nov  2 17:12:05 2021 kern.info kernel: [ 3745.338789] epc = 77de87ac in libc.so[77d60000+a5000]
Tue Nov  2 17:12:05 2021 kern.info kernel: [ 3745.343833] ra  = 004017b3 in logread[400000+3000]

for checking if the log-service is healthy, we do regularly:

ubus call network.device status
ubus call log read
logread >/dev/null

The last call has (when failing) always RC = 139 with above message in log.

30.10.20214116KernelBug ReportVery LowHighqca9560-eth supports jumbo frames but is limited to 151...TrunkUnconfirmed Task Description

- Device problem occurs on
GL.iNet GL-AR750S (NOR)

- Software versions of OpenWrt/LEDE release, packages, etc.
Trunk

- Steps to reproduce

Attempt to increase the mtu beyond 1516

ifconifg eth0 mtu 1517


According to all resources the QCA9560 supports jumbo frames, as does the switch (AR8337) in this device however for an undocumented unknown reason it’s hard coded in `linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c:1640` to `1540`. Also for reasons I do not understand I can not increase the mtu beyond 1516 up to this limit of `1540` which I need for 802.11q (1522 frame size).

This code seems to need to be reviewed by someone with access to the datasheets for the QCA9560 to properly resolve this issue.

29.10.20214115Base systemBug ReportVery LowHighWireless device is always disabled when using STA+AP wi...openwrt-21.02Unconfirmed Task Description

root@OpenWrt:~# opkg list | grep ath10k
ath10k-board-qca4019 - 20201118-3
ath10k-firmware-qca4019-ct - 2020-11-08-1
kmod-ath10k-ct - 5.4.154+2021-09-22-e6a7d5b5-1
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID=’OpenWrt’ DISTRIB_RELEASE=’21.02.1’ DISTRIB_REVISION=’r16325-88151b8303’ DISTRIB_TARGET=’ipq40xx/generic’ DISTRIB_ARCH=’arm_cortex-a7_neon-vfpv4’ DISTRIB_DESCRIPTION=’OpenWrt 21.02.1 r16325-88151b8303’ DISTRIB_TAINTS=’’

I am running Openwrt on my new Fritzbox 4040.
I would like to make it my camping wifi AP, therefore I have installed travelmate.
Sadly it does not work as it should.
After every reboot, every and every change to the “Client” or “Master” Device, the “Client” Wifi is always disabled and has to be enabled manually. Also sometimes it takes ages to even get it going - with constant resetting of the device.
Also if the client wifi channels change, the AP+STA “Construct” does not work most of the time, even if enabled manually. This is by far not an ideal experience.
I am not sure if it additionally has something to do with DFS, thats why I have left my bug report at the ath10-ct github open. But greearb meant I should also contact you guys here.

https://github.com/greearb/ath10k-ct/issues/189 I have posted a syslog and dmesg there.

29.10.20214114Base systemBug ReportVery LowLowR7800 radio0 (5ghz) is locked at 40 or 153 at 80mhz wid...TrunkUnconfirmed Task Description

- Device problem occurs on Netgear R7800
- Software versions OpenWRT 21.02.1 r16325-88151b8303
- Steps to reproduce

1. Set radio0 (5ghz) channel to any channel that is not 40 or 153 at 80mhz width.
2a. If the manual channel selection frequency is within the 80mhz width of channels 40 or 153, radio0 will broadcast a wifi network that is actually at 40 or 153 (according to the Channel Analyzer feature).
2b. If the manual channel selection frequency is outside the above limits, radio0 will be disabled.

 

I am not sure if this is a hardware limitation of the R7800 or related to DFS but the tested channels should be outside the TDWR frequency range.

dmesg log with a test of the channel set outside the 80mhz width of 40 and 153 (ex: 60, 116, 144) so the radio is disabled. Then the channel is set to 40/153 and it ends up working.

[ 2897.661980] br-lan: port 3(wlan0) entered disabled state
[ 2897.664209] device wlan0 left promiscuous mode
[ 2897.666424] br-lan: port 3(wlan0) entered disabled state
[ 2903.621030] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
[ 2903.621056] ath10k_pci 0000:01:00.0: msdu-desc: 2500 skid: 32
[ 2903.703062] ath10k_pci 0000:01:00.0: wmi print ‘P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0’ [ 2903.703912] ath10k_pci 0000:01:00.0: wmi print ‘free: 84920 iram: 13156 sram: 11224’ [ 2904.090785] ath10k_pci 0000:01:00.0: rts threshold -1
[ 2904.091643] ath10k_pci 0000:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
[ 2910.104019] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
[ 2910.104045] ath10k_pci 0000:01:00.0: msdu-desc: 2500 skid: 32
[ 2910.186082] ath10k_pci 0000:01:00.0: wmi print ‘P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0’ [ 2910.186928] ath10k_pci 0000:01:00.0: wmi print ‘free: 84920 iram: 13156 sram: 11224’ [ 2910.573428] ath10k_pci 0000:01:00.0: rts threshold -1
[ 2910.573700] ath10k_pci 0000:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
[ 2910.579716] br-lan: port 3(wlan0) entered blocking state
[ 2910.588492] br-lan: port 3(wlan0) entered disabled state
[ 2910.594228] device wlan0 entered promiscuous mode
[ 2910.920831] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 2910.921053] br-lan: port 3(wlan0) entered blocking state
[ 2910.926269] br-lan: port 3(wlan0) entered forwarding state


26.10.20214112KernelBug ReportVery LowMediumbcm53xx: vlan break with kernel 5.10.xxxTrunkUnconfirmed Task Description

Target: bcm53xx
Device: Asus RT-AC88u
Version: OpenWrt SNAPSHOT, r17818

When trying to use a Vlan configuration with Kernel 5.10.xxx, I cannot use the tagged guest Vlan. Neither a connection nor a ping to the gateway of the guest network is possible. The same configuration under OpenWrt 21.02.0, r16279 (Kernel 5.4.143), the configuration works as expected. Please read the contents of / etc / config / network.

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 'fd3f:f501:9a6f::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        option igmp_snooping '1'

config bridge-vlan                                                                                   
        option device 'br-lan'                                                                       
        option vlan '1'                                                                              
        list ports 'lan1:u*'                                                                         
        list ports 'lan2:u*'                                                                         
                                                                                                     
config bridge-vlan                                                                                   
        option device 'br-lan'                                                                       
        option vlan '3'                                                                              
        list ports 'lan1:t'                                                                          
        list ports 'lan3:u*'                                                                         
                                                                                                     
config device                                                                                        
        option type 'bridge'                                                                         
        option name 'br1'                                                                            
        list ports 'br-lan.1'                                                                        
        option igmp_snooping '1'                                                                     
                                                                                                     
config device                                                                                        
        option type 'bridge'                                                                         
        option name 'br3'                                                                            
        list ports 'br-lan.3'                                                                        
        option igmp_snooping '1'                                                                     
                                                                                                     
config interface 'lan'                                                                               
        option proto 'static'                                                                        
        option netmask '255.255.255.0'                                                               
        option ip6assign '60'                                                                        
        option ipaddr '192.168.5.111'                                                                
        option gateway '192.168.5.1'                                                                 
        option broadcast '192.168.5.255'                                                             
        list dns '192.168.5.1'                                                                       
        option device 'br1'                                                                          
        option metric '50'

config interface 'guest'                                                                             
        option proto 'static'                                                                        
        option netmask '255.255.255.0'                                                               
        option ip6assign '60'                                                                        
        option ipaddr '192.168.190.2'                                                                
        option gateway '192.168.190.1'                                                               
        option broadcast '192.168.190.255'                                                           
        list dns '192.168.190.1'                                                                     
        option device 'br3'                                                                          
        option metric '150'                                                                          
                                                                                                     
config interface 'wan'                                                                               
        option device 'wan'                                                                          
        option proto 'dhcp'                                                                          
                                                                                                     
config interface 'wan6'                                                                              
        option device 'wan'                                                                          
        option proto 'dhcpv6' 

A quick note of the above file:
The bridges br1 and br3 are designed as a workaround so that wifi devices can reach the tagged subnets. Without this trick, WiFi devices cannot, for example, log into the guest network. The latter applies to both the kernel 5.4.xxx and the kernel 5.10.xxx.

On the forum user @patient0 confirmed this problem with kernel version 5.10 and 5.15 with my setup, please see https://forum.openwrt.org/t/openwrt-support-for-asus-rt-ac88u/78635/135.

26.10.20214111Base systemBug ReportVery LowLowSoftware NAT offloading causing random high packet time...openwrt-21.02Unconfirmed Task Description

Just upgraded from 19.07 to 21.02.0 on my WNDR3700v4 and noticed I was getting kicked from my IRC bouncer. I couldn’t catch it as a drop rather when doing a simple ping to my server I’d see random 3 second ping.
Disabling NAT offloading I do not see this.
Using a service such as packetlosstest.com and enabling offloading I see the drops, as soon as I disable offloading it completes successfully.

I did not have this issue on 19.07 and would love to use this feature as it allows me to actually get the /full speed/ my ISP offers.
If there’s anything else you’d like me to try or some logs I could generate I’d be glad.

26.10.20214110KernelBug ReportVery LowLowAerohive HiveAP 330 kernel.gz now too large to boot as ...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: Aerohive HiveAP 330
- Software versions of OpenWrt/LEDE release, packages, etc.: Snapshot 2021-10-24 (Linux-5.10.75)
- Steps to reproduce:

 1: Sysupgrade to OpenWrt 21.02.0
 2: See the result: boot works:

```console
Hit any key to stop autoboot: 0
Hit any key to interrupt boot from flash: 0
## Booting kernel from Legacy Image at ee840000 ...

 Image Name:   POWERPC OpenWrt Linux-5.4.143
 Created:      2021-08-31  22:20:08 UTC
 Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 Data Size:    3710564 Bytes =  3.5 MB
 Load Address: 00000000
 Entry Point:  00000000
 Verifying Checksum ... OK

## Loading init Ramdisk from Legacy Image at 02000000 ...

 Image Name:   OpenWrt fake ramdisk
 Created:      2021-08-31  22:20:08 UTC
 Image Type:   PowerPC Linux RAMDisk Image (uncompressed)
 Data Size:    0 Bytes =  0 kB
 Load Address: 00000000
 Entry Point:  00000000
 Verifying Checksum ... OK

## Flattened Device Tree blob at ec000000

 Booting using the fdt blob at 0xec000000
 Uncompressing Kernel Image ... OK
 Loading Ramdisk to 10000000, end 10000000 ... OK
 Loading Device Tree to 00ffa000, end 00fffcb5 ... OK

ft_fixup_l2cache: FDT_ERR_NOTFOUND
[ 0.000000] Memory CAM mapping: 256 Mb, residual: 0Mb
[ 0.000000] Linux version 5.4.143 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16279-5cc0535800)) #0 SMP Tue Aug 31 22:20:08 2021
```

 3: Sysupgrade to OpenWrt snapshot.
 4: Upon attempted reboot, see the result: failure to boot:

```console
[mkennedy@fedora AP330]$ cat not_booting_snapshot
Hit any key to stop autoboot: 0
Hit any key to interrupt boot from flash: 0
## Booting kernel from Legacy Image at ee840000 ...

 Image Name:   POWERPC OpenWrt Linux-5.10.75
 Created:      2021-10-24  18:22:04 UTC
 Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 Data Size:    4332488 Bytes =  4.1 MB
 Load Address: 00000000
 Entry Point:  00000000
 Verifying Checksum ... OK

## Loading init Ramdisk from Legacy Image at 02000000 ...

 Image Name:   OpenWrt fake ramdisk
 Created:      2021-10-24  18:22:04 UTC
 Image Type:   PowerPC Linux RAMDisk Image (uncompressed)
 Data Size:    0 Bytes =  0 kB 
 Load Address: 00000000
 Entry Point:  00000000
 Verifying Checksum ... OK

## Flattened Device Tree blob at ec000000

 Booting using the fdt blob at 0xec000000
 Uncompressing Kernel Image ... Error: inflate() returned -5

GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover

 Loading Ramdisk to 10000000, end 10000000 ... OK
 Loading Device Tree to 00ffa000, end 00fffd46 ... OK

ft_fixup_l2cache: FDT_ERR_NOTFOUND

U-Boot 2009.11 (Jan 12 2017 - 00:27:25), Build: jenkins-HiveOS-Honolulu_AP350_Rel-245
```


23.10.20214109Base systemBug ReportVery LowMedium5GHz Device Loses 5GHz WiFi Connection When Device View...openwrt-21.02Unconfirmed Task Description

- Device problem occurs on: Linksys WRT1900AC v1

- Software versions of OpenWrt/LEDE release: OpenWrt 21.02.0 r16279-5cc0535800

   packages: wpad-openssl
             irqbalance (Changed 'enabled' from '0' to '1' in '/etc/config/irqbalance')

- Things I tried to improve issue:

 Added in Luci > startup > local startup the following commands:
 echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
 echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
 Luci > Network > DHCP and DNS: Unchecked Rebind Protection (to allow connections to private work network)
 Luci > Network > Wireless: Edit wlan1 (5GHz network) settings: Interface Configuration > Advanced Settings > Disassociate On Low Acknowledgement: Unchecked. 

- Steps to reproduce:
When I simply view the radio1 (5GHz) spectrum in Luci (Luci > Status > Channel Analysis) webpage from any of my 5GHz devices (e.g. HP Envy-17ts laptop, Samsung Galaxy Tab-A tablet or Samsung Galaxy J7 phone), its 5GHz wireless connection to the router is dropped after a few seconds (while the webpage is updating), and it often doesn’t automatically reconnect. In that case, turning device WiFi OFF then back ON (or for my laptop, switching to airplane mode ON, waiting a bit, then back to OFF) is often required to restore the 5GHz wireless connection. Note: it’s the 5GHz connection between the device viewing the 5GHz webpage and the router that is dropped; The 5GHz radio1 on the router stays on (as verified by the logs and viewing 5GHz webpage from a 2.4GHz device, see below).

When I check the radio0 (2.4GHz) spectrum in Luci (Luci > Status > Channel Analysis) webpage from any of my 5GHz wireless devices, its 5GHz connection to the router never drops.

When I check the radio0 (2.4GHz) or radio1 (5GHz) spectrum in Luci (Luci > Status > Channel Analysis) webpages from any of my 2.4GHz devices, its 2.4GHz connection to the router never drops.

I’ve attached both Kernel and System logs.
Please let me know if you need additional info.
Thank you for your assistance!
Ed

23.10.20214105Base systemBug ReportVery LowHighfw3 crashes when a device name is too long, leaving dev...openwrt-21.02Unconfirmed Task Description

After connecting to a PPPoE, fw3 crashes and leave the router completely isolated from internet.
It happens with multiple targets. This is from x86/64 in a VM:

Thu Dec 31 23:05:49 2020 user.notice firewall: Reloading firewall due to ifup of xxx (xxx)
Thu Dec 31 23:05:49 2020 kern.info kernel: [   34.632472] fw3[3409]: segfault at 293531f0 ip 0000000000409353 sp 00007ffec12378f0 error 4 in fw3[404000+f000]
Thu Dec 31 23:05:49 2020 kern.info kernel: [   34.632508] Code: 41 00 48 89 c6 e9 48 ff ff ff 48 8b 7c 24 08 48 8d 54 24 40 be e5 36 41 00 e8 2b bb ff ff eb ad 31 db 48 8b 44 24 08 48 ff c3 <48> 8b b8 c8 00 00 00 39 98 c0 00 00 00 7e 0c 48 8b 3c df ff 15 84

If I manually restart the firewall:

* Forward 'vpn' -> 'lan'
   * Zone 'lan'
   * Zone 'wan'
     ! Exception: interface name `pppoe-wanb_pppoe' must be shorter than IFNAMSIZ (15)     ! Skipping due to previous exception (code 2)
Segmentation fault

The issue is only visible using a non-network console as after the firewall is gone, iptables is in a drop-all state.

fw3 should ignore the interface but not crash when this situation happens.
luci should prevent interface names/device names that will extrapolate IFNAMSIZ, specially PPPoE.
netifd should limit the number of extra chars in a device prefix (i.e.: “br-”, “3g-”) to make luci checks easier.

22.10.20214104Base systemBug ReportVery LowMediumnetifd: new bridge vlan ports are not applied correctly...TrunkUnconfirmed Task Description

If a bridge is created without any members, and vlan members are added later on, a reload of netifd does not properly create the bridge. A second reload of netifd is required for the bridge to appear.

The following network configuration can be used to reproduce the issue:

config device 'switch0'
	option name 'switch0'
	option type 'bridge'

config bridge-vlan 'switch0_4'
	option device 'switch0'
	option vlan '4'

config bridge-vlan 'switch0_5'
	option device 'switch0'
	option vlan '5'

Restart netifd. Add ports to bridge-vlans:

uci set network.switch0_4.ports='eth0:t eth1:* eth2:* eth4:*'
uci set network.switch0_5.ports='eth0:* eth2:t'

Reload netifd. The bridge configuration seems to be applied correctly, but the bridge is not created. A second reload of netifd is required. Starting the bridge manually (ifup switch0) also works.

Adding additional ports to an already existing and started bridge works as expected. Therefore, the bridge option

option bridge_empty '1'

can be used to work around this problem.

Restarting netifd instead of reloading also works as expected.

22.10.20214103Base systemBug ReportVery LowLowMeraki MR33 5G radio : cannot maintain high channelsTrunkUnconfirmed Task Description

OpenWrt 19.07.8 r11364-ef56c85848 / LuCI openwrt-19.07 branch git-21.189.23240-7b931da

Name the affected device
Meraki MR33

What does it do that it should not do / what does it not do that it should do
5G Channels statically set (radio0) are ending up dropping to lower channels
Affects other high channels but will zero in on one example, channel 165
Note: Country set to GB

Steps to reproduce
As a test I set radio0 to 165 but in the morning was running on 52

What you have already done to workaround/fix the problem
fix to channel 48

Any additional info you think is important
I can get you one to play with remotely if it helps

21.10.20214102Base systemBug ReportVery LowHighnetifd intermittently fails to bring up wireguard inter...openwrt-21.02Unconfirmed Task Description

I have a wireguard interface that is defined in UCI, which normally works well. Sometimes following a device reboot, wireguard will not be brought up at all. When I then try to bring up the interface manually using “ifup wg0”, the wireguard.sh setup code is not even called. Rebooting the router beings back normal wireguard functionality.

I have seen this on 21.02 (ramips & ath79), 21.02-rc3 (ramips), and 19.07.3 (ar71xx).

It happens most frequently following an automatic 3am reboot. It is difficult to reproduce on demand in the middle of the day. I can cause it to happen in about 20% of 3am reboots by using a domain name for the wireguard peer which is a CNAME pointing to a CNAME pointing to a CNAME pointing to an A record.

@vgaetera thinks there might be a race condition in netifd, which is why I have tagged this report.

I have several routers in this state presently and can do any requested testing on them.

Other people are also seeing the same issue. One person reports seeing the issue also when using an ip address for the peer (no DNS). A link to the forum discussion is https://forum.openwrt.org/t/wireguard-interfaces-sometimes-do-not-come-up-automatically-in-21-02/106012

20.10.20214100Base systemBug ReportVery LowLowSQUASHFS errors with OpenWrt 21.02TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

Western Digital My Net N750

- Software versions of OpenWrt/LEDE release, packages, etc.

openwrt-21.02.0

strongswan, dnscrypt-proxy2, avahi-utils, luci-app-ddns

- Steps to reproduce

I installed openwrt-21.02.0-ath79-generic-wd_mynet-n750-squashfs-sysupgrade.bin on a Western Digital My Net N750 that had been running openwrt-19.

The router seemed okay initially but after power cycling, it started reporting errors:

Oct 17 12:20:37 router2 kernel: [ 38.613970] SQUASHFS error: xz decompression failed, data probably corrupt
Oct 17 12:20:37 router2 kernel: [ 38.621029] SQUASHFS error: squashfs_read_data failed to read block 0x23686e
Oct 17 12:20:37 router2 kernel: [ 38.628199] SQUASHFS error: Unable to read fragment cache entry [23686e]
Oct 17 12:20:37 router2 kernel: [ 38.635010] SQUASHFS error: Unable to read page, block 23686e, size 16b28

The filesystem problem would leave some random file damaged, so different services would fail. Over time, the router became less and less functional as various files became inaccessible and after a few cycles, wouldn’t boot at all.

I wondered if there was a problem with my old configuration on the new release (though I’m not sure how that could damage the squashfs), so I reinstalled a few more times in different ways, e.g., doing a factory install (openwrt-21.02.0-ath79-generic-wd_mynet-n750-squashfs-factory.bin and then the upgrade) instead of just the upgrade, and configuring from scratch rather than from the backup. But each time I had the same problem with the router.

It wasn’t the same block on different installs, I noticed, but it seemed to be consistent for a particular installation attempt.

Oct 17 16:11:14 router2 kernel: [ 53.182571] SQUASHFS error: xz decompression failed, data probably corrupt
Oct 17 16:11:14 router2 kernel: [ 53.189582] SQUASHFS error: squashfs_read_data failed to read block 0x21e9e6
Oct 17 16:11:14 router2 kernel: [ 53.196749] SQUASHFS error: Unable to read fragment cache entry [21e9e6]
Oct 17 16:11:14 router2 kernel: [ 53.203559] SQUASHFS error: Unable to read page, block 21e9e6, size fd9c

Once there were two blocks (I think this is a reboot of the install above):

Oct 17 16:29:04 router2 kernel: [ 78.505075] SQUASHFS error: xz decompression failed, data probably corrupt
Oct 17 16:29:04 router2 kernel: [ 78.512103] SQUASHFS error: squashfs_read_data failed to read block 0x1e6e76
Oct 17 16:29:05 router2 kernel: [ 79.111366] SQUASHFS error: xz decompression failed, data probably corrupt
Oct 17 16:29:05 router2 kernel: [ 79.118386] SQUASHFS error: squashfs_read_data failed to read block 0x21e9e6
Oct 17 16:29:05 router2 kernel: [ 79.125565] SQUASHFS error: Unable to read fragment cache entry [21e9e6]
Oct 17 16:29:05 router2 kernel: [ 79.132445] SQUASHFS error: Unable to read page, block 21e9e6, size fd9c

One time there was first a jffs error, followed by lots of squashfs errors. Sorry, I don’t have the log for that one.

I now realize that I should have tried power cycling a clean install a few times to see if there were errors right away or if they only happened after files were installed/changed.

To check whether the router was just having a hardware problem, I reinstalled openwrt-19.07.8 and configured it the same. I have not seen any errors after a few power cycles, which points to a problem with the new release. I did not see any bug reports on this tracker that mention squashfs problems and googling, I did not find any useful discussions, hence this bug report.

I guess it could be that the new release uses a bad bit of memory that the earlier release managed to miss. I looked for but didn’t find a memory test utility, so I don’t know how to examine that possibility. Though the fact that it was different blocks each time makes it not sound like a hardware problem.

20.10.20214099Base systemBug ReportVery LowLowMesh 802.11s blackhole due to bogus mpath routes with n...TrunkUnconfirmed Task Description

- Device problem occurs on: reported by a few users on different devices, I am using a mediatek based one

- I am experiencing this on current master, ade56b8d9e

- Steps to reproduce: I am not sure what exactly triggers this, the bug happens on its own periodically, if anyone has suggestions on specific actions to do to try to replicate it, please let me know

What happens:

Connection to the root mesh node is lost, but inspecting the status of the mesh links with “iw mesh0 station dump” or “iw mesh1 station dump” shows the links are active.

Inspecting “iw mesh0 mpath dump” or “iw mesh1 mpath dump” show a list of mac addresses which are from devices in the LAN, with an invalid next hop (00:00:00:00:00:00), which for some reason end up in the mesh routing table and fill it.

For example, when the problem starts showing up, the mesh routing table may look as follows:

iw mesh1 mpath dump
DEST ADDR         NEXT HOP          IFACE	SN	METRIC	QLEN	EXPTIME		DTIM	DRET	FLAGS	HOP_COUNT	PATH_CHANGE
16:dd:0c:a4:ba:aa 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
fc:93:c3:3b:0b:fe 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
90:f4:c0:8f:de:80 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
bc:a1:da:cb:87:a8 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
1e:f7:95:47:4a:b3 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
3a:e2:e6:88:65:fb 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
6c:cd:48:37:af:bc 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
d8:54:0b:7c:20:46 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
ce:43:28:84:44:7e 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
26:75:58:0b:39:18 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
80:3f:5d:**:**:** 80:3f:5d:**:**:** mesh1	0	4857	0	0	0	0	0x10	1	1

After one minute, the size may have doubled or tripled.

At some point one of the mesh nodes ends up in the routing table with a bogus route (with nexthop 00:00:00:00:00:00), which basically screws up routing 100%, until that happens, the other rough mesh routes do not cause issues, but once the black hole appears, removing the bogus mesh routes does not fix it, only turning off wifi and then on again fixes it.

Showing tasks 1 - 50 of 1367 Page 1 of 281 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing