OpenWrt/LEDE Project

Welcome to the OpenWrt Project bug reporting and issue tracking system

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

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

OpenedIDCategoryTask TypePrioritySeveritySummaryReported In  descStatus
29.11.20214164Base systemBug ReportVery LowCriticalASUS RT-N56U reboots unexpectedly on OpenWrt 21.02.1openwrt-21.02Unconfirmed Task Description

Device the problem occurs on: Asus RT-N56U.

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

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

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

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

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

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

 OpenWrt 21.02.1, r16325-88151b8303

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

 

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


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

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

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


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

Netgear GS108T v3

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

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

Steps to reproduce:

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

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

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

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

The issue can be triggered by running iperf3:

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

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

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

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

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

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

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

Thank you for reading.

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

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

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

skge is the driver used for the following gigabit NIC:

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


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

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

The problem NIC:

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

Openwrt:
OpenWrt x86_64 21.02.1 r16325-88151b8303

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

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

Turning TSO off is a workaround.

ethtool -K eth0 tso off

but pcie_aspm=off does not help.

[49573.954931] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[49573.954931]   TDH                  <2>
[49573.954931]   TDT                  <1a>
[49573.954931]   next_to_use          <1a>
[49573.954931]   next_to_clean        <ff>
[49573.954931] buffer_info[next_to_clean]:
[49573.954931]   time_stamp           <100bbf478>
[49573.954931]   next_to_watch        <2>
[49573.954931]   jiffies              <100bbf6f8>
[49573.954931]   next_to_watch.status <0>
[49573.954931] MAC Status             <80083>
[49573.954931] PHY Status             <796d>
[49573.954931] PHY 1000BASE-T Status  <3800>
[49573.954931] PHY Extended Status    <3000>
[49573.954931] PCI Status             <10>
[49575.970909] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[49575.970909]   TDH                  <2>
[49575.970909]   TDT                  <1a>
[49575.970909]   next_to_use          <1a>
[49575.970909]   next_to_clean        <ff>
[49575.970909] buffer_info[next_to_clean]:
[49575.970909]   time_stamp           <100bbf478>
[49575.970909]   next_to_watch        <2>
[49575.970909]   jiffies              <100bbf8f0>
[49575.970909]   next_to_watch.status <0>
[49575.970909] MAC Status             <80083>
[49575.970909] PHY Status             <796d>
[49575.970909] PHY 1000BASE-T Status  <3800>
[49575.970909] PHY Extended Status    <3000>
[49575.970909] PCI Status             <10>
[49577.954909] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[49577.954909]   TDH                  <2>
[49577.954909]   TDT                  <1a>
[49577.954909]   next_to_use          <1a>
[49577.954909]   next_to_clean        <ff>
[49577.954909] buffer_info[next_to_clean]:
[49577.954909]   time_stamp           <100bbf478>
[49577.954909]   next_to_watch        <2>
[49577.954909]   jiffies              <100bbfae0>
[49577.954909]   next_to_watch.status <0>
[49577.954909] MAC Status             <80083>
[49577.954909] PHY Status             <796d>
[49577.954909] PHY 1000BASE-T Status  <3800>
[49577.954909] PHY Extended Status    <3000>
[49577.954909] PCI Status             <10>
[49578.082559] e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
[49578.254005] e1000e: eth0 NIC Link is Down
[49581.083429] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
21.11.20214143Base systemBug ReportVery LowLowImage check failed TL-WR1043ND v4openwrt-21.02Unconfirmed Task Description

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

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

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

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

The output of sysupgrade looks like this:

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

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

Wifi unstable Kernel warning in mac80211/rate.c

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

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

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

 


17.11.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.20214136KernelBug ReportVery LowHigherror loading ifbopenwrt-21.02Unconfirmed Task Description

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

 

Xiaomi Mi Router 3G (MediaTek MT7621)

OpenWrt 21.02.0, r16279-5cc0535800

# insmod ifb
failed to insert ifb

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

In dmesg:
[108588.487809] Module has invalid ELF structures

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

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

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

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

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

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

Log for that stage:

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


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

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


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

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

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

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

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

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

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

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

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

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

I also have flow offloading switched off!

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

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

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

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

I have already reported this at the forum:

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

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

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

> /tmp/sysinfo/board_name <

tplink,tl-wdr3600-v1

> /tmp/sysinfo/model <

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

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

- Steps to reproduce
not known yet

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

diagnostic informations collected, see attachments:
dmesg
logread

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

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.

 


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.

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.

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

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?

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.20214083PackagesBug ReportVery LowHighkmod-usb-net-rtl8152 resettingopenwrt-21.02Unconfirmed Task Description

Device: FriendlyARM NanoPi R2S
Openwrt version: 21.02
kmod-usb-net-rtl8152 version: 5.4.143-1

Under load the rtl8152 usb→ethernet controller periodically resets, resulting in lost connectivity.

[835268.288485] r8152 4-1:1.0 eth1: Invalid ether addr 00:00:00:00:00:00
[835268.289087] r8152 4-1:1.0 eth1: Random ether addr f6:79:cb:0d:e8:ca
[835268.294377] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[835601.651427] r8152 4-1:1.0 eth1: Tx timeout
[835603.700959] r8152 4-1:1.0 eth1: Tx status -2
[835603.701462] r8152 4-1:1.0 eth1: Tx status -2
[835603.701925] r8152 4-1:1.0 eth1: Tx status -2
[835603.702389] r8152 4-1:1.0 eth1: Tx status -2
[835604.400457] r8152 4-1:1.0 eth1: Invalid ether addr 00:00:00:00:00:00
[835604.401057] r8152 4-1:1.0 eth1: Random ether addr 1a:0c:e4:6e:e6:78
[835604.406427] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[835851.756695] r8152 4-1:1.0 eth1: Tx timeout
[835851.759988] r8152 4-1:1.0 eth1: Tx status -2
[835851.760467] r8152 4-1:1.0 eth1: Tx status -2
[835851.760989] r8152 4-1:1.0 eth1: Tx status -2
[835851.761459] r8152 4-1:1.0 eth1: Tx status -2
[835854.032456] r8152 4-1:1.0 eth1: Invalid ether addr 00:00:00:00:00:00
[835854.033097] r8152 4-1:1.0 eth1: Random ether addr 9e:77:eb:ed:04:55
[835854.038332] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[836203.747280] r8152 4-1:1.0 eth1: Tx timeout
[836205.795765] r8152 4-1:1.0 eth1: Tx status -2
[836205.796251] r8152 4-1:1.0 eth1: Tx status -2
[836205.796710] r8152 4-1:1.0 eth1: Tx status -2
[836205.797173] r8152 4-1:1.0 eth1: Tx status -2
[836206.496453] r8152 4-1:1.0 eth1: Invalid ether addr 00:00:00:00:00:00
[836206.497053] r8152 4-1:1.0 eth1: Random ether addr fe:52:21:ca:fa:03
[836206.502398] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[836561.625738] r8152 4-1:1.0 eth1: Tx timeout
[836563.674078] r8152 4-1:1.0 eth1: Tx status -2
[836563.674565] r8152 4-1:1.0 eth1: Tx status -2
[836563.675030] r8152 4-1:1.0 eth1: Tx status -2
[836563.675493] r8152 4-1:1.0 eth1: Tx status -2
[836564.384455] r8152 4-1:1.0 eth1: Invalid ether addr 00:00:00:00:00:00
[836564.385058] r8152 4-1:1.0 eth1: Random ether addr ba:63:ae:46:69:46
[836564.390679] r8152 4-1:1.0 eth1: Promiscuous mode enabled

Other reports indicate that this is due to a problem with the driver version used by OpenWRT. This problem does not arise in FriendlyWRT.

Additional info: https://github.com/jayanta525/openwrt-nanopi-r2s/issues/5

