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.

OpenedIDCategory  ascTask TypePrioritySeveritySummaryReported 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


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

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


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.

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.

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

 


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

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.

04.11.20214120Base systemBuild FailureVery LowLowProblems compiling starting from trunk (or from openwr...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on Tp-link Archer C2600
- Software versions of OpenWrt from Trunk
- Steps to reproduce:

Download “master” from Git:
#git clone https://git.openwrt.org/openwrt/openwrt.git master
#cd master
#git pull
#./scripts/feeds update -a
#./scripts/feeds install -a
#make menuconfig
#make -j 1 V=s

- compilation stops very early with errors about Ninja and Meson

Tryed make clean, make dirclean, make distclean → same results.

ALL REPEATED 3 times!

then:

#git checkout v21.02.0
#git pull
#./scripts/feeds update -a
#./scripts/feeds install -a
#make menuconfig
#make -j 1 V=s

- I can see logs about ninja and meson compiling right
- compilation stops after long time with error about libcap

then:

#git checkout master
#git pull
#./scripts/feeds update -a
#./scripts/feeds install -a
#make menuconfig
#make -j 1 V=s

- compiling goes right

It seems impossible to compile master or 21.02 at fist time: may be something wrong in master make file about compiling ninja and meson packages so for 21.02 compiling libcap package?

 


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.

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.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.

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.

20.10.20214098Base systemBug ReportVery LowLowMESH-SAE-AUTH-BLOCKEDTrunkUnconfirmed Task Description

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

- I am experiencing this on current master, revision r2857+4-9d994f35b4

- Steps to reproduce: it randomly occurs some times when the root node of a mesh using plain 802.11s (mesh mode) + SAE/PSK2 authentication is rebooted (or a power outage), in order to replicate it, one would have to keep on rebooting aggressively until it happens. Maybe turning off and on wifi may be able to replicate it as well

What happens?

Some times, the devices in a mesh can’t connect each other after a power outage or a reboot of the root node (the node which is connected to the gateway and allows the rest of the mesh to connect to the internet).

Log lines:

Oct 20 13:04:40 OpenWrt wpa_supplicant[1335]: mesh0: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1a
Oct 20 13:04:47 OpenWrt wpa_supplicant[1335]: mesh1: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1b
Oct 20 13:04:59 OpenWrt wpa_supplicant[1335]: mesh0: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1a
Oct 20 13:05:01 OpenWrt wpa_supplicant[1335]: mesh1: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1b
Oct 20 13:05:11 OpenWrt wpa_supplicant[1335]: mesh0: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1a
Oct 20 13:05:12 OpenWrt wpa_supplicant[1335]: mesh1: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1b
Oct 20 13:05:24 OpenWrt wpa_supplicant[1335]: mesh0: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1a
Oct 20 13:05:24 OpenWrt wpa_supplicant[1335]: mesh0: MESH-SAE-AUTH-BLOCKED addr=*0:3f:5d:**:**:1a duration=300
Oct 20 13:05:26 OpenWrt wpa_supplicant[1335]: mesh1: MESH-SAE-AUTH-FAILURE addr=*0:3f:5d:**:**:1b
Oct 20 13:05:26 OpenWrt wpa_supplicant[1335]: mesh1: MESH-SAE-AUTH-BLOCKED addr=*0:3f:5d:**:**:1b duration=300

When this happens, the links show up in “iw mesh0 station dump” or “iw mesh1 station dump” but in BLOCKED state.

Rebooting the nodes which have their link blocked at the same time fixes the issue, which seems to rule out an interference issue, because how can a reboot fix an interference issue?

I also tried setting “cell_density ‘1’” in the configuration of the radios, but the problem keep happening, it doesn’t happen often, but when it happens it can wreak havoc.

The mesh configuration is the following:

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option htmode 'HT20'
	option disabled '0'
	option log_level '0'
	option legacy_rates '0'
	option country 'US'
	option cell_density '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option htmode 'VHT80'
	option disabled '0'
	option log_level '0'
	option channel '40'
	option country 'US'
	option cell_density '1'

config wifi-iface 'wifi_mesh0'
	option device 'radio0'
	option ifname 'mesh0'
	option mode 'mesh'
	option encryption 'psk2+ccmp'
	option key '***************'
	option mesh_id '***************'
	option network 'lan'
	option mesh_fwding '1'
	option mesh_rssi_threshold '-80'

config wifi-iface 'wifi_mesh1'
	option device 'radio1'
	option ifname 'mesh1'
	option mode 'mesh'
	option encryption 'psk2+ccmp'
	option key '***************'
	option mesh_id '***************'
	option network 'lan'
	option mesh_fwding '1'
	option mesh_rssi_threshold '-80'

config wifi-iface 'wifi_wlan0'
	option device 'radio0'
	option ifname 'wlan0'
	option mode 'ap'
	option encryption 'psk2'
	option key '***************'
	option ssid '***************'
	option network 'lan'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option rsn_preauth '1'
	option reassociation_deadline '20000'
	option ft_over_ds '1'

config wifi-iface 'wifi_wlan1'
	option device 'radio1'
	option ifname 'wlan1'
	option mode 'ap'
	option encryption 'psk2'
	option key '***************'
	option ssid '***************'
	option network 'lan'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option rsn_preauth '1'
	option reassociation_deadline '20000'
	option ft_over_ds '1'
20.10.20214097Base systemBug ReportVery LowMedium"Fails": setting TxPower to 0,1,2 dBm with mt76 on GL-M...openwrt-21.02Unconfirmed Task Description

I own a power density meter (and now how to use it) and checked how 0..20 dBm setting and applying with LuCi affects power density.

Surprising not expected result: 0,1,2 dBm result in slightly higher power densities than 20 dBm. As expected: 3 dBm is a very lowe value, increasing with higher settings up to 20 dBm.

So either the driver or the hardware does not support that values, for whatever reason; might be a bug. I found nothing in the mt7628n data sheet for this issue.

Suggestion - LuCi should not allow to set these values, or mt76 (if it’s not a bug in mt76) should set 3 dBm for 0,1,2 dBm.

19.10.20214091Base systemBug ReportVery LowLowisl: PKG_SOURCE_URL deadAllUnconfirmed Task Description

See also https://groups.google.com/g/isl-development/c/JGaMo2VUu_8

Please change tools/isl/Makefile to
PKG_SOURCE_URL:=https://sourceforge.net/projects/libisl/files/

18.10.20214090Base systemBug ReportVery LowCriticalNo configuration from ISP on Asus RT-AC85Popenwrt-21.02Unconfirmed Task Description

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

 After installing latest released OpenWrt 21.02 to AC85P I found it is not able to get network configuration from ISP - WAN interface has no IP etc. 

Some additional info:

  • My old TL-WR1043ND with OpenWrt 19.07 works good with my ISP.
  • My desktop machine and all my several laptops works good with my ISP (connecting to is directly by cable).
  • RT-AC85P with stock firmware works good with my ISP; it is getting network config from ISP.

I made a call to my ISP support informing them my router not able to get network config on what they answered “my router doesn’t sends its MAC address”.

An appropriate forum thread: https://forum.openwrt.org/t/no-configuration-from-isp-on-asus-rt-ac85p/108056/12

18.10.20214089Base systemBug ReportVery LowMediumTP-Link Archer C7 v5 - TEMPer1 (USB HID Device) not rec...openwrt-21.02Unconfirmed Task Description

I am using a TEMPer1 device and when connecting it to an Archer C7 v5, it is not recognized. In the log, there are following errors:

Mon Oct 18 19:25:57 2021 kern.info kernel: [ 407.582498] usb 1-1: new low-speed USB device number 2 using ehci-platform
Mon Oct 18 19:26:12 2021 kern.err kernel: [ 422.842461] usb 1-1: device descriptor read/64, error -145
Mon Oct 18 19:26:27 2021 kern.err kernel: [ 438.282399] usb 1-1: device descriptor read/64, error -145
Mon Oct 18 19:26:28 2021 kern.info kernel: [ 438.552372] usb 1-1: new low-speed USB device number 3 using ehci-platform
Mon Oct 18 19:26:43 2021 kern.err kernel: [ 453.882301] usb 1-1: device descriptor read/64, error -145
Mon Oct 18 19:26:58 2021 kern.err kernel: [ 469.322235] usb 1-1: device descriptor read/64, error -145
Mon Oct 18 19:26:59 2021 kern.info kernel: [ 469.442282] usb usb1-port1: attempt power cycle
Mon Oct 18 19:26:59 2021 kern.info kernel: [ 469.912231] usb 1-1: new low-speed USB device number 4 using ehci-platform
Mon Oct 18 19:27:10 2021 kern.err kernel: [ 480.512195] usb 1-1: device not accepting address 4, error -145
Mon Oct 18 19:27:10 2021 kern.info kernel: [ 480.662196] usb 1-1: new low-speed USB device number 5 using ehci-platform
Mon Oct 18 19:27:20 2021 kern.err kernel: [ 491.232218] usb 1-1: device not accepting address 5, error -145
Mon Oct 18 19:27:20 2021 kern.err kernel: [ 491.252221] usb usb1-port1: unable to enumerate USB device

I am using this device without any issues on other devices (e.g. TP-Link TL-WR842N/ND v2, Netgear WNDR3800, Netgear WNDR3800).

This errors occur in OWRT 19.07.8 as well as in OWRT 21.02.0.
The packages kmod-hid, kmod-hid-generic and kmod-usb-hid are installed.

16.10.20214087Base systemBug ReportVery LowLowCannot use vlan 1 tagged with DSA in WRT1900ACS v2openwrt-21.02Unconfirmed Task Description

Hello,

No matter what I change, I cannot create a wan.1 interface. Any other vlan id works:

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

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.4'
        option gateway '192.168.1.1'

config interface 'lan6'
        option proto 'dhcpv6'
        option device 'br-lan'
        option reqaddress 'try'
        option reqprefix 'auto'

config device
        option name 'br-guest'
        option type 'bridge'
        list ports 'wan.3'

config interface 'guest'
        option proto 'none'
        option device 'br-guest'

config device
        option type '8021q'
        option ifname 'wan'
        option vid '3'
        option name 'wan.3'

config device
        option type '8021q'
        option ifname 'wan'
        option vid '2'
        option name 'wan.2'

config interface 'test'
        option proto 'none'
        option device 'wan.1'

config device
        option type '8021q'
        option ifname 'wan'
        option vid '1'
        option name 'wan.1'

I want to add wan.1 to br-lan but the virtual device (wan.1) is never created. I created a test interface just to try to bring it up alone, but nothing made wan.1 appears.

I also tried ip-full and it also failed:

root@ap4:/etc/config# ip link add link wan name wan.1 type vlan id 2
root@ap4:/etc/config# ip link add link wan name wan.1 type vlan id 1
RTNETLINK answers: Not supported

Why vlan 1 is prohibit?

15.10.20214086Base systemBug ReportVery LowMediumedgerouter 6p : missing usb3 support in initramfsTrunkUnconfirmed Task Description

I had to add these lines :

CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PLATFORM=y

in openwrt/target/linux/octeon/config-5.4. Otherwise there is no /dev/sda1 device available for installing.

14.10.20214085Base systemBug ReportVery LowLowdnsmasq: cannot open or create lease file /tmp/dhcp.lea...TrunkUnconfirmed Task Description

with a selfcompiled r17753 with mipsel ramips/mt7621 on ‘TP-LINK Archer C6U’ It was working without these issues with r17560

Thu Oct 14 18:32:38 2021 user.err : jail: creat(/tmp/ujail-lhNbFK/tmp/dhcp.leases) failed: Read-only file system
Thu Oct 14 18:32:38 2021 daemon.crit dnsmasq[1]: cannot open or create lease file /tmp/dhcp.leases: Read-only file system
Thu Oct 14 18:32:38 2021 daemon.crit dnsmasq[1]: FAILED to start up
Thu Oct 14 18:32:43 2021 user.err : jail: creat(/tmp/ujail-FlhCEP/tmp/dhcp.leases) failed: Read-only file system
Thu Oct 14 18:32:43 2021 daemon.crit dnsmasq[1]: cannot open or create lease file /tmp/dhcp.leases: Read-only file system
Thu Oct 14 18:32:43 2021 daemon.crit dnsmasq[1]: FAILED to start up
Thu Oct 14 18:32:49 2021 user.err : jail: creat(/tmp/ujail-fHEJCC/tmp/dhcp.leases) failed: Read-only file system
Thu Oct 14 18:32:49 2021 daemon.crit dnsmasq[1]: cannot open or create lease file /tmp/dhcp.leases: Read-only file system
Thu Oct 14 18:32:49 2021 daemon.crit dnsmasq[1]: FAILED to start up
Thu Oct 14 18:32:50 2021 daemon.alert kalua: /usr/sbin/cron.monitorin: curl_it() [ERR] returning 4 after fetching 'http://intercity-vpn.de/networ...'
Thu Oct 14 18:32:54 2021 user.err : jail: creat(/tmp/ujail-jGfjpp/tmp/dhcp.leases) failed: Read-only file system
Thu Oct 14 18:32:54 2021 daemon.crit dnsmasq[1]: cannot open or create lease file /tmp/dhcp.leases: Read-only file system
Thu Oct 14 18:32:54 2021 daemon.crit dnsmasq[1]: FAILED to start up
Thu Oct 14 18:32:59 2021 user.err : jail: creat(/tmp/ujail-knefoG/tmp/dhcp.leases) failed: Read-only file system
Thu Oct 14 18:32:59 2021 daemon.crit dnsmasq[1]: cannot open or create lease file /tmp/dhcp.leases: Read-only file system
Thu Oct 14 18:32:59 2021 daemon.crit dnsmasq[1]: FAILED to start up
Thu Oct 14 18:33:02 2021 daemon.alert kalua: /usr/sbin/cron.monitorin: curl_it() [ERR] returning 4 after fetching 'http://intercity-vpn.de/networ...'
Thu Oct 14 18:33:04 2021 user.err : jail: creat(/tmp/ujail-jneGLN/tmp/dhcp.leases) failed: Read-only file system
Thu Oct 14 18:33:04 2021 daemon.crit dnsmasq[1]: cannot open or create lease file /tmp/dhcp.leases: Read-only file system
Thu Oct 14 18:33:04 2021 daemon.crit dnsmasq[1]: FAILED to start up
Thu Oct 14 18:33:04 2021 daemon.info procd: Instance dnsmasq::cfg01411c s in a crash loop 6 crashes, 0 seconds since last crash

The filesystem looks normal:

root@box:~ :) df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.5M      5.5M         0 100% /rom
tmpfs                    59.4M      1.3M     58.1M   2% /tmp
/dev/mtdblock4            7.4M    476.0K      7.0M   6% /overlay
overlayfs:/overlay        7.4M    476.0K      7.0M   6% /
tmpfs                   512.0K         0    512.0K   0% /dev