FriendlyWRT commit to workaround the issue: https://github.com/friendlyarm/rtl8812au/commit/76c3cf81fdc71af4338571b6404beb2ba3835a62

OpenWRT forum issue: https://forum.openwrt.org/t/update-kmod-usb-net-rtl8152-driver-to-avoid-usb-3-0-to-gigabit-lan-issues/65466/38

11.10.20214078KernelBug ReportVery LowHighKernel panic from rt2x00usb - rt2x00queue_for_each_entr...openwrt-21.02Unconfirmed Task Description

Device: RT5370 WiFi chip + rt2x00usb driver
OpenWRT Version: 21.02 (commit b2ae42)

We're experiencing a kernel panic causing our device to frequently reboot. It's due to an Internal error: Oops: 207, or sometimes Internal error: Oops: 206. It seems to happen often when we connect several devices to the RT5370 WiFi chip which uses the rt2x00usb driver.

It is happening on multiple devices and was not an issue for us on 18.06 (commit c3bd13).

Here's a relevant trace of the issue:

[ 4576.824582] 8<--- cut here ---
[ 4576.827674] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 4576.835810] pgd = 1b97c305
[ 4576.849425] Internal error: Oops: 207 [#1] SMP ARM
[ 4576.859700] Modules linked in: xt_connlimit rt2800usb rt2800lib pppoe ppp_async nf_conncount iptable_nat brcmfmac xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_cov
[ 4576.859858]  deflate zlib_inflate zlib_deflate cbc authenc crypto_acompress dwc3 fsl_mph_dr_of ehci_fsl
[ 4576.835810] pgd = 1b97c305
[ 4576.967462] CPU: 2 PID: 9400 Comm: kworker/u8:2 Not tainted 5.4.143 #0
[ 4576.979513] Hardware name: Allwinner sun8i Family
[ 4576.989779] Workqueue: phy1 rt2x00usb_work_rxdone [rt2x00usb]
[ 4577.001057] PC is at rt2x00queue_for_each_entry+0x378/0x618 [rt2x00lib]
[ 4577.011805] LR is at rt2x00queue_for_each_entry+0x2c0/0x618 [rt2x00lib]
[ 4577.018409] pc : [<bf3a05e4>]    lr : [<bf3a052c>]    psr: 60000013
[ 4577.024665] sp : e749dc50  ip : 00000000  fp : 00000001
[ 4577.029882] r10: e749dd60  r9 : 00000000  r8 : e778f748
[ 4577.035099] r7 : 00000000  r6 : e9bcdfa0  r5 : e71a6f00  r4 : e749dc74
[ 4577.041615] r3 : 00000006  r2 : 00000000  r1 : e856f85c  r0 : 00000006
[ 4577.048159] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[ 4577.055320] Control: 30c5387d  Table: 69bb9e40  DAC: 9f1e88c3
[ 4577.061073] Process kworker/u8:2 (pid: 9400, stack limit = 0x35a706a0)
[ 4577.067593] Stack: (0xe749dc50 to 0xe749e000)
[ 4577.071946] dc40:                                     e9b7d458 e9bcdfa0 e71a6f00 e9bccd00
[ 4577.080114] dc60: 00000000 bf3a1544 00000000 00000000 00000000 00000188 00180021 00000000
[ 4577.088281] dc80: 00000000 00000000 0000002b 00000003 00000005 00000000 00000000 00000000
[ 4577.096449] dca0: e71a6f00 e9bcdfa0 e9b7d458 e9bccd00 e749dd04 00000000 e749dd60 bf39eff4
[ 4577.104616] dcc0: 00000000 00000000 00000000 00000000 00000000 e749dd60 e749dd60 e9bccd00
[ 4577.112784] dce0: 00000000 e9bcd15c 00000000 e749dd60 00000001 bf2f1400 e778f748 e95eae28
[ 4577.120951] dd00: 00000000 e778f748 e9bccd00 e749dd60 000000d0 e9bccd00 00000021 e9bccd00
[ 4577.129119] dd20: 00000001 00000000 e749ddc8 bf2f1528 00000001 e95ea580 e71a6f00 00000000
[ 4577.137286] dd40: e95ea580 00000021 e9bccd00 bf2f8014 00000001 eb1f1c10 00000000 00000000
[ 4577.145453] dd60: e749dd60 e749dd60 00000000 00000000 e9bccd00 e95ea580 e778f000 00000000
[ 4577.153620] dd80: 00000000 00000002 68808044 e71a6f00 e95ea580 e9bccd00 e9bcd29c 00000000
[ 4577.161788] dda0: e9bcd15c bf2f97fc 00000008 e9bccd00 e749ddb0 e9bccd00 e9bcce5c bf32f75c
[ 4577.169955] ddc0: 00000000 00000000 e9bccd00 ffffffe8 e71e30c0 e749de70 e880e058 e9bcd39c
[ 4577.178121] dde0: e9bcd3a0 00000000 ef6cd498 00000000 c0c57900 00000040 c0e03080 c0243fe8
[ 4577.186289] de00: 00000000 00000006 c0e03098 c0e03080 40000006 ffffe000 00000101 c02022d8
[ 4577.194456] de20: e71e30c0 e9bccd00 e95ea580 c0c51508 c0c57900 0000000a c0c51494 0006869c
[ 4577.202624] de40: c0e03d00 c08fbeac 04208060 c08fbe74 e9bcdfa0 60000013 ffffe000 e71e30c0
[ 4577.210791] de60: ffffffe3 e7231e40 00000004 00000000 ffffe000 c0244324 000001ff c02443f0
[ 4577.218958] de80: e8f2aae0 e9bcdfa0 e71e30c0 bf39d900 000013b2 e9bcdfa0 00000000 00000000
[ 4577.227125] dea0: 00000000 ffffffe3 00000018 00000000 0000000c 00000001 00000000 00000000
[ 4577.235292] dec0: 00000000 00000000 00000000 00000000 e9bce5d8 e749def4 c0e04e50 eb29a700
[ 4577.243459] dee0: 00000000 00000100 00000000 bf3ad660 eb05c200 00000028 c08fe0c8 e749df14
[ 4577.251626] df00: bf3ad610 e9bce5d8 e86c8380 eb006200 eb29a700 e7bc6a51 e9bce5d8 e86c8380
[ 4577.259794] df20: eb006200 c02575c0 00000088 c0e03d00 e86c8380 e86c8394 eb006200 00000088
[ 4577.267961] df40: c0e03d00 eb006218 eb006200 c025785c c0e0c5f0 c08fcf78 ffffe000 e86c8380
[ 4577.276128] df60: c0257818 e9b9c000 e8cc0f80 00000000 e749c000 e86c8380 c0257818 eb131eac
[ 4577.284295] df80: e9b9c01c c025d338 00001228 e8cc0f80 c025d1ec 00000000 00000000 00000000
[ 4577.292462] dfa0: 00000000 00000000 00000000 c02011f8 00000000 00000000 00000000 00000000
[ 4577.300629] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4577.308795] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 4577.317043] [<bf3a05e4>] (rt2x00queue_for_each_entry [rt2x00lib]) from [<bf3a1544>] (rt2x00queue_write_tx_frame+0x24/0x418 [rt2x00lib])
[ 4577.329215] [<bf3a1544>] (rt2x00queue_write_tx_frame [rt2x00lib]) from [<bf39eff4>] (rt2x00mac_tx+0x88/0x358 [rt2x00lib])
[ 4577.340316] [<bf39eff4>] (rt2x00mac_tx [rt2x00lib]) from [<bf2f1400>] (ieee80211_beacon_update_cntdwn+0x29c/0xd20 [mac80211])
[ 4577.351723] [<bf2f1400>] (ieee80211_beacon_update_cntdwn [mac80211]) from [<bf2f1528>] (ieee80211_beacon_update_cntdwn+0x3c4/0xd20 [mac80211])
[ 4577.364582] [<bf2f1528>] (ieee80211_beacon_update_cntdwn [mac80211]) from [<bf2f8014>] (ieee80211_tx_prepare_skb+0x22c/0x254 [mac80211])
[ 4577.376919] [<bf2f8014>] (ieee80211_tx_prepare_skb [mac80211]) from [<bf2f97fc>] (ieee80211_tx_pending+0xac/0x258 [mac80211])
[ 4577.388262] [<bf2f97fc>] (ieee80211_tx_pending [mac80211]) from [<c0243fe8>] (tasklet_action_common.constprop.3+0x64/0xe8)
[ 4577.399295] [<c0243fe8>] (tasklet_action_common.constprop.3) from [<c02022d8>] (__do_softirq+0x120/0x2b0)
[ 4577.408851] [<c02022d8>] (__do_softirq) from [<c0244324>] (do_softirq.part.2+0x3c/0x44)
[ 4577.416845] [<c0244324>] (do_softirq.part.2) from [<c02443f0>] (__local_bh_enable_ip+0xc4/0xd4)
[ 4577.425541] [<c02443f0>] (__local_bh_enable_ip) from [<bf39d900>] (rt2x00lib_rxdone+0x250/0x5f4 [rt2x00lib])
[ 4577.435369] [<bf39d900>] (rt2x00lib_rxdone [rt2x00lib]) from [<bf3ad660>] (rt2x00usb_work_rxdone+0x50/0x90 [rt2x00usb])
[ 4577.446157] [<bf3ad660>] (rt2x00usb_work_rxdone [rt2x00usb]) from [<c02575c0>] (process_one_work+0x218/0x470)
[ 4577.456061] [<c02575c0>] (process_one_work) from [<c025785c>] (worker_thread+0x44/0x5dc)
[ 4577.464145] [<c025785c>] (worker_thread) from [<c025d338>] (kthread+0x14c/0x150)
[ 4577.471534] [<c025d338>] (kthread) from [<c02011f8>] (ret_from_fork+0x14/0x3c)
[ 4577.478744] Exception stack(0xe749dfb0 to 0xe749dff8)
[ 4577.483789] dfa0:                                     00000000 00000000 00000000 00000000
[ 4577.491955] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4577.500120] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 4577.506728] Code: e5d53022 e5d80020 e3130001 1a000068 (e5d73008) 
[ 4577.512929] ---[ end trace acdac39c83d22d1a ]---
[ 4577.517552] Kernel panic - not syncing: Fatal exception in interrupt