root@liszt28-hybrid--37:~ :) echo foo >/tmp/dhcp.leases.txt 

root@liszt28-hybrid--37:~ :) ls -l /tmp/dhcp.leases.txt
-rw-r--r--    1 root     root             4 Oct 14 18:37 /tmp/dhcp.leases.txt

root@liszt28-hybrid--37:~ :) ps | grep jail
 3898 root      2616 S    {hostapd} /sbin/ujail -n hostapd -U network -G network -C /etc/capabilities/wpad.json -c -- /usr/sbin/hostapd -s -g /var/run/hostapd/global
 3899 root      2616 S    {wpa_supplicant} /sbin/ujail -n wpa_supplicant -U network -G network -C /etc/capabilities/wpad.json -c -- /usr/sbin/wpa_supplicant -n -s -g /var/run/wpa_supplican
 4489 root      1280 S    grep jail

root@liszt28-hybrid--37:~ :) pidof dnsmasq || echo BAD
BAD

root@liszt28-hybrid--37:~ :) uci show dhcp
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].logqueries='0'
dhcp.@dnsmasq[0].domainneeded='0'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='0'
dhcp.@dnsmasq[0].rebind_localhost='0'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].addnhosts='/var/run/hosts_olsr' '/etc/local.hosts'
dhcp.@dnsmasq[0].server='8.8.8.8'
dhcp.@dnsmasq[0].notinterface='wan' 'wlan' 'wlanRADIO1'
dhcp.@dnsmasq[0].dhcpscript='/etc/dhcp-script.d/10dhcpscript'
dhcp.@dnsmasq[0].cachesize='1000'
dhcp.@dnsmasq[0].local='/internet/'
dhcp.@dnsmasq[0].domain='internet'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.start='34'
dhcp.lan.limit='13'
dhcp.lan.force='1'
dhcp.lan.ignore='0'
dhcp.lan.leasetime='48h'
dhcp.wlan=dhcp
dhcp.wlan.force='1'
dhcp.wlan.ignore='0'
dhcp.wlan.interface='mastergate'
dhcp.wlan.dhcp_option='3,100.64.0.1' '6,100.64.0.1'
dhcp.wlan.leasetime='12h'
dhcp.wlan.start='100.65.35.2'
dhcp.wlan.limit='253'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'
dhcp.@host[0]=host
dhcp.@host[0].ip='127.0.0.2'
dhcp.@host[0].mac='00:00:00:00:00:00'
dhcp.@host[0].name='lo-alias'
dhcp.@dhcp[3]=dhcp
dhcp.@dhcp[3].interface='loopback'
dhcp.@dhcp[3].start='2'
dhcp.@dhcp[3].limit='2'
dhcp.@dhcp[3].leasetime='1h'
dhcp.@dhcp[3].force='1'
dhcp.@dhcp[3].ignore='0'
14.10.20214084Base systemBug ReportVery LowHighProblem with TL-WR842N v5 wifi and static IPopenwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- TP-Link TL-WR842N v5
- OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-21.231.26241-422c175
- I set to default all the settings. After it i set static IP for wan:
config interface ‘wan’