The device we are using is an InvizBox 2. If it would help, we would be happy to contribute one for testing as we are planning to bring it into OpenWRT mainline once we have the time and knowledge.

10.10.20214075KernelBug ReportVery LowHighCpufreq is missing on kirkwood target, so the cpu is st...openwrt-21.02Unconfirmed Task Description

Hello, I installed openwrt on a Zyxel NSA-310 device. Everything seems good but when I went to test the performance it was not so good.
So I noticed that the cpu frequency is stuck on 200MHz and cpufreq is missing (also can’t find it as a kmod package).

I am running on original u-boot because of a bad block and the wiki suggested not to flash it. Maybe openwrt’s u-boot has a workaround on this or there is some setting to apply on boot?

BTW I think the wiki does not include a safer, less invasive method as this device can boot entirely from usb without flashing anything, but to do so you need to have a kernel/initramfs w/usbstorage included.

I might try to compile openwrt from sources to include cpufreq. Should I then submit a pull request or a patch?

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

09.10.20214073ToolchainBuild FailureVery LowMediummake kernel_menuconfig fails at m4 1.4.18 in Ubuntu 21....openwrt-21.02Unconfirmed Task Description

I’m attempting to build openwrt 21.02 from git for a Buffalo WZR-600DHP on x86_64 Ubuntu 21.10. make kernel_menuconfig failed, and after running it with increased verbosity I see:

  gcc  -I.   -I/home/bgjenero/gitapps/openwrt/staging_dir/host/include   -O2 -I/home/bgjenero/gitapps/openwrt/staging_dir/host/include  -MT c-stack.o -MD -MP -MF $depbase.Tpo -c -o c-stack.o c-stack.c &&\
  mv -f $depbase.Tpo $depbase.Po
  In file included from /usr/include/signal.h:328,
                   from ./signal.h:52,
                   from c-stack.c:49:
  c-stack.c:55:26: error: missing binary operator before token "("
     55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
        |                          ^~~~~~~~

That’s a failure building m4 1.4.18. It is discussed at https://lists.gnu.org/archive/html/bug-m4/2021-03/msg00000.html

The problem is that m4 is expecting SIGSTKSZ to be a compile time constant, but instead in
/usr/include/x86_64-linux-gnu/bits/sigstksz.h it is: # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)

The m4 package in Ubuntu 21.10 is actually the same version, and the source package has a patch for this in https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/m4/1.4.18-5ubuntu1/m4_1.4.18-5ubuntu1.debian.tar.xz at /debian/patches/04-fix-sigstksz.patch. I am attaching that patch here.

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)


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"
07.10.20214068KernelBug ReportVery LowHighath9k: Placeholder MAC address set on wireless device o...openwrt-21.02Unconfirmed Task Description

I am encountering issues with the wifi device on AVM FRITZ!Box 7430. The MAC address of the adapter is set to a placeholder value:

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
5: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
7: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 00:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff

This issue was reproducable on two separate devices, both with the 21.0.2 release (no matter whether the image was pre-built or self-compiled) and the latest SNAPSHOT image.

fritz_tffs_nand -d /dev/mtd1 -n macwlan

is able to read the correct MAC address from flash however. Attempts to reconfigure the MAC address during runtime with “ip” or by adding the “macaddr” option to /etc/config/wireless were not successful.
I am trying to built a mesh network with multiple FRITZ!Box 7430 devices and the identical BSSID used by them seems to cause on the client network. I have no experience in developing drivers, but am comfortable in compiling OpenWrt from source. Does anyone have an idea on where I could start looking into this issue? I am not sure how the wireless device is configured with its MAC address during boot-up, but would be glad to try any suggestions on how this placeholder value could be overriden. I’ve attached a log showing the boot process.

06.10.20214064Base systemBug ReportVery LowLowhigh latency / no packet transmitted on WRT1900ACS (88W...openwrt-21.02Unconfirmed Task Description

Hi

On Linksys WRT1900ACS (and possibly other devices using marvel 88W8864 WiFi), WiFi connectivity is intermittently unreliable. On my Galaxy S10e smartphone, the symptom is that the device reports being connected to WiFi, but when trying to load a web page, it takes forever. The device switches to cellular connectivity after some time, and reconnect to WiFi (possibly on the other band) and then it works for a while.

As a couple users have reported, it is necessary to disable TX AMSDU to fix this bug.
This can be accomplished by issuing the following commands:

echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu

This should be done by default.

Related discussions:
https://forum.openwrt.org/t/openwrt-21-02-0-first-stable-release/105395/209 https://github.com/kaloz/mwlwifi/issues/207

30.09.20214060Base systemBug ReportVery LowMediumopkg update fails to download the package list because ...openwrt-21.02Unconfirmed Task Description

Detailed description:
It seems that

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

root@MiniMot2:~# opkg update
Downloading https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz

Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz

Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz

Collected errors:
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz, wget returned 5.
root@MiniMot2:~# opkg update
Downloading https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz

Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz

Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz * Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz

Collected errors:
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz, wget returned 5.
* opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz, wget returned 5.
root@MiniMot2:~# wg
wg wget
root@MiniMot2:~# wget https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz Downloading ‘https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz’ Connecting to 168.119.138.211:443
Connection error: Invalid SSL certificate
root@MiniMot2:~# date
Thu Sep 30 11:03:48 EDT 2021
root@MiniMot2:~# wget –no-check-certificate https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz Downloading ‘https://downloads.openwrt.org/releases/21.02.0/targets/ipq806x/generic/packages/Packages.gz’ Connecting to 168.119.138.211:443
Writing to ‘Packages.gz’ Packages.gz 100% |***| 87252 0:00:00 ETA
Download completed (87252 bytes)
root@MiniMot2:~#

24.09.20214054KernelBug ReportVery LowMediumath10k kernel error out of the blue on WiFi dump AP run...openwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: TP-Link Archer C7v5 (3 devices, bought 2019 + 2021/06 + 2021/07)
- Software versions of OpenWrt: 21.02.0-stable

Kernel log: (see attachment for full log)

Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.336444] ------------[ cut here ]------------
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.341374] WARNING: CPU: 0 PID: 0 at backports-5.10.42-1/net/mac80211/rate.c:688 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.352697] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat batman_adv ath9k_hw ath10k_pci ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt                            _MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt                            _LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter i                            p6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 usb_storage fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usb                            core nls_base usb_common crc16 crc32c_generic crypto_hash
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.429750] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.143 #0
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.435871] Stack : 86c80000 800b95d8 80660000 805fa440 00000000 00000000 00000000 00000000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.444593]         00000000 00000000 00000000 00000000 00000000 00000001 87c0bc30 d8213a8a
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.453311]         87c0bcc8 00000000 00000000 00000124 00000038 8057a304 352e342e 31343320
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.462030]         00000124 0d9f3ab6 00000000 73776170 00000000 87c0bc10 00000000 86c1e77c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.470755]         00000009 86c76a10 86d581a0 80630000 00000002 8031fd68 00000000 80790000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.479473]         ...
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.482091] Call Trace:
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.482104] [<86c80000>] 0x86c80000 [ath10k_core@664f4f0d+0x5a910]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.491190] [<800b95d8>] 0x800b95d8
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.494891] [<80660000>] 0x80660000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.498592] [<8057a304>] 0x8057a304
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.502299] [<86c1e77c>] 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.508533] [<8031fd68>] 0x8031fd68
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.512235] [<86c80000>] 0x86c80000 [ath10k_core@664f4f0d+0x5a910]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.518706] [<80069364>] 0x80069364
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.522407] [<8006936c>] 0x8006936c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.526107] [<800821b4>] 0x800821b4
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.529814] [<86c1e77c>] 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.536018] [<8008225c>] 0x8008225c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.539725] [<8054599c>] 0x8054599c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.543442] [<86c1e77c>] 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.549660] [<86c2e650>] 0x86c2e650 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.555879] [<800c3bfc>] 0x800c3bfc
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.559577] [<8684b544>] 0x8684b544 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.565524] [<868495cc>] 0x868495cc [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.571482] [<8684c928>] 0x8684c928 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.577444] [<86844400>] 0x86844400 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.583401] [<86c30ccc>] 0x86c30ccc [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.589627] [<86c30e20>] 0x86c30e20 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.595855] [<86c38b50>] 0x86c38b50 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.602090] [<86c3a774>] 0x86c3a774 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.608320] [<86844c28>] 0x86844c28 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.614256] [<80660000>] 0x80660000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.617956] [<80660000>] 0x80660000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.621647] [<80085040>] 0x80085040
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.625339] [<800badb8>] 0x800badb8
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.629040] [<8057f8b8>] 0x8057f8b8
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.632739] [<800bf060>] 0x800bf060
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.636433] [<802bf580>] 0x802bf580
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.640133] [<80064f78>] 0x80064f78
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.643829]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.645453] ---[ end trace 7de74c0828886f30 ]---

My packages: “opkg list” (see attachment)

My wireless config:

config wifi-device 'radio0'
        option type 'mac80211'
        option beacon_int '100'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'VHT80'
        option txpower '23'
        option country 'DE'
        option noscan '1'
        option disabled '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '1'
        option hwmode '11g'
        option path 'platform/ahb/18100000.wmac'
        option htmode 'HT40'
        option txpower '20'
        option country 'DE'
        option noscan '1'
        option disabled '0'

config wifi-iface 'wifinet0'
        option device 'radio0'
        option disabled '0'
        option mode 'ap'
        option network 'VL20'
        option ssid 'SSID1'
        option encryption 'wpa2+ccmp'
        option nasid 'NASID'
        option auth_port '1812'
        option auth_server 'RAD_SERVER_IP'
        option auth_secret 'KEY_REMOVED'
        option acct_port '1813'
        option acct_server 'RAD_SERVER_IP'
        option acct_secret 'KEY_REMOVED'
        option disassoc_low_ack '1'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option dtim_period '2'
        option short_preamble '1'

config wifi-iface 'wifinet1'
        option device 'radio0'
        option disabled '0'
        option mode 'ap'
        option network 'VL20'
        option ssid 'SSID2'
        option encryption 'psk2+ccmp'
        option key 'KEY_REMOVED'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option disassoc_low_ack '1'
        option dtim_period '1'
        option short_preamble '1'

config wifi-iface 'wifinet2'
        option device 'radio0'
        option disabled '1'
        option mode 'ap'
        option hidden '1'
        option network 'VL10'
        option ssid 'SSID3'
        option encryption 'psk2+ccmp'
        option key 'KEY_REMOVED'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option disassoc_low_ack '1'
        option dtim_period '2'
        option short_preamble '1'

config wifi-iface 'wifinet3'
        option device 'radio1'
        option disabled '0'
        option mode 'ap'
        option network 'VL20'
        option ssid 'SSID4'
        option encryption 'psk2+ccmp'
        option key 'KEY_REMOVED'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option disassoc_low_ack '1'
        option dtim_period '1'
        option short_preamble '1'

config wifi-iface 'wifinet4'
        option device 'radio0'
        option disabled '1'
        option mode 'ap'
        option network 'VL30'
        option ssid 'SSID5'
        option encryption 'none'
        option disassoc_low_ack '1'
        option dtim_period '2'
        option short_preamble '1'
24.09.20214053KernelBug ReportVery LowMediumath10k kernel error out of the blue on WiFi dump AP run...openwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: TP-Link Archer C7v5 (3 devices, bought 2019 + 2021/06 + 2021/07)
- Software versions of OpenWrt: 21.02.0-stable

Kernel log: (see attachment for full log)

Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.336444] ------------[ cut here ]------------
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.341374] WARNING: CPU: 0 PID: 0 at backports-5.10.42-1/net/mac80211/rate.c:688 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.352697] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat batman_adv ath9k_hw ath10k_pci ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt                            _MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt                            _LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter i                            p6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 usb_storage fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usb                            core nls_base usb_common crc16 crc32c_generic crypto_hash
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.429750] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.143 #0
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.435871] Stack : 86c80000 800b95d8 80660000 805fa440 00000000 00000000 00000000 00000000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.444593]         00000000 00000000 00000000 00000000 00000000 00000001 87c0bc30 d8213a8a
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.453311]         87c0bcc8 00000000 00000000 00000124 00000038 8057a304 352e342e 31343320
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.462030]         00000124 0d9f3ab6 00000000 73776170 00000000 87c0bc10 00000000 86c1e77c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.470755]         00000009 86c76a10 86d581a0 80630000 00000002 8031fd68 00000000 80790000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.479473]         ...
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.482091] Call Trace:
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.482104] [<86c80000>] 0x86c80000 [ath10k_core@664f4f0d+0x5a910]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.491190] [<800b95d8>] 0x800b95d8
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.494891] [<80660000>] 0x80660000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.498592] [<8057a304>] 0x8057a304
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.502299] [<86c1e77c>] 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.508533] [<8031fd68>] 0x8031fd68
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.512235] [<86c80000>] 0x86c80000 [ath10k_core@664f4f0d+0x5a910]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.518706] [<80069364>] 0x80069364
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.522407] [<8006936c>] 0x8006936c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.526107] [<800821b4>] 0x800821b4
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.529814] [<86c1e77c>] 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.536018] [<8008225c>] 0x8008225c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.539725] [<8054599c>] 0x8054599c
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.543442] [<86c1e77c>] 0x86c1e77c [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.549660] [<86c2e650>] 0x86c2e650 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.555879] [<800c3bfc>] 0x800c3bfc
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.559577] [<8684b544>] 0x8684b544 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.565524] [<868495cc>] 0x868495cc [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.571482] [<8684c928>] 0x8684c928 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.577444] [<86844400>] 0x86844400 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.583401] [<86c30ccc>] 0x86c30ccc [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.589627] [<86c30e20>] 0x86c30e20 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.595855] [<86c38b50>] 0x86c38b50 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.602090] [<86c3a774>] 0x86c3a774 [mac80211@2c15a7f2+0x7d0f0]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.608320] [<86844c28>] 0x86844c28 [ath9k@97ca09b5+0x19110]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.614256] [<80660000>] 0x80660000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.617956] [<80660000>] 0x80660000
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.621647] [<80085040>] 0x80085040
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.625339] [<800badb8>] 0x800badb8
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.629040] [<8057f8b8>] 0x8057f8b8
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.632739] [<800bf060>] 0x800bf060
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.636433] [<802bf580>] 0x802bf580
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.640133] [<80064f78>] 0x80064f78
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.643829]
Sep 24 08:55:55 WifiAP-02-EG kernel: [833015.645453] ---[ end trace 7de74c0828886f30 ]---