option ifname 'eth0.2'
option proto 'static'
option gateway 'IP'
list dns '1.1.1.1'
list dns '8.8.8.8'
option netmask '255.255.255.0'
option ipaddr 'IP'

and set the wifi:

config wifi-device ‘radio0’

option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/10300000.wmac'
option htmode 'HT40'
option disabled '0'

config wifi-iface ‘wifinet1’

option ssid 'DIR-620'
option encryption 'none'
option device 'radio0'
option mode 'ap'
option network 'lan'
 

After set the settings it have connected about 8 wifi devices. After it it has regular dropdown an packets (i can see The timeout interval for the request has been exceeded. if i ping on my laptop from wifi connected)

11.10.20214082Base systemBug ReportVery LowLowNew default 'Support-UDP-Traceroute' rule might have il...TrunkUnconfirmed Task Description

As mentioned on IRC/OFTC...

<Lantizia> hmm there is a broken default ‘Traffic’ Rule’ of ‘Support-UDP-Traceroute’ on 21.02
<Lantizia> which is disabled by default... but wouldn’t work even if you enabled it as the port is 33434:33689 rather than 33434-33689
<Lantizia> is this reported anyplace? I could report it... but where would I?
<PaulFertser> Lantizia: bugs.openwrt.org is the place for reporting issues
<satmd> we’d appreciate the report :) Thank you for finding and mentioning!