My packages: "opkg list" (see attachment)

My wireless config:

config wifi-device 'radio0'
        option type 'mac80211'
        option beacon_int '100'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'VHT80'
        option txpower '23'
        option country 'DE'
        option noscan '1'
        option disabled '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '1'
        option hwmode '11g'
        option path 'platform/ahb/18100000.wmac'
        option htmode 'HT40'
        option txpower '20'
        option country 'DE'
        option noscan '1'
        option disabled '0'

config wifi-iface 'wifinet0'
        option device 'radio0'
        option disabled '0'
        option mode 'ap'
        option network 'VL20'
        option ssid 'SSID1'
        option encryption 'wpa2+ccmp'
        option nasid 'Rocco'
        option auth_port '1812'
        option auth_server 'RAD_SERVER_IP'
        option auth_secret 'KEY_REMOVED'
        option acct_port '1813'
        option acct_server 'RAD_SERVER_IP'
        option acct_secret 'KEY_REMOVED'
        option disassoc_low_ack '1'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option dtim_period '2'
        option short_preamble '1'

config wifi-iface 'wifinet1'
        option device 'radio0'
        option disabled '0'
        option mode 'ap'
        option network 'VL20'
        option ssid 'SSID2'
        option encryption 'psk2+ccmp'
        option key 'KEY_REMOVED'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option disassoc_low_ack '1'
        option dtim_period '1'
        option short_preamble '1'

config wifi-iface 'wifinet2'
        option device 'radio0'
        option disabled '1'
        option mode 'ap'
        option hidden '1'
        option network 'VL10'
        option ssid 'SSID3'
        option encryption 'psk2+ccmp'
        option key 'KEY_REMOVED'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option disassoc_low_ack '1'
        option dtim_period '2'
        option short_preamble '1'

config wifi-iface 'wifinet3'
        option device 'radio1'
        option disabled '0'
        option mode 'ap'
        option network 'VL20'
        option ssid 'SSID4'
        option encryption 'psk2+ccmp'
        option key 'KEY_REMOVED'
        option ieee80211w '1'
        option wpa_disable_eapol_key_retries '1'
        option disassoc_low_ack '1'
        option dtim_period '1'
        option short_preamble '1'

config wifi-iface 'wifinet4'
        option device 'radio0'
        option disabled '1'
        option mode 'ap'
        option network 'VL30'
        option ssid 'SSID5'
        option encryption 'none'
        option disassoc_low_ack '1'
        option dtim_period '2'
        option short_preamble '1'
22.09.20214051KernelBug ReportVery LowHighath10k_pci firmware is crashing in loopsopenwrt-21.02Unconfirmed Task Description

I have a TP-Link Archer C7v4 with 21.02. After 21.02 upgrade, ath10k firmware started to crash in loops. I get a lot of logs,

[11487.634801] ath10k_pci 0000:00:00.0: device successfully recovered
[11492.190000] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 117
[11492.241196] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 15
[11496.695656] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 127
[11496.746854] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 208
[11496.798068] ath10k_pci 0000:00:00.0: HTC rx frame too long, len: 65330
[11496.849253] ath10k_pci 0000:00:00.0: HTC rx frame too long, len: 65543
[11496.900455] ath10k_pci 0000:00:00.0: HTC rx frame too long, len: 18916
[11498.129262] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 189
[11498.180467] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 41
[11499.972498] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 209
...
[11519.921127] ath10k_pci 0000:00:00.0: firmware crashed! (guid d9fcd37f-f88d-4c9c-a552-28050cb02db3)

And a couple of kernel stacks too. I’ll attach dmesg messages.

It started after my last reboot and system uptime is still small (about 3hs).
The system seems to be updated:
ath10k-board-qca988x - 20201118-3
ath10k-firmware-qca988x-ct - 2020-11-08-1
kmod-ath - 5.4.143+5.10.42-1-1
kmod-ath10k-ct - 5.4.143+2021-06-03-b44cd7b2-2

ath9x does not seem to be affected.

After a reboot, the system was stable again.

22.09.20214050Base systemBug ReportVery LowHighDFS not working on WNDR4300openwrt-21.02Unconfirmed Task Description

After Upgrading from 19.07.8 to version 21.02.0 the 5 GHZ WLAN is not working any more.
The WLAN gets shutdown by DFS.
FYI: Same freqency was used (channel 52) on 19.07.8 - worked perfekt, on 21.02.0 - doesn’t work due to radar detect and shutdown by DFS.

Device: WNDR4300
Software: OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-21.231.26241-422c175

Logfile:
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5660 ht_enabled=1 chan_offset=1 chan_width=2 cf1=5670 cf2=0
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: AP-DISABLED
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 8c:8e:f2:f1:27:70
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 40:16:3b:f4:ed:da
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 74:81:14:50:7e:94
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 80:0c:67:08:d8:f1
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED ec:ad:b8:7b:b0:25
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
Tue Sep 21 07:51:19 2021 kern.info kernel: [82242.427874] device wlan1 left promiscuous mode
Tue Sep 21 07:51:19 2021 kern.info kernel: [82242.432916] br-lan: port 2(wlan1) entered disabled state
Tue Sep 21 07:51:19 2021 daemon.notice netifd: Network device ‘wlan1’ link is down
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: interface state ENABLED→DISABLED
Tue Sep 21 07:51:19 2021 kern.info kernel: [82242.487270] br-lan: port 2(wlan1) entered blocking state
Tue Sep 21 07:51:19 2021 kern.info kernel: [82242.492733] br-lan: port 2(wlan1) entered disabled state
Tue Sep 21 07:51:19 2021 kern.info kernel: [82242.498550] device wlan1 entered promiscuous mode
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: interface state DISABLED→COUNTRY_UPDATE
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE→HT_SCAN
Tue Sep 21 07:51:19 2021 daemon.err hostapd: could not get valid channel
Tue Sep 21 07:51:19 2021 daemon.notice hostapd: wlan1: interface state HT_SCAN→DFS
Tue Sep 21 07:51:31 2021 daemon.info hostapd: wlan0: STA 06:0f:98:97:99:26 IEEE 802.11: authenticated
Tue Sep 21 07:51:31 2021 daemon.info hostapd: wlan0: STA 06:0f:98:97:99:26 IEEE 802.11: associated (aid 1)
Tue Sep 21 07:51:31 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 06:0f:98:97:99:26
Tue Sep 21 07:51:31 2021 daemon.info hostapd: wlan0: STA 06:0f:98:97:99:26 WPA: pairwise key handshake completed (RSN)
Tue Sep 21 07:52:27 2021 daemon.err uhttpd[1831]: luci: accepted login on / for root from 192.168.1.120
Tue Sep 21 07:56:35 2021 daemon.err uhttpd[1831]: luci: accepted login on / for root from 192.168.1.15