This new default firewall rule (although disabled by default) seems to have been introduced with commit de8b88ce17c3e19cf1fe366be0de2e3c376762b0.

I’m not sure if the colon (rather than a hyphen) affects the possibility of this rule working if it is activated without using LuCI.

But certainly from within LuCI... if try to edit this rule and re-save it (without changing anything) then it’ll flag the field as having invalid contents and refuse to save.

If colons are valid in this context then I’ll re-file this bug to the LuCI bug tracker instead.

10.10.20214077Base systemBug ReportVery LowLowERROR level instead of INFO level in syslog messages fr...TrunkUnconfirmed Task Description

The FEATURE_SYSLOG_INFO option appeared in BusyBox v. 1.31.0. But in OpenWRT this option is disabled by default: master, openwrt-21.02 branch (in order to save about 200 bytes?!). As a result, BusyBox components (for example, crond) in syslog write all messages with the ERROR level instead of INFO level, which misleads users:

Sun Oct 10 19:07:35 2021 cron.err crond[8795]: crond (busybox 1.31.0) started, log level 5
Sun Oct 10 19:08:00 2021 cron.err crond[8795]: USER root pid 9035 cmd /usr/bin/test.sh
Sun Oct 10 19:08:00 2021 cron.err crond[8795]: USER root pid 9036 cmd echo "hello"