If you need amy additional info, please let me know.

Regards


21.09.20214048Base systemBug ReportVery LowLowsysupgrade with "-k"openwrt-21.02Unconfirmed Task Description

When using sysupgrade with “-k” to include a list of installed packages in the backup, a mounting error is both logged to console and to log.

How to reproduce:

Do backup with “-k”

root@router:~# /sbin/sysupgrade -k -b /mnt/sda1/backup.tar.gz
mount: mounting overlay on /etc/backup failed: Invalid argument
Cannot mount '/etc/backup' as tmpfs to avoid touching disk while saving the list of installed packages.
Tue Sep 21 16:12:05 CEST 2021 upgrade: Saving config files...

It does not matter where to backup,the same errors show up when using

sysupgrade -k -b - >/dev/null

to backup to stdout.

Show kernel error from log:

root@router:~# logread | grep kern.err
TueSep 21 16:12:05 2021 kern.err kernel: [539662.073867] overlayfs: maximum fs stacking depth exceeded

System

Hardware:
TP-Link Archer C7

OpenWrt version:

root@router:~# cat /etc/os-release 
NAME="OpenWrt"
VERSION="21.02.0"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 21.02.0"
VERSION_ID="21.02.0"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r16279-5cc0535800"
OPENWRT_BOARD="ath79/generic"
OPENWRT_ARCH="mips_24kc"
OPENWRT_TAINTS=""
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt 21.02.0 r16279-5cc0535800"
20.09.20214047Base systemBug ReportVery LowLowMissing LED on Archer C7 V2openwrt-21.02Unconfirmed Task Description

With ATH79 the WAN LED is missing on my Archer C7 V2
Using Openwrt 21.02.0.

root@Repeater_WZ:~# ls /sys/class/leds
ath10k-phy0 tp-link:green:system tp-link:green:wlan2g
ath9k-phy1 tp-link:green:usb1 tp-link:green:wlan5g
tp-link:green:qss tp-link:green:usb2
root@Repeater_WZ:~#

19.09.20214046Base systemBug ReportVery LowMediumUniFI 6 LR 5 GHz doesn't always come upopenwrt-21.02Unconfirmed Task Description

I upgraded my UniFI 6 LR from 21.02-rc4 to 21.02, and the 5 GHz didn’t come up

The log contained:

[   82.530766] procd: - init -
[   82.693561] urngd: v1.0.2 started.
[   82.693573] kmodloader: loading kernel modules from /etc/modules.d/*
[   82.715949] Loading modules backported from Linux version v5.10.42-0-g65859eca4dff
[   82.721972] random: crng init done
[   82.723533] Backport generated by backports.git v5.10.42-1-0-gbee5c545
[   82.726920] random: 6 urandom warning(s) missed due to ratelimiting
[   82.758353] xt_time: kernel timezone is -0000
[   82.825175] mtk-spi-nor 11014000.spi: dma read timeout.
[   82.832591] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   82.860179] mt7915e 0000:01:00.0: assign IRQ: got 130
[   82.865298] pci 0000:00:00.0: enabling bus mastering
[   82.870276] mt7915e 0000:01:00.0: enabling device (0000 -> 0002)
[   82.876353] mt7915e 0000:01:00.0: enabling bus mastering
[   82.910736] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
[   82.910736] 
[   82.958342] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20201105222230a
[   82.958342] 
[   83.083169] mt7622-wmac 18000000.wmac: N9 Firmware Version: 2.0, Build Time: 20200131180931
[   83.103528] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20201105222304
[   83.152087] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20201105222323
[   83.270498] mtk-spi-nor 11014000.spi: dma read timeout.
[   83.276046] mt7915e: probe of 0000:01:00.0 failed with error -110
[   83.289668] PPP generic driver version 2.4.2
[   83.294505] NET: Registered protocol family 24
[   83.302489] kmodloader: done loading kernel modules from /etc/modules.d/*
[   85.403795] mtk_soc_eth 1b100000.ethernet eth0: configuring for fixed/2500base-x link mode
[   85.412217] mtk_soc_eth 1b100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control off

I then rebooted, and it did come up, the log now showed:

[    6.916314] procd: - init -
[    7.066192] kmodloader: loading kernel modules from /etc/modules.d/*
[    7.080571] urngd: v1.0.2 started.
[    7.088294] Loading modules backported from Linux version v5.10.42-0-g65859eca4dff
[    7.095887] Backport generated by backports.git v5.10.42-1-0-gbee5c545
[    7.108576] random: crng init done
[    7.112008] random: 6 urandom warning(s) missed due to ratelimiting
[    7.120977] xt_time: kernel timezone is -0000
[    7.198829] mtk-spi-nor 11014000.spi: dma read timeout.
[    7.206369] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    7.238726] mt7915e 0000:01:00.0: assign IRQ: got 130
[    7.243838] pci 0000:00:00.0: enabling bus mastering
[    7.248816] mt7915e 0000:01:00.0: enabling device (0000 -> 0002)
[    7.254907] mt7915e 0000:01:00.0: enabling bus mastering
[    7.285262] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
[    7.285262] 
[    7.346831] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20201105222230a
[    7.346831] 
[    7.436626] mt7622-wmac 18000000.wmac: N9 Firmware Version: 2.0, Build Time: 20200131180931
[    7.532980] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20201105222304
[    7.583152] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20201105222323
[    7.710630] PPP generic driver version 2.4.2
[    7.716260] NET: Registered protocol family 24
[    7.724504] kmodloader: done loading kernel modules from /etc/modules.d/*
[    9.395937] mtk_soc_eth 1b100000.ethernet eth0: configuring for fixed/2500base-x link mode
[    9.404503] mtk_soc_eth 1b100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control off
17.09.20214043Base systemBug ReportVery LowLow21.02 x86 generic ext4 combined image does not bootopenwrt-21.02Unconfirmed Task Description

x86 image “generic-ext4-combined.img.gz” of 21.02.0 does not boot — it can’t find rootfs and either panics or hangs.
Tested on qemu and virtualbox.

Broken image link:
https://downloads.openwrt.org/releases/21.02.0/targets/x86/generic/openwrt-21.02.0-x86-generic-generic-ext4-combined.img.gz

The efi image, “generic-ext4-combined-efi.img.gz”, works fine (tested with BIOS boot), that’s why I assume that “generic-ext4-combined.img.gz” is broken.

17.09.20214042Base systemBug ReportVery LowMediumnetifd forces up dhcp interfaces set admin-down with "i...openwrt-21.02Unconfirmed Task Description

netifd will immediately and automatically set an interface active/up which has been administratively disabled with either the “ip link set $I down” or “ifconfig $I down” commands.

This problem will only occur if the interface proto is configured for “dhcp” rather than “static”. This appears to be related to the behavior induced by the “force_link” option, however force_link suppresses hotplug events (which breaks my use-case) and probably has other undesirable side-effects.

Below is a sample log where “ip link set eth0.1 down” is used against the “lan” interface-configuration. Note that identical behavior is also observed on a typical ethernet interface (eth0) where there is no intermediate switch or VLAN-interfaces involved.

Sat Sep 11 00:39:59 2021 daemon.notice netifd: VLAN 'eth0.1' link is down
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat Sep 11 00:39:59 2021 kern.info kernel: [48844.417075] device eth0 left promiscuous mode
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (28106): udhcpc: received SIGTERM
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is now down
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is disabled
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is enabled
Sat Sep 11 00:39:59 2021 daemon.notice netifd: VLAN 'eth0.1' link is up
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is setting up now
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: started, v1.30.1
Sat Sep 11 00:39:59 2021 kern.info kernel: [48845.042493] device eth0 entered promiscuous mode
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: sending discover
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: sending select for 192.168.0.148
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: lease of 192.168.0.148 obtained, lease time 43200
Sat Sep 11 00:40:00 2021 daemon.notice netifd: Interface 'lan' is now up
Sat Sep 11 00:40:01 2021 user.notice firewall: Reloading firewall due to ifup of lan (eth0.1)

This behavior was verified on multiple 21.02 and 19.07 devices.

14.09.20214036Base systemBug ReportVery LowMediumLenovo Newifi D1, cannot form a mesh over 2.4Ghz radio ...openwrt-21.02Unconfirmed Task Description

- Problem:
It’s not possible to form a mesh using the 11th channel of the 2.4Ghz radio using the Lenovo Newifi D1, even though ‘iw dev’ shows it should, the entire troubleshooting was documented over at: https://forum.openwrt.org/t/mesh-network-configuration-mesh-fails-batman/105260

- Device: Lenovo Newifi_D1
- Version: 21.02.0
- Packages:

base-files - 1432-r16279-5cc0535800
batctl-default - 2021.1-1
block-mount - 2021-01-04-c53b1882-1
busybox - 1.33.1-6
ca-bundle - 20210119-1
cgi-io - 2020-10-27-ab4c3471-19
dnsmasq - 2.85-8
dropbear - 2020.81-2
firewall - 2021-03-23-61db17ed-1
fstools - 2021-01-04-c53b1882-1
fwtool - 2019-11-12-8f7fe925-1
getrandom - 2020-10-25-9ef88681-2
hostapd-common - 2020-06-08-5a8b3662-35
iftop - 2018-10-03-77901c8c-2
ip6tables - 1.8.7-1
iptables - 1.8.7-1
irqbalance - 1.8.0-1
iw - 5.9-8fab0c9e-1
iwinfo - 2021-04-30-c45f0b58-2.1
jshn - 2021-05-16-b14c4688-2
jsonfilter - 2018-02-04-c7e938d6-1
kernel - 5.4.143-1-69ffa419aded4c8e863b9a419c27d933
kmod-batman-adv - 5.4.143+2021.1-4
kmod-cfg80211 - 5.4.143+5.10.42-1-1
kmod-crypto-acompress - 5.4.143-1
kmod-crypto-crc32 - 5.4.143-1
kmod-crypto-crc32c - 5.4.143-1
kmod-crypto-hash - 5.4.143-1
kmod-fs-ext4 - 5.4.143-1
kmod-fs-f2fs - 5.4.143-1
kmod-fs-vfat - 5.4.143-1
kmod-gpio-button-hotplug - 5.4.143-3
kmod-ip6tables - 5.4.143-1
kmod-ipt-conntrack - 5.4.143-1
kmod-ipt-core - 5.4.143-1
kmod-ipt-nat - 5.4.143-1
kmod-ipt-offload - 5.4.143-1
kmod-leds-gpio - 5.4.143-1
kmod-lib-crc-ccitt - 5.4.143-1
kmod-lib-crc16 - 5.4.143-1
kmod-lib-crc32c - 5.4.143-1
kmod-lib-lzo - 5.4.143-1
kmod-mac80211 - 5.4.143+5.10.42-1-1
kmod-mmc - 5.4.143-1
kmod-mt76-core - 5.4.143+2021-06-06-22b69033-4
kmod-mt7603 - 5.4.143+2021-06-06-22b69033-4
kmod-mt76x02-common - 5.4.143+2021-06-06-22b69033-4
kmod-mt76x2 - 5.4.143+2021-06-06-22b69033-4
kmod-mt76x2-common - 5.4.143+2021-06-06-22b69033-4
kmod-nf-conntrack - 5.4.143-1
kmod-nf-conntrack6 - 5.4.143-1
kmod-nf-flow - 5.4.143-1
kmod-nf-ipt - 5.4.143-1
kmod-nf-ipt6 - 5.4.143-1
kmod-nf-nat - 5.4.143-1
kmod-nf-reject - 5.4.143-1
kmod-nf-reject6 - 5.4.143-1
kmod-nls-base - 5.4.143-1
kmod-nls-cp437 - 5.4.143-1
kmod-nls-iso8859-1 - 5.4.143-1
kmod-nls-utf8 - 5.4.143-1
kmod-ppp - 5.4.143-1
kmod-pppoe - 5.4.143-1
kmod-pppox - 5.4.143-1
kmod-scsi-core - 5.4.143-1
kmod-sdhci - 5.4.143-1
kmod-sdhci-mt7620 - 5.4.143-1
kmod-slhc - 5.4.143-1
kmod-usb-core - 5.4.143-1
kmod-usb-ehci - 5.4.143-1
kmod-usb-ledtrig-usbport - 5.4.143-1
kmod-usb-storage - 5.4.143-1
kmod-usb-storage-uas - 5.4.143-1
kmod-usb2 - 5.4.143-1
kmod-zram - 5.4.143-1
libblobmsg-json20210516 - 2021-05-16-b14c4688-2
libc - 1.1.24-3
libgcc1 - 10.2.0-3
libip4tc2 - 1.8.7-1
libip6tc2 - 1.8.7-1
libiwinfo-data - 2021-04-30-c45f0b58-2.1
libiwinfo-lua - 2021-04-30-c45f0b58-2.1
libiwinfo20210430 - 2021-04-30-c45f0b58-2.1
libjson-c5 - 0.15-2
libjson-script20210516 - 2021-05-16-b14c4688-2
liblua5.1.5 - 5.1.5-9
liblucihttp-lua - 2021-06-11-3dc89af4-1
liblucihttp0 - 2021-06-11-3dc89af4-1
libncurses6 - 6.2-1
libnl-tiny1 - 2020-08-05-c291088f-2
libpcap1 - 1.9.1-3
libpthread - 1.1.24-3
librt - 1.1.24-3
libubox20210516 - 2021-05-16-b14c4688-2
libubus-lua - 2021-06-30-4fc532c8-2
libubus20210630 - 2021-06-30-4fc532c8-2
libuci20130104 - 2020-10-06-52bbc99f-5
libuclient20201210 - 2021-05-14-6a6011df-1
libustream-wolfssl20201210 - 2020-12-10-68d09243-1
libwolfssl4.7.0.66253b90 - 4.7.0-stable-2
libxtables12 - 1.8.7-1
logd - 2020-10-25-9ef88681-2
lua - 5.1.5-9
luci - git-20.074.84698-ead5e81
luci-app-firewall - git-21.244.20922-3b3c2e5
luci-app-opkg - git-21.079.58598-6639e31
luci-base - git-21.231.26241-422c175
luci-lib-base - git-20.232.39649-1f6dc29
luci-lib-ip - git-20.250.76529-62505bd
luci-lib-jsonc - git-19.317.29469-8da8f38
luci-lib-nixio - git-20.234.06894-c4a4e43
luci-mod-admin-full - git-19.253.48496-3f93650
luci-mod-network - git-21.243.25235-d9a228e
luci-mod-status - git-21.188.55036-eafe171
luci-mod-system - git-21.230.63964-c3580ee
luci-proto-ipv6 - git-21.148.49484-14511e5
luci-proto-ppp - git-21.163.64918-6c6559a
luci-ssl - git-20.244.36115-e10f954
luci-theme-bootstrap - git-21.164.71418-bd36169
mtd - 26
netifd - 2021-07-26-440eb064-1
odhcp6c - 2021-01-09-53f07e90-16
odhcpd-ipv6only - 2021-07-18-bc9d317f-3
openwrt-keyring - 2021-02-20-49283916-2
opkg - 2021-06-13-1bf042dd-1
ppp - 2.4.8.git-2020-10-03-3
ppp-mod-pppoe - 2.4.8.git-2020-10-03-3
procd - 2021-02-23-37eed131-1
px5g-wolfssl - 3
rpcd - 2021-03-11-ccb75178-1
rpcd-mod-file - 2021-03-11-ccb75178-1
rpcd-mod-iwinfo - 2021-03-11-ccb75178-1
rpcd-mod-luci - 20210614
rpcd-mod-rrdns - 20170710
terminfo - 6.2-1
ubi-utils - 2.1.2-1
ubox - 2020-10-25-9ef88681-2
ubus - 2021-06-30-4fc532c8-2
ubusd - 2021-06-30-4fc532c8-2
uci - 2020-10-06-52bbc99f-5
uclient-fetch - 2021-05-14-6a6011df-1
uhttpd - 2021-03-21-15346de8-1
uhttpd-mod-ubus - 2021-03-21-15346de8-1
urandom-seed - 3
urngd - 2020-01-21-c7f7b6b6-1
usign - 2020-05-23-f1f65026-1
wireless-regdb - 2021.04.21-1
wpad-wolfssl - 2020-06-08-5a8b3662-35
zram-swap - 8

- Steps to reproduce
1. Change WiFi 2.4Ghz radio channel to 11
2. Try to form a mesh with another device (R6220 was tested with it) using 2.4Ghz radio
3. 2.4Ghz mesh point interface will fail to join the mesh and “ip link” shows said interface isn’t up.
4. Using a different channel (1 and 6 were tested) resolved the problem.

NOTE: I changed country codes from 00 to IN(which has no DFS and no limits) and to US, no changes.

- Logs:
Newifi D1 system log:

Wed Sep  8 14:28:44 2021 daemon.err wpa_supplicant[3766]: wlan0-1: Could not join mesh
Wed Sep  8 14:28:44 2021 daemon.notice wpa_supplicant[3766]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Wed Sep  8 14:28:44 2021 kern.info kernel: [ 1519.626597] br-lan: port 5(wlan0) entered disabled state
Wed Sep  8 14:28:44 2021 kern.info kernel: [ 1519.655136] device wlan0 left promiscuous mode
Wed Sep  8 14:28:44 2021 kern.info kernel: [ 1519.659660] br-lan: port 5(wlan0) entered disabled state
Wed Sep  8 14:28:44 2021 daemon.notice wpa_supplicant[3766]: nl80211: deinit ifname=wlan0-1 disabled_11b_rates=0
Wed Sep  8 14:28:44 2021 kern.info kernel: [ 1519.812995] br-lan: port 6(wlan0-1) entered disabled state
Wed Sep  8 14:28:45 2021 kern.info kernel: [ 1520.867562] br-lan: port 6(wlan0-1) entered disabled state
Wed Sep  8 14:28:45 2021 kern.info kernel: [ 1520.903187] device wlan0-1 left promiscuous mode
Wed Sep  8 14:28:45 2021 kern.info kernel: [ 1520.907901] br-lan: port 6(wlan0-1) entered disabled state
Wed Sep  8 14:28:47 2021 daemon.notice netifd: radio0 (8260): command failed: Link has been severed (-67)
Wed Sep  8 14:28:47 2021 daemon.notice netifd: radio0 (8260): command failed: Link has been severed (-67)
Wed Sep  8 14:28:47 2021 kern.info kernel: [ 1522.390393] br-lan: port 5(wlan0) entered blocking state
Wed Sep  8 14:28:47 2021 kern.info kernel: [ 1522.395991] br-lan: port 5(wlan0) entered disabled state
Wed Sep  8 14:28:47 2021 kern.info kernel: [ 1522.402587] device wlan0 entered promiscuous mode
Wed Sep  8 14:28:47 2021 kern.info kernel: [ 1522.413285] br-lan: port 6(wlan0-1) entered blocking state
Wed Sep  8 14:28:47 2021 kern.info kernel: [ 1522.418904] br-lan: port 6(wlan0-1) entered disabled state
Wed Sep  8 14:28:47 2021 kern.info kernel: [ 1522.425376] device wlan0-1 entered promiscuous mode
Wed Sep  8 14:28:48 2021 daemon.notice wpa_supplicant[3766]: wlan0-1: leaving mesh
Wed Sep  8 14:28:48 2021 kern.info kernel: [ 1523.095183] br-lan: port 6(wlan0-1) entered disabled state
Wed Sep  8 14:28:49 2021 daemon.notice wpa_supplicant[3766]: nl80211: Failed to set interface into station mode
Wed Sep  8 14:28:49 2021 daemon.err wpa_supplicant[3766]: wlan0-1: mesh leave error=-134

Kernel log:

[ 1378.973986] device wlan0 left promiscuous mode
[ 1378.978502] br-lan: port 5(wlan0) entered disabled state
[ 1380.402899] br-lan: port 5(wlan0) entered blocking state
[ 1380.408339] br-lan: port 5(wlan0) entered disabled state
[ 1380.414510] device wlan0 entered promiscuous mode
[ 1380.424809] br-lan: port 6(wlan0-1) entered blocking state
[ 1380.430417] br-lan: port 6(wlan0-1) entered disabled state
10.09.20214028Base systemBug ReportVery LowMediumExtroot cannot mount after boot, block: no usable confi...openwrt-21.02Unconfirmed Task Description

I run OpenWRT on my x86 PC(Lenovo tiny series, UEFI+amd64), use the latest 21.02 stable version, squashfs+efi, and burn into USB drive via Rufus, all new flash, no upgrade, no restore backup configuration.
I totally follow this guide to configure extroot, of course enablemodified the partition /dev/sda1 and something like that. But after reboot I found Extroot partition don’t mount automatic as expected.
Try some times still not work I found not checked enable on luci,so I add

option enabled '1'

in /etc/config/fstab, but still don’t work property. I also follow troublshooting on that article increase delay_root, not work, but true, mount it without problems from a shell after boot.

logread | sed -n -e "/- preinit -/,/- init -/p"

Full logs at here , list relative part below

*
user.info kernel: [ 7.764620] block: attempting to load /etc/config/fstab
user.err kernel: [ 7.768095] block: unable to load configuration (fstab: Entry not found)
user.err kernel: [ 7.769569] block: no usable configuration
*

I search and found this report:https://bugs.openwrt.org/index.php?do=details&task_id=2231, looks a patch in it but I don’t know how to compile and hope use pre-compile stable release. It’s old issue, but it still not marked as completed. I don’t know if it’s relevant.

10.09.20214025Base systemBug ReportVery LowLowipq40xx: Wrong board-2.bin for devices with non-default...openwrt-21.02Unconfirmed Task Description

Steps to reproduce:

$ wget https://downloads.openwrt.org/releases/21.02.0/targets/ipq40xx/generic/openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin $ binwalk -e openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin
$ ls -ltr _openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin.extracted/squashfs-root/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
-rw-r–r– 1 sven sven 607304 Sep 1 00:20 _openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin.extracted/squashfs-root/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
$ md5sum _openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin.extracted/squashfs-root/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
$ md5sum _openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin.extracted/squashfs-root/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
93ee138ebf04fab3ea03a33b24e35f05 _openwrt-21.02.0-ipq40xx-generic-plasmacloud_pa1200-squashfs-factory.bin.extracted/squashfs-root/lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin

But expected were (on tag v21.2.0):

$ ls -ltr package/firmware/ipq-wifi/board-plasmacloud_pa1200.qca4019
-rw-r–r– 1 sven sven 24324 Aug 17 09:23 package/firmware/ipq-wifi/board-plasmacloud_pa1200.qca4019
$ md5sum package/firmware/ipq-wifi/board-plasmacloud_pa1200.qca4019
73129ba35258a8505407364ecedc13ec package/firmware/ipq-wifi/board-plasmacloud_pa1200.qca4019

This breaks wifi on some devices but can also damage them.

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

Available keyboard shortcuts

Tasklist

Task Details

Task Editing