09.10.20214074Base systemBug ReportVery LowHighRandom Traffic Stalls on ZBT WG3526 on WiFiopenwrt-21.02Unconfirmed Task Description

Problem occurs on the ZBT WG3526 Arch MediaTek MT7621 ver:1 eco:3

When transferring large amounts of data across the 5Ghz band the WiFi radio will randomly stop sending or receiving packets in the default radio configuration. In order to restore connectivity the client device must disassociate from the AP and then re-associate (accomplished by disabling and re-enabling the WiFi on the laptop/device). Then traffic flows normally again until the next drop. This occurs at random intervals and when under heavy traffic load such as a multi-gigabyte file transfer. The device does not have the same issue with wired clients on the switchports.

Tested with three different devices, two with Intel Pro Wireless cards and the other with an embedded Mediatek WiFi chip. All three will randomly experience these drops. I also tried changing channels from 36 to 149 to verify it wasn’t some sort of band interference.

As additional testing I configured an GL.iNet AR750S with the same version of OpenWRT (21.02 release) with the same default AP settings on the original band 36 (leaving the WG3536 on 149 to avoid interference). After testing for 2 days I have experienced none of the same drops on the exact same three devices. I have also hammered an iPerf3 server for 20-30 minutes straight without experiencing the same issues.

This device was originally working fine on 18.06.9 and only started to experience these problems after upgrading to 21.02. I have not yet reverted to 18.06.9 as a test, but the problems started immediately after the upgrade. I have also since clean installed OpenWRT 21.02 from firmware recovery on the device to verify it wasn’t some sort of bad flash issue.

Not sure if related but I do keep seeing the following messages in the kernel log once and a while and I know hostapd runs the Access Point SSIDs, so it’s possible the service is crashing and then restarting:

[53077.551539] Out of memory: Killed process 2440 (hostapd) total-vm:2424kB, anon-rss:120kB, file-rss:1728kB, shmem-rss:0kB, UID:0 pgtables:20kB oom_score_adj:0
[53077.569641] oom_reaper: reaped process 2440 (hostapd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

08.10.20214072Base systemBug ReportVery LowMediumUSB 3.0 drive not able to mount when plugged into 3.0 p...openwrt-21.02Unconfirmed Task Description

*Log is provided in link below please don’t skip this!* The

Bought a new external USB 3.0 enclosure for SMB. Installed 2TB drive in said enclosure, hooked it up and cannot get it to be recognized when plugged into the USB 3.0 port on my Asus AC68U. It does work on the 2.0 port. And it does work on 3.0 port if i use a 2.0 hub. strange indeed! also note that the USB 3.0 port does correctly identify and mount 2 other 3.0 drives I have.

See here for more info: https://forum.openwrt.org/t/openwrt-21-02-asus-ac68u-unable-to-see-usb-3-0-drives/107161/5 and here: https://bugs.openwrt.org/index.php?do=details&task_id=1862

I did try editing /etc/modules.d/usb-storage to add quirks=VID:PID:u after usb-storage (on the same line). VID/PID must be of your UAS device. kmod-usb-storage-uas should be installed. Reboot for the changes to take effect.

But this this not work.

output of lsusb:
root@AC68U-43B8:~# lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux 5.4.143 ohci_hcd Generic Platform OHCI controller
Bus 004 Device 002: ID 174c:55aa RSH-339 ASM1153E
Bus 004 Device 001: ID 1d6b:0003 Linux 5.4.143 xhci-hcd xHCI Host Controller
Bus 001 Device 001: ID 1d6b:0002 Linux 5.4.143 ehci_hcd EHCI Host Controller
Bus 003 Device 001: ID 1d6b:0002 Linux 5.4.143 xhci-hcd xHCI Host Controller

the device in question is this ID 174c:55aa RSH-339 ASM1153E

root@AC68U-43B8:~# lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

  |__ Port 1: Dev 2, If 0, Class=, Driver=, 5000M

/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/2p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M


Keep in mind this device works on my USB 2.0 port as it should, but not the 3.0 port. However if I flash Tomato firmware to my AC68U then this drive has no issues being mounted while plugged into the USB 3.0 port. If I go back to OpenWRT, as I am now, it once again refuses to mount when plugged into the 3.0 port.

08.10.20214071Base systemBug ReportVery LowMedium Lantiq-VRX200 modem is using wrong line modeopenwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
- AVM Fritz 7412
- Lantiq-VRX200

- Software versions of OpenWrt/LEDE release, packages, etc.
21.02.0 (r16279-5cc0535800)

- Steps to reproduce
- Flash firmware
- Enter ISP configuration for 1&1 (https://openwrt.org/docs/guide-user/network/wan/isp-configurations)
- Download and use the modem firmware supplied by AVM: 5.9.0.12.1.7 or 5.9.1.4.0.7

Openwrt will be using: Line Mode: G.993.2 (VDSL2 with down- and upstream vectoring)
instead of: Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
which is used by the stock fritz box firmware. This results in a speed decrease from possible
Max. Attainable Data Rate (ATTNDR): 133.841 Mb/s (down) to 25.000 Mb/s (down)


08.10.20214070Base systemBug ReportVery LowLownetifd: potential use-after-free bug?TrunkUnconfirmed Task Description

While investigating an issue with an older version of netifd I came upon what appears to be a use-after free bug in the latest version of netifd (commit id: 448ffc15) in interfaces.c::interface_proto_event_cb() when handling the IFPEV_DOWN event.

Within this case there is a call to interface_handle_config_change(iface)

	case IFPEV_DOWN:
		if (iface->state == IFS_DOWN)
			return;

		netifd_log_message(L_NOTICE, "Interface '%s' is now down\n", iface->name);
		mark_interface_down(iface);
		if (iface->main_dev.dev)
			device_release(&iface->main_dev);
		if (iface->l3_dev.dev)
			device_remove_user(&iface->l3_dev);
		interface_handle_config_change(iface);
		break;

, which will free ‘iface’ if iface→config_state == IFC_REMOVE.

	case IFC_REMOVE:
		interface_do_free(iface);
		return;

‘iface’ will be invalid if this happens.

However, after this call is made the code will drop to the bottom of interface_proto_event_cb() and call

	interface_write_resolv_conf(iface->jail);

with the potentially invalid ‘iface’ pointer.

I haven’t investigated to see if it’s actually possible for iface to be in the correct state to be freed when handling this event, but it certainly looks like it has the potential to be a bug. I thought it might be wise to alert somebody to this issue. If it’s ‘impossible’ for iface to be freed at this point, perhaps it’d be worth at least adding a comment to that effect.
Regards

07.10.20214069Base systemBug ReportVery LowMediumArcher C7 v2 - 802.11w Management Frame Protection impo...openwrt-21.02Unconfirmed Task Description

Problem Device:

TP-Link Archer C7 v2

Software version:

OpenWrt 21.02.0 r16279-5cc0535800 , default packages versions.

Steps to reproduce:

Setup wireless with:
  Encryption "WPA2-PSK/WPA3-SAE Mixed Mode"
Showing tasks 1 - 50 of 1367 Page 1 of 281 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing