OpenWrt/LEDE Project

Welcome to the OpenWrt/LEDE Project bug reporting and issue tracking system

Problems to be reported here are for the OpenWrt/LEDE Project targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt/LEDE 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 lede-bugs@infradead.org.

OpenedIDCategoryTask Type  ascPrioritySeveritySummaryReported InStatus
08.05.20203072Base systemBug ReportVery LowHighSamknows WhiteBox8 misses 2.4 GHz pcie wireless NICTrunkUnconfirmed Task Description

device

software versions

tested & misses 2.4 GHz NIC

tested & has 2.4 GHz NIC

reproduce

  • build OpenWrt master branch with a given commits and flash it on the device (my build config is attached)
  • run “iw dev” or “iw list”
    • in problem state it lists one interface (the 5 GHz wireless NIC)
    • in good state it lists two interfaces (2.4 GHz and 5 GHz wireless NIC)

conclusion

I think it has either to do with ramips: mt7621: switch kernel version to 5.4 or with ramips: mt7621: update PCIe node in dtsi. Between the known good and earliest known bad commit are multiple commits working together. I fear to test them one by one.

08.05.20203073KernelBug ReportLowHighAR8337/AR8327 Flow Control Enabled on Archer C7 v5 (and...TrunkUnconfirmed Task Description

I have a TP-Link Archer C7 v5 (ath79/generic) running OpenWrt 19.07.2 r10947-65030d81f3 and periodically one of my hosts sends out a long-running flood (10/sec) of MPCP Pause frames. The AR8337 switch is configured to honor these frames on port 0 (CPU), and other ports, so stops switching frames essentially forever.

There is no way exposed to user to disable flow control.

Flow control should be turned off unless explicitly requested by the user (e.g., they are in a Datacenter/Enterprise environment and/or doing Fibre Channel over Ethernet). This is exactly the opposite of how it currently is with the added benefit that the user cannot change the behavior.

Here’s a tool that will helpfully generate MPCP Pause frames:
https://github.com/nwholloway/mpcp

You can use this to bring down your network indefinitely. Additionally, since the AR8337 switch consumes these frames you will not be able to see them from the OpenWRT host.

09.05.20203079Base systemBug ReportVery LowHighTraceback when booting OpenWrt 19.07.2 on Netgear r7500...TrunkUnconfirmed Task Description

My Netgear r7500v2 running OpenWrt 19.07.2 always shows the following traceback when booting up.

[ 31.917130] ————[ cut here ]———— [ 31.917192] WARNING: CPU: 1 PID: 1938 at backports-4.19.98-1/net/wireless/util.c:1147 0xbf2e3d88 [cfg80211@bf2df000+0×37000]
[ 31.920831] invalid rate bw=0, mcs=15, nss=4
[ 31.932143] Modules linked in: pppoe ppp_async ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT wireguard slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack 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 ip6_udp_tunnel udp_tunnel uas usb_storage f2fs ext4 mbcache jbd2 crc32c_generic crc32_generic leds_gpio xhci_plat_hcd
[ 31.985373] xhci_pci xhci_hcd dwc3 dwc3_of_simple ohci_platform ohci_hcd phy_qcom_dwc3 ahci ehci_platform sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug
[ 32.007657] CPU: 1 PID: 1938 Comm: hostapd Not tainted 4.14.171 #0
[ 32.025242] Hardware name: Generic DT based system
[ 32.031323] Function entered at [<c030f1c4>] from [<c030b390>]
[ 32.036095] Function entered at [<c030b390>] from [<c07c0664>]
[ 32.041911] Function entered at [<c07c0664>] from [<c031fa98>]
[ 32.047727] Function entered at [<c031fa98>] from [<c031faf8>]
[ 32.053544] Function entered at [<c031faf8>] from [<bf2e3d88>]
[ 32.059386] Function entered at [<bf2e3d88>] from [<bf2f17dc>]
[ 32.065179] Function entered at [<bf2f17dc>] from [<bf2fe5f4>]
[ 32.070992] Function entered at [<bf2fe5f4>] from [<bf2ff1e8>]
[ 32.076806] Function entered at [<bf2ff1e8>] from [<bf332ad0>]
[ 32.082632] Function entered at [<bf332ad0>] from [<bf332b60>]
[ 32.088438] Function entered at [<bf332b60>] from [<bf332bf8>]
[ 32.094255] Function entered at [<bf332bf8>] from [<bf2ed678>]
[ 32.100071] Function entered at [<bf2ed678>] from [<c06e190c>]
[ 32.105887] Function entered at [<c06e190c>] from [<c06e0128>]
[ 32.111702] Function entered at [<c06e0128>] from [<c06e0900>]
[ 32.117517] Function entered at [<c06e0900>] from [<c06df938>]
[ 32.123334] Function entered at [<c06df938>] from [<c06dfd54>]
[ 32.129150] Function entered at [<c06dfd54>] from [<c0689c18>]
[ 32.134967] Function entered at [<c0689c18>] from [<c068a480>]
[ 32.140782] Function entered at [<c068a480>] from [<c0307b60>]
[ 32.146678] —[ end trace 97f7e93c858c392e ]—

09.05.20203082KernelBug ReportVery LowHigh[nft|bpf] netdev packet logging not possible due to uns...AllUnconfirmed Task Description

nftables|bpf have access to netdev however with https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/config-5.4;h=cdee4c973b2d6a642dadff38a95ec45b309c2dc2;hb=refs/heads/master#l3661

# CONFIG_NF_LOG_NETDEV is not set
 

it is not possible:

  • to debug nftables|bpf rules applied to netdev
  • to build nftables|bpf rules from packets logged on netdev

The kconf for 5.4 is just reference, the issue though is present in all branches.

upstream reference https://github.com/torvalds/linux/blob/v5.4/net/netfilter/Kconfig#L77

09.05.20203083KernelBug ReportVery LowHigh[nftables] invalid/obsolete and missing and unset kconf...TrunkUnconfirmed Task Description

upstream source https://github.com/torvalds/linux/blob/v5.4/net/netfilter/Kconfig#L442 is not matching downstream, in particular it seems that:

  • downstream exhibiting obsolete kconf
CONFIG_NF_TABLES_ARP
CONFIG_NF_TABLES_BRIDGE
  • downstream missing kconf (impeding nft functionality)
NFT_NUMGEN
NFT_CT
NFT_COUNTER
NFT_LOG
NFT_LIMIT
NFT_MASQ
NFT_REDIR
NFT_NAT
NFT_QUEUE
NFT_QUOTA
NFT_REJECT
NFT_REJECT_INET
NFT_COMPAT
NFT_HASH
NFT_FIB_INET
NF_DUP_NETDEV
NFT_DUP_NETDEV
NFT_FWD_NETDEV
  • downstream unset kconf (impeding nft functionality)
NFT_FLOW_OFFLOAD
NFT_CONNLIMIT
NFT_TUNNEL
NFT_OBJREF
NFT_XFRM
NFT_SOCKET
NFT_OSF
NFT_TPROXY
11.05.20203091KernelBug ReportVery LowHighLatest build does not work properly on Banana Pi R2TrunkUnconfirmed Task Description

I compile my image according to the given guide: https://openwrt.org/toh/sinovoip/sinovoip_banana_pi_r2

With kernel version 4.19 everything went smooth (OpenWrt Snapshot shown after boot was r12726-92616c4227).

Then i wanted to upgrade to the current master and after applying the new bpi_bananapi-r2-kernel.bin and root.squashfs files the boot process stops every time at the same point (see attached file boot.txt).

I did the follwing steps:

  1. ./scripts/feeds update -a
  2. ./scripts/feeds install -a
  3. make -j8 menuconfig
  4. follow instructions for menuconfig on guide
  5. make -j8 kernel_menuconfig
  6. follow instructions for kernel_menuconfig on guide
  7. I did not apply the patch that was given. I didn’t encounter any problems with failing network connections even with the old linux kernel. It also does not make any difference according to the current problem.
  8. make -j8
  9. changed repositories.conf according to the guide
  10. make image PROFILE=bpi_bananapi-r2
  11. apply new kernel-file and rootfs according to the guide

I tried this several times with different configurations but the result was the same anyway.

It seems like there is a bug at loading rootfs from MTD.

 


11.05.20203092Base systemBug ReportVery LowHighXiaomi Router 3G random rebootsopenwrt-19.07Unconfirmed Task Description

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

 

Hello,

I have a Xiaomi 3G router. Since the day I bought it I installed Openwrt and to tell you the truth, with version 18.06 I didn’t have any problem.

A few weeks ago I updated to the new version (19.07) using LuCI and it restarts me randomly.

I tried restoring the router, reinstalling the update and it keeps randomly rebooting. Right now I have it without any additional packages installed and it still keeps rebooting randomly.

I have noticed, that almost every time I see a reboot and look at the log file the first thing that appears is this, that is, the first line after the reboot is:

Mon May 11 22:16:59 2020 daemon.info dnsmasq[1148]: exiting on receipt of SIGTERM
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: started, version 2.80 cachesize 150
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: DNS service limited to local subnets
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify dumpfile
Mon May 11 22:16:59 2020 daemon.info dnsmasq-dhcp[2722]: DHCP, IP range 192.168.2.100 -- 192.168.2.249, lease time 12h
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain test
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain onion
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain localhost
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain local
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain invalid
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain bind
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain lan
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: reading /tmp/resolv.conf.auto
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain test
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain onion
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain localhost
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain local
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain invalid
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain bind
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain lan

Please, I need help since I can’t work if it constantly resets. If you need any more information, please do not hesitate to ask me.

30.05.20203138KernelBug ReportVery LowHighmac802.11sh commit broken and causing one radio to dropAllUnconfirmed Task Description

Source of the problem: commit `b551660` `/lib/netifd/wireless/mac802.11sh`
Device problem occurs on: Netgear R7800, LinksysWRT1900ACSv2, Netgear EX6400, TP-Link Archer C60
Software versions of OpenWrt/LEDE: v19.07.3 and master

Steps to reproduce: I created a post here https://forum.openwrt.org/t/wrt1900acsv2-only-one-wifi-radio-is-staying-up/64273 regarding the last WiFi client disconnecting from the AP stops working on that radio.

If I go into ‘Network > Wireless’ in LuCI and click the ‘Restart’ button on the 2.4 or 5GHz radio, that radio is the only radio that stays working, whereas the other radio says disabled and wireless not associated.

I can also replicate this via SSH/CLI running `wifi up radio0` disables radio1. Running `wifi up` brings radio1 up this but drops radio0. If I run `wifi up` a second time both radios come back up.

My forum has been linked to a Netgear 7800 thread found here https://forum.openwrt.org/t/netgear-r7800-exploration-ipq8065-qca9984/285/2259 and there has been confirmation that there appears to be a problem with commit `b551660` from May 4, 2020 for `openwrt/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh`. Rolling back to commit `0495324` appears to fix this issue.

I too can confirm this by renaming `mac80211.sh` to `mac80211.sh.old`, downloading commit `0495324`, placing it under `/lib/netifd/wireless`, setting the permissions to `0755` and then running `wifi up radio0` in SSH/CLI. Radio0 (5GHz) drops as expected and after a couple of seconds it is back up all without affecting the radio1 (2.4GHz).

This is the broken commit https://github.com/openwrt/openwrt/commit/b5516603dd90215d5cdc5bac7ea496a6c758bb0f

This is the working commit https://github.com/openwrt/openwrt/commit/0e522d5f4a31182312bd115c26c7edb654769724

03.06.20203147Base systemBug ReportVery LowHigh802.11w settings on LUCI WIFI page doesn't work properl...openwrt-19.07Unconfirmed Task Description

Host device

Device problem occurs on: Phicomm PSG1218A (MTK7620, 64M, 8MB, 802.11AC+N)
Software versions of OpenWrt/LEDE release: OpenWRT 19.07.3 Stable (r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363)
Package: wpad-openssl OR hostapd-openssl

External server/service

RADIUS server: Windows Server 2019 NPAS, worked fine with WPA2-EAP

Client

Client WIFI chip and driver: Intel Dual Band Wireless-AC 8265 running newest driver version 20.70.16.4 (driver date: 01/01/2020)

Steps to reproduce:

1. initialize default settings, then remove wpad-basic and install wpad-openssl OR hostapd-openssl to enable WPA3 AP mode
2. leave 802.11w to default setting which is “Required” 3. set country setting, ssid, and etc. as required such as radius for EAP
4 if use WPA2-PSK or WPA2-EAP with default settings, everything works fine.

5. switch WIFI (AC/N) to WPA2-PSK/WPA3-SAE mixed mode (sae+ccmp or something like that) OR WPA2-EAP/WPA3-EAP mixed mode (wpa3-mixed+ccmp or something like that)
6. apply settings wait until effective or reboot to take effect

6.1 __ssid won't come up on 802.11g/n interface__ if in PSK/SAE mixed mode.

7. Client (Intel 8265) won’t be able to connect to SSID,

7.1 if ssid would come up (802.11a/ac), it would be seen on client scan, but the client (Intel 8265) won't be able to connect to SSID, reports "Can't connect", in EAP mode, router side log "Deauthenticated due to local request" after "EAP-SUCCESS"

8. switch 802.11w to other settings, including “Optional”, problem remains, router config file /etc/config/wireless would list “option ieee80211w ‘1’” 9. switch 802.11w to other settings, including “Optional”, problem still remains, router config file /etc/config/wireless will be missing the “option ieee80211w” completely, and it seems wpad or hostapd would assume “optional” (code ‘1’) as default value instead of the documented “disabled” (code ‘0’).

Steps to workaround:

Manually set “option ieee80211w ‘0’” in /etc/config/wireless to disable 802.11w and don’t update settings through LUCI on the problematic ssid, restart wifi. Everything would work.

06.06.20203154KernelBug ReportVery LowHighXFRM state insert failure with AES-GCMopenwrt-19.07Unconfirmed Task Description

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

 

X86_64 arch, kernel fails to insert XFRM states with AES-GCM as transform.
Testable with
ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0×07 mode transport reqid 0×07 replay-window 32 aead ‘rfc4106(gcm(aes))’ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp

Works on Arch.
Result on X86_64 OpenWRT 19.07.3:
RTNETLINK answers: No such file or directory

On Arch 5.6.15-arch1-1, works (no output, ip x s shows the state).
Also fails 100% of the time when tested using an IKE keying daemon, e.g. strongSwan

08.06.20203160Base systemBug ReportVery LowHigh[opkg | odhcpd] installation collisionopenwrt-19.07Unconfirmed Task Description
{”kernel”:”4.14.180”,”hostname”:”OpenWrt”,”system”:”ARMv7 Processor rev 1 (v7l)”,”model”:”Turris Omnia”,”board_name”:”cznic,turris-omnia”,”release”:{”distribution”:”OpenWrt”,”version”:”19.07.3”,”revision”:”r11063-85e04e9f46”,”target”:”mvebu/cortexa9”,”description”:”OpenWrt 19.07.3 r11063-85e04e9f46”}}
—-
opkg install odhcpd
Installing odhcpd (2020-05-03-49e4949c-3) to root...
Downloading http://downloads.openwrt.org/releases/19.07.3/packages/arm_cortex-a9_vfpv3-d16/base/odhcpd_2020-05-03-49e4949c-3_arm_cortex-a9_vfpv3-d16.ipk
Collected errors:
 * check_data_file_clashes: Package odhcpd wants to install file /etc/init.d/odhcpd
        But that file is already provided by package  * odhcpd-ipv6only
 * check_data_file_clashes: Package odhcpd wants to install file /usr/sbin/odhcpd
        But that file is already provided by package  * odhcpd-ipv6only
 * check_data_file_clashes: Package odhcpd wants to install file /usr/sbin/odhcpd-update
        But that file is already provided by package  * odhcpd-ipv6only
 * opkg_install_cmd: Cannot install package odhcpd.


11.06.20203174Base systemBug ReportVery LowHigh[sysupgrade] unsupported GPT PARTUUID notationAllUnconfirmed Task Description

{”kernel”:”5.4.45”,”hostname”:”OpenWrt”,”system”:”ARMv7 Processor rev 1 (v7l)”,”model”:”Turris Omnia”,”board_name”:”cznic,turris-omnia”,”release”:{”distribution”:”OpenWrt”,”version”:”SNAPSHOT”,”revision”:”r13527-61307544d1”,”target”:”mvebu/cortexa9”,”description”:”OpenWrt SNAPSHOT r13527-61307544d1”}}


deploying from GPT partition

(. /lib/upgrade/common.sh; set -x; export_bootdevice)
+ export_bootdevice
+ local cmdline bootdisk rootpart uuid blockdev uevent line class
+ local MAJOR MINOR DEVNAME DEVTYPE
+ read cmdline
+ rootpart='PARTUUID=4d4ced8f-b95c-1142-9287-529911b660c6 rootflags=commit=5 rw cfg80211.freg=**'
+ rootpart='PARTUUID=4d4ced8f-b95c-1142-9287-529911b660c6'
+ '[' -e  ]
+ return 1
 

This patch sorts the issue

diff --git a/package/base-files/files/lib/upgrade/common.sh b/package/base-files/files/lib/upgrade/common.sh
index c375b70742..e718d0412b 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -154,7 +154,7 @@ export_bootdevice() {
                                        fi
                                done
                        ;;
-                       PARTUUID=????????-????-????-????-??????????02)
+                       PARTUUID=????????-????-????-????-????????????)
                                uuid="${rootpart#PARTUUID=}"
                                uuid="${uuid%02}00"
                                for disk in $(find /dev -type b); do


12.06.20203176Base systemBug ReportVery LowHighpi zero AP+STA mode does not workAllUnconfirmed Task Description

Supply the following if possible:
- device: Raspberry Pi Zero W
- Versions confirmed on: recent Snapshot, 19.07.3, 18.06.8, 17.01.4
- Steps to reproduce:

  1. flash image to sd card, put sd card into pi
  2. turn on wifi radio (uci set wireless.radio0.disabled=0)
  3. add a wireless network such that one is a station and one is a AP (I’ve tried though gui and command line)
  4. restart wifi (either through reboot or wifi command)
  5. Now in the dmesg you can see wlan0-1 cycling between blocking forwarding and disabled states

Additional info:
I made this forum post about it, but not much has come from that and I’ve learned a lot since posting.

I know that this mode is supported from the iw list output -

 valid interface combinations:
                 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
                   total <= 3, #channels <= 2
                 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
                   total <= 4, #channels <= 1
        Supported extended features:
                * [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
                * [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode

I’ve even gotten AP+STA mode to work by manually starting a second instance of hostapd (note that im not killing the original one), but that makes it even more confusing that it doesn’t work normally.

I make sure that they are on the same channel.

If you need anything cleared up please let me know. I’ve tried for over a week now to fix this myself to no avail.

14.06.20203181Base systemBug ReportVery LowHighunable to build 19.07.3 for clearfog proopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
Clearfog pro

- Software versions of OpenWrt/LEDE release, packages, etc.
tag 19.07.3
- Steps to reproduce
make fails:

export CROSS="arm-openwrt-linux-muslgnueabi-"  NO_RENAME=1 ; NM="arm-openwrt-linux-muslgnueabi-nm" STRIP="/home/oli/openwrt/staging_dir/host/bin/sstrip" STRIP_KMOD="/home/oli/openwrt/scripts/strip-kmod.sh" PATCHELF="/home/oli/openwrt/staging_dir/host/bin/patchelf" /home/oli/openwrt/scripts/rstrip.sh /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools
rstrip.sh: /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/usr/sbin/fw_printenv: executable
(cd /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/CONTROL; ( echo "$CONTROL"; printf "Description: "; echo "$DESCRIPTION" | sed -e 's,^[[:space:]]*, ,g'; ) > control; chmod 644 control; ( echo "#!/bin/sh"; echo "[ \"\${IPKG_NO_SCRIPT}\" = \"1\" ] && exit 0"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_postinst \$0 \$@"; ) > postinst; ( echo "#!/bin/sh"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_prerm \$0 \$@"; ) > prerm; chmod 0755 postinst prerm; echo "$V_Package_uboot_envtools_conffiles" > conffiles;  )
install -d -m0755 /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages
/home/oli/openwrt/scripts/ipkg-build -c -o 0 -g 0 /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages
/home/oli/openwrt/staging_dir/host/bin/find: '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/etc/config/ubootenv': No such file or directory
/home/oli/openwrt/staging_dir/host/bin/find: '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/etc/fw_env.config': No such file or directory
Packaged contents of /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools into /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages/uboot-envtools_2018.03-3_arm_cortex-a9_vfpv3-d16.ipk
echo "uboot-envtools" >> /home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/pkginfo/uboot-envtools.default.install
make[3]: Leaving directory '/home/oli/openwrt/package/boot/uboot-envtools'
time: package/boot/uboot-envtools/compile#1.27#0.68#1.71
make[3]: Entering directory '/home/oli/openwrt/package/boot/uboot-mvebu'
rm -f /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built
touch /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built_check
make  -C /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03 CROSS_COMPILE=arm-openwrt-linux-muslgnueabi- DTC="/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-4.14.180/scripts/dtc/dtc" HOSTCC="gcc" HOSTCFLAGS="-O2 -I/home/oli/openwrt/staging_dir/host/include -I/home/oli/openwrt/staging_dir/hostpkg/include -I/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/include -I/home/oli/openwrt/staging_dir/host/include -I/home/oli/openwrt/staging_dir/hostpkg/include -I/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/include -std=gnu11" HOSTLDFLAGS="-L/home/oli/openwrt/staging_dir/host/lib -L/home/oli/openwrt/staging_dir/hostpkg/lib -L/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/lib"
make[4]: Entering directory '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03'
  CHK     include/config/uboot.release
  CHK     include/generated/version_autogenerated.h
  CHK     include/generated/timestamp_autogenerated.h
  CC      lib/asm-offsets.s
  CHK     include/generated/generic-asm-offsets.h
  UPD     include/generated/generic-asm-offsets.h
  CC      arch/arm/lib/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  UPD     include/generated/asm-offsets.h
  HOSTLD  scripts/dtc/dtc
/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
make[6]: *** [scripts/Makefile.host:108: scripts/dtc/dtc] Error 1
make[5]: *** [scripts/Makefile.build:425: scripts/dtc] Error 2
make[4]: *** [Makefile:491: scripts] Error 2
make[4]: Leaving directory '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03'
make[3]: *** [Makefile:53: /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built] Error 2
make[3]: Leaving directory '/home/oli/openwrt/package/boot/uboot-mvebu'
time: package/boot/uboot-mvebu/clearfog/compile#0.32#0.20#0.51
make[2]: *** [package/Makefile:113: package/boot/uboot-mvebu/compile] Error 2
make[2]: Leaving directory '/home/oli/openwrt'
make[1]: *** [package/Makefile:107: /home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/oli/openwrt'
make: *** [/home/oli/openwrt/include/toplevel.mk:227: world] Fehler 2
18.06.20203190KernelBug ReportVery LowHighKernel Oops and reboot on ipq806x (EA8500): msm_read_ti...TrunkUnconfirmed Task Description

This happened on OpenWrt SNAPSHOT r13520-68b94f0fb4, but it’s pretty random. I haven’t been able to figure out what causes it. It usually happens at least once within a week. I’m not sure why there’s no call stack here, I also tried `cat /sys/kernel/debug/crashlog` a few hours after it happened and got a “No such file or directory”.

# uname -a
Linux EA8500S 5.4.43 #0 SMP Mon Jun 8 19:16:17 2020 armv7l GNU/Linux


[333045.256692] 8<--- cut here ---
[333045.256733] Unable to handle kernel NULL pointer dereference at virtual address 0000000a
[333045.258656] pgd = 8948efb0
[333045.267139] [0000000a] *pgd=00000000
[333045.269709] Internal error: Oops: 5 [#1] SMP ARM
[333045.273404] Modules linked in: nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet ath10k_pci ath10k_core ath nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_ct nft_counter nf_tables_set nf_tables nf_conntrack_netlink mac80211 iptable_nat ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_MASQUERADE xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY ts_fsm ts_bm nfnetlink nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_rtsp nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtsp nf_conntrack_rtcache
[333045.273734]  nf_conntrack_pptp nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conncount iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables compat asn1_decoder fuse act_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 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 ledtrig_usbport ledtrig_heartbeat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel ipcomp esp4 ah4 tunnel6 tunnel4 tun xfrm_user xfrm_ipcomp af_key xfrm_algo vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp437 sha1_generic md5 echainiv des_generic libdes cbc authenc usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom ohci_platform ohci_hcd phy_qcom_dwc3 ahci fsl_mph_dr_of ehci_platform ehci_fsl sd_mod ahci_platform libahci_platform libahci libata scsi_mod
[333045.343201]  ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 exfat(C) crc32c_generic
[333045.452936] CPU: 0 PID: 10391 Comm: kworker/0:2 Tainted: G         C        5.4.43 #0
[333045.460735] Hardware name: Generic DT based system
[333045.468481] Workqueue: events dbs_work_handler
[333045.473245] PC is at msm_read_timer_count+0xc/0x18
[333045.477746] LR is at msm_read_current_timer+0x1c/0x28
[333045.482608] pc : [<c0733ea8>]    lr : [<c0733ee4>]    psr: a0000013
[333045.487814] sp : da0f1dc0  ip : 00000000  fp : dce52880
[333045.494327] r10: ddb8d010  r9 : dd648b40  r8 : 16e36000
[333045.499619] r7 : dd511240  r6 : 00000006  r5 : 00000001  r4 : c0c68ea0
[333045.504919] r3 : 00000006  r2 : 1fffa6f0  r1 : 20000013  r0 : c0c28428
[333045.511261] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
20.06.20203195Base systemBug ReportVery LowHighramips/mt7621/zbt3526 -> boot failure with kernel 5.4TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: ZBT 3526-16MB + 32 MB - Software versions of OpenWrt/LEDE: current trunk (kernel 5.4)
- Steps to reproduce: when i update the firmware, i see that there is a network after reboot for ~10sec, and then it is gone, and is not accessable, seeems to be, that something is crashing.
i can only hard-reset - nothing else.

any idea ?
maybe it is related also like the other bugs reported ? for bootloop or hanging/crashing mt7621 ?

 


26.06.20203204KernelBug ReportVery LowHighmac80211 crashTrunkUnconfirmed Task Description

Netgear R7800 running hnyman’s build master-r13625-d4dea7efcd-20200624-ath10k

[104369.085841] ------------[ cut here ]------------
[104369.091780] WARNING: CPU: 0 PID: 0 at backports-5.7-rc3-1/net/mac80211/sta_info.c:1929 ieee80211_sta_update_pending_airtime+0x1f8/0x1fc [mac80211]
[104369.096329] STA f0:18:xxxxx AC 2 txq pending airtime underflow: 4294967244, 52
[104369.096332] Modules linked in: pppoe ppp_async ath10k_pci ath10k_core ath pptp pppox ppp_mppe ppp_generic mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_MASQUERADE xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY wireguard slhc sch_cake nf_reject_ipv4 nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_netlink nf_conncount iptable_raw iptable_nat iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt compat chaoskey fuse 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 ledtrig_usbport ledtrig_heartbeat xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac
[104369.109593]  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 ip6table_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_NPT nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos ip_gre gre ifb ip6_udp_tunnel udp_tunnel sit tunnel4 ip_tunnel tun vfat fat hfsplus cifs nls_utf8 nls_iso8859_15 nls_iso8859_1 nls_cp850 nls_cp437 nls_cp1250 sha1_generic md5 md4 ecb des_generic libdes arc4 usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom ohci_platform ohci_hcd phy_qcom_dwc3 ahci fsl_mph_dr_of ehci_platform ehci_fsl sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 exfat(C) crc32c_generic
[104369.256372] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        5.4.48 #0
[104369.278522] Hardware name: Generic DT based system
[104369.286004] [<c030f954>] (unwind_backtrace) from [<c030b96c>] (show_stack+0x14/0x20)
[104369.290607] [<c030b96c>] (show_stack) from [<c08ba2e0>] (dump_stack+0x94/0xa8)
[104369.298594] [<c08ba2e0>] (dump_stack) from [<c031e7b4>] (__warn+0xb4/0xd0)
[104369.305702] [<c031e7b4>] (__warn) from [<c031e850>] (warn_slowpath_fmt+0x80/0x90)
[104369.312720] [<c031e850>] (warn_slowpath_fmt) from [<bf691af0>] (ieee80211_sta_update_pending_airtime+0x1f8/0x1fc [mac80211])
[104369.320482] [<bf691af0>] (ieee80211_sta_update_pending_airtime [mac80211]) from [<bf68d734>] (ieee80211_tx_monitor+0xe38/0x10c0 [mac80211])
[104369.331785] [<bf68d734>] (ieee80211_tx_monitor [mac80211]) from [<bf68da18>] (ieee80211_tx_status+0x5c/0x6c [mac80211])
[104369.344456] [<bf68da18>] (ieee80211_tx_status [mac80211]) from [<bf7588e4>] (ath10k_txrx_tx_unref+0x130/0x318 [ath10k_core])
[104369.355280] [<bf7588e4>] (ath10k_txrx_tx_unref [ath10k_core]) from [<bf755264>] (ath10k_htt_txrx_compl_task+0x7d0/0x1058 [ath10k_core])
[104369.366428] [<bf755264>] (ath10k_htt_txrx_compl_task [ath10k_core]) from [<bf7a3b3c>] (ath10k_pci_napi_poll+0x58/0x11c [ath10k_pci])
[104369.378748] [<bf7a3b3c>] (ath10k_pci_napi_poll [ath10k_pci]) from [<c0773a2c>] (net_rx_action+0x118/0x374)
[104369.390603] [<c0773a2c>] (net_rx_action) from [<c0302298>] (__do_softirq+0x130/0x2d4)
[104369.400148] [<c0302298>] (__do_softirq) from [<c0322c10>] (irq_exit+0xbc/0xe0)
[104369.408132] [<c0322c10>] (irq_exit) from [<c036d150>] (__handle_domain_irq+0x6c/0xd0)
[104369.415343] [<c036d150>] (__handle_domain_irq) from [<c05c6774>] (gic_handle_irq+0x5c/0xb8)
[104369.423324] [<c05c6774>] (gic_handle_irq) from [<c0301a8c>] (__irq_svc+0x6c/0x90)
[104369.431910] Exception stack(0xc0c01ee0 to 0xc0c01f28)
[104369.439303] 1ee0: 00000000 00005eec 1ce52000 dd991a00 dcc2d400 00000000 dd990df0 00005eec
[104369.444430] 1f00: 00005eec 00000000 524739a0 5244a280 00000015 c0c01f30 c0716b90 c0716b94
[104369.452661] 1f20: 20000013 ffffffff
[104369.460907] [<c0301a8c>] (__irq_svc) from [<c0716b94>] (cpuidle_enter_state+0x94/0x498)
[104369.464643] [<c0716b94>] (cpuidle_enter_state) from [<c0716fdc>] (cpuidle_enter+0x30/0x4c)
[104369.472716] [<c0716fdc>] (cpuidle_enter) from [<c034a7ec>] (do_idle+0x1d8/0x240)
[104369.480787] [<c034a7ec>] (do_idle) from [<c034aafc>] (cpu_startup_entry+0x1c/0x20)
[104369.488425] [<c034aafc>] (cpu_startup_entry) from [<c0b00e58>] (start_kernel+0x4d8/0x4e8)
[104369.495990] ---[ end trace 713bf4bd85eb5631 ]---
27.06.20203207Base systemBug ReportVery LowHighSetting MTU on Bridged interfaces does not set MTU on m...openwrt-19.07Unconfirmed Task Description

- Device problem occurs on - x86
- Software versions of OpenWrt/LEDE release, packages, etc. - 19.07.3

 

I think it’s a bug/overlooked use case, but when you have interfaces bridged in the UCI config, the MTU setting does not get applied to the member interfaces (physical or VLAN).

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.1'
        option type 'bridge'
        option mtu '9000'
        option ifname 'eth1 eth4.10'

When I boot using this config I have connectivity issues with devices using Jumbo frames. ifconfig confirms that MTUs on the members interfaces are still at default 1500.

eth1      Link encap:Ethernet  HWaddr 0C:C4:7A:AB:39:3D
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:df440000-df45ffff

eth4      Link encap:Ethernet  HWaddr 3C:FD:FE:BB:01:50
          inet6 addr: fe80::3efd:feff:febb:150/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
          RX packets:50176 errors:0 dropped:1 overruns:0 frame:0
          TX packets:37468 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15692679 (14.9 MiB)  TX bytes:29263711 (27.9 MiB)

eth4.10   Link encap:Ethernet  HWaddr 3C:FD:FE:BB:01:50
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36728 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20850 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9314410 (8.8 MiB)  TX bytes:26473088 (25.2 MiB)

I have to manually use the ifconfig tool to set the MTU (i.e. ifconfig eth4.10 mtu 9000) to get the network back up and running correctly.

Obviously these commands could be scritped, however it was my understanding the UCI network config should be doing this .

02.07.20203213KernelBug ReportVery LowHighLantiq-XRX200: Fritzbox 7360 SL PCie Link up failes! - ...TrunkUnconfirmed Task Description

On my Lantiq-XRX200 device Fritzbox 7360 SL, the WIFI PHy doesnt gets detected anymore. right after 1 second when booting the device. i get a kernel warning that the “PCIe PHY cant get detected and right after that 5 lines of
“PCIe phy_link_up timeout”

This happend in release of 19.07.x and trunk.

 

[ 0.864077] ifx_pcie_wait_phy_link_up timeout
[ 1.081343] ifx_pcie_wait_phy_link_up timeout
[ 1.298569] ifx_pcie_wait_phy_link_up timeout
[ 1.302795] pcie_rc_initialize link up failed!!!!!

22.07.20203242Base systemBug ReportVery LowHighUAS not working - All devices with USB3.0 affectedAllUnconfirmed Task Description

USB controller “f10f8000.usb3” is preventing UAS from working on OpenWRT devices, as dmesg states:

[ 1.830001] usb 3-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 1.860632] usb 3-1: USB controller f10f8000.usb3 does not support streams, which are required by the UAS driver.
[ 1.870949] usb 3-1: Please try an other USB controller if you wish to use UAS.
[ 1.878291] usb-storage 3-1:1.0: USB Mass Storage device detected

Checked in OpenWRT 18.04 and 19.03 with Linksys WRT3200ACM and Turris Omnia. This impacts USB3.0 speeds.

To reproduce just hook up a USB3.0 HDD to a OpenWRT device on the USB3.0 port and see dmesg.

Is it possible to try another controller or fix f10f8000.usb3?

23.07.20203244KernelBug ReportVery LowHighath9k_htc: Kernel oops in snapshot on RaspberryPi 4 (at...TrunkUnconfirmed Task Description

- Device: Raspberry Pi4
- Snapshot kernel 5.4 with 5.7 backport
- Install ath9k_htc dongle and connect WiFi client

So, I have been able to tackle down who is causing a kernel panic and reboot of my RPi4 with current snapshots.

It is the ath9k_htc dongle I use but only if there are clients connected to it
Apparently it corrupts memory so the kernel panic look quite different among them, here two caputer with serial:

```
[75789.085223] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000008
[75789.095930] Mem abort info:
[75789.098716] ESR = 0×96000045 [75789.101763] EC = 0×25: DABT (current EL), IL = 32 bits
[75789.107068] SET = 0, FnV = 0
[75789.110113] EA = 0, S1PTW = 0
[75789.113246] Data abort info:
[75789.116118] ISV = 0, ISS = 0×00000045 [75789.119945] CM = 0, WnR = 1
[75789.122906] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000f6f67000
[75789.129339] [0000000000000008] pgd=0000000000000000, pud=0000000000000000
[75789.136124] Internal error: Oops: 96000045 [#1] SMP
[75789.140994] Modules linked in: ath9k_htc ath9k_common xt_connlimit rt2800usb rt2800lib rt2500usb pppoe ppp_async nf_conncount iptable_nat brcmfmac ath9k_hw ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT rtl8812au rt2x00usb rt2x00lib pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack mt76x2u mt76x2e mt76x2_common mt76x02_usb mt76x02_lib mt7603e mt7601u mt76_usb mt76 mac80211 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 wireguard usbhid slhc sch_cake nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables hid_generic crc_ccitt compat brcmutil sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic
[75789.141074] act_skbedit act_mirred snd_bcm2835(C) hid evdev ledtrig_heartbeat xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport 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 nat46 ip6_udp_tunnel udp_tunnel sit tunnel4 ip_tunnel tun snd_rawmidi snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_mixer_oss snd_hwdep snd_compress snd soundcore nls_utf8 md5 vfat fat nls_iso8859_1 nls_cp437
[75789.289825] CPU: 3 PID: 721 Comm: hostapd Tainted: G C 5.4.51 #0
[75789.297125] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[75789.302950] pstate: 20400085 (nzCv daIf +PAN -UAO)
[75789.307739] pc : skb_try_recv_from_queue+0×164/0x1a0
[75789.312869] lr :
skb_try_recv_datagram+0xb0/0x1a8
[75789.317737] sp : ffffffc011553aa0
[75789.321041] x29: ffffffc011553aa0 x28: ffffffc011553bbc
[75789.326344] x27: 0000000000000000 x26: ffffff80f2ccb8d0
[75789.331646] x25: 0000000000000000 x24: ffffffc011553b90
[75789.336949] x23: 0000000000000000 x22: 0000000000000000
[75789.342251] x21: ffffffc011553bbc x20: 0000000000000000
[75789.347553] x19: ffffff80f1e51000 x18: 0000000000000000
[75789.352855] x17: 0000000000000000 x16: 0000000000000000
[75789.358157] x15: 0000000000000000 x14: 0000000000000000
[75789.363459] x13: 0000000000000000 x12: 0000000000000000
[75789.368762] x11: 0000000000000000 x10: 00000055b6805320
[75789.374064] x9 : ffffff80f5090800 x8 : 0000000000000040
[75789.379366] x7 : ffffffc01056a890 x6 : ffffffc011553b90
[75789.384668] x5 : ffffffc011553b4c x4 : ffffffc011553bbc
[75789.389970] x3 : 0000000000000000 x2 : 0000000000000000
[75789.395272] x1 : ffffff80f2ccb8d0 x0 : ffffff80f2ccb800
[75789.400575] Call trace:
[75789.403014] skb_try_recv_from_queue+0×164/0x1a0
[75789.407796]
skb_try_recv_datagram+0xb0/0x1a8
[75789.412318] skb_recv_datagram+0×84/0xa8
[75789.416405] skb_recv_datagram+0×28/0×30 [75789.420320] netlink_recvmsg+0×48/0×330 [75789.424147] sock_recvmsg+0x1c/0×28 [75789.427626]
sys_recvmsg+0×84/0x3e8
[75789.431452]
_sys_recvmsg+0×64/0×88 [75789.435107] sys_recvmsg+0×40/0×80 [75789.438673] arm64_sys_recvmsg+0×20/0×28 [75789.442762] el0_svc_handler+0xd4/0×130 [75789.446588] el0_svc+0×8/0xc
[75789.449464] Code: 51000442 b9001022 a9400662 a9007e7f (f9000441)
[75789.455549] —[ end trace 49dce345634ad00c ]— [75789.460156] Kernel panic - not syncing: Fatal exception
[75789.465373] SMP: stopping secondary CPUs
[75789.469289] Kernel Offset: disabled
[75789.472768] CPU features: 0×0002,20006000
[75789.476766] Memory Limit: none
[75789.479813] Rebooting in 3 seconds..
```

```
[22276.297087] Unable to handle kernel access to user memory with fs=KERNEL_DS at virtual address 000000000000004c
[22276.307207] Mem abort info:
[22276.309997] ESR = 0×96000005 [22276.313075] EC = 0×25: DABT (current EL), IL = 32 bits
[22276.318389] SET = 0, FnV = 0
[22276.321436] EA = 0, S1PTW = 0
[22276.324575] Data abort info:
[22276.327453] ISV = 0, ISS = 0×00000005 [22276.331287] CM = 0, WnR = 0
[22276.334255] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000f1f36000
[22276.340696] [000000000000004c] pgd=00000000f40b0003, pud=00000000f40b0003, pmd=0000000000000000
[22276.349401] Internal error: Oops: 96000005 [#1] SMP
[22276.354272] Modules linked in: ath9k_htc ath9k_common xt_connlimit rt2800usb rt2800lib rt2500usb pppoe ppp_async nf_conncount iptable_nat brcmfmac ath9k_hw ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT rtl8812au rt2x00usb rt2x00lib pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack mt76x2u mt76x2e mt76x2_common mt76x02_usb mt76x02_lib mt7603e mt7601u mt76_usb mt76 mac80211 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 wireguard usbhid slhc sch_cake nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables hid_generic crc_ccitt compat brcmutil sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic
[22276.354354] act_skbedit act_mirred snd_bcm2835(C) hid evdev ledtrig_heartbeat xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport 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 nat46 ip6_udp_tunnel udp_tunnel sit tunnel4 ip_tunnel tun snd_rawmidi snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_mixer_oss snd_hwdep snd_compress snd soundcore nls_utf8 md5 vfat fat nls_iso8859_1 nls_cp437
[22276.503133] CPU: 2 PID: 1883 Comm: sh Tainted: G C 5.4.51 #0
[22276.510088] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[22276.515916] pstate: 60400005 (nZCv daif +PAN -UAO)
[22276.520710] pc : vfs_read+0xc/0×158 [22276.524192] lr : kernel_read+0×40/0×88 [22276.527933] sp : ffffffc016943c80
[22276.531240] x29: ffffffc016943c80 x28: 0000000000000000
[22276.536546] x27: 0000000000000002 x26: ffffffc01080bf60
[22276.541853] x25: ffffff80f50d8c80 x24: ffffffc010960cd8
[22276.547158] x23: 00000000fffffff8 x22: ffffff80f52d8438
[22276.552463] x21: ffffff80f52d8400 x20: 0000007fffffffff
[22276.557769] x19: ffffff80f2c68000 x18: 0000000000000000
[22276.563074] x17: 0000000000000000 x16: 0000000000000000
[22276.568379] x15: 00000000008a4000 x14: 0000000000000001
[22276.573684] x13: 0000000000000b90 x12: 0000000000000b90
[22276.578989] x11: 0000000000474470 x10: 0000000000474470
[22276.584295] x9 : 0000000000064470 x8 : 000000046474e552
[22276.589600] x7 : 0000000000000000 x6 : 0000000000000000
[22276.594906] x5 : 0000000000000000 x4 : 0000000000000020
[22276.600211] x3 : ffffffc016943da8 x2 : 000000000000001a
[22276.605516] x1 : ffffff80f50d8c80 x0 : 0000000000000008
[22276.610821] Call trace:
[22276.613263] vfs_read+0xc/0×158 [22276.616397] kernel_read+0×40/0×88 [22276.619795] load_elf_binary+0xf4/0xd08
[22276.623624] search_binary_handler.part.55+0xac/0×278 [22276.628669] do_execve_file+0x4c4/0x6a8
[22276.632671]
arm64_sys_execve+0×38/0×48 [22276.636676] el0_svc_handler+0xd4/0×130 [22276.640505] el0_svc+0×8/0xc
[22276.643386] Code: d503201f a9bc7bfd 910003fd a90363f7 (b9404404)
[22276.649475] —[ end trace 081a8415f22be558 ]— [22276.654086] Kernel panic - not syncing: Fatal exception
[22276.659307] SMP: stopping secondary CPUs
[22276.663223] Kernel Offset: disabled
[22276.666705] CPU features: 0×0002,20006000
[22276.670706] Memory Limit: none
[22276.673756] Rebooting in 3 seconds..
```

I have tried two different RPi4 hardware and two different SD cards. No other devices are connected to the USB ports,ath9k_htc dongle is connected to USB 2.0 port.

With 19.07.x on a Orangepi PC2 device, the same dongle behaved correctly

 


28.07.20203252Base systemBug ReportVery LowHighX86 kernel has no emmc support, cause it can't boot fro...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: Z83II mini pc. https://www.minipcdb.com/articles/Meet-Z83II-Mini-PC - Software versions of OpenWrt/LEDE release, packages, etc. Tested on both 19.07.3 and latest snapshots, both failed.
- Steps to reproduce: Write to image to the embedded emmc disk and boot it.

I’ve tested both 19.07.3 and latest snapshots build of openwrt x86-64 build on the Intel Z8350 fanless mini PC. Both failed to boot. The kernel can boot up correctly, but the system hang at waiting for root device. If the image is burned on USB disk, it can boot up correctly without any issue.

I searched on Google and found this post - https://forum.archive.openwrt.org/viewtopic.php?id=72195

I did the test on 19.07.3 and verified the system can boot up correctly from embedded emmc storage that by adding the following two options into the target/linux/x86/64/config-default file
CONFIG_MMC_SDHCI_ACPI
CONFIG_X86_INTEL_LPSS

Could you approve to add the options into the future update to support booting from emmc storage?
Thanks!

 


06.08.20203273KernelBug ReportVery LowHighVLAN isolation failed on ipq40xx (GL-B1300)TrunkUnconfirmed Task Description

ipq40xx GL-B1300 OpenWrt snapshot

It seems that recent snapshots broke vlan isolation, I guess https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9da2b567605b0964d921b9ca4f0c9886db4f636d should be responsible.

More information on https://forum.openwrt.org/t/vlan-isolation-failed-on-ipq40xx-gl-b1300

06.08.20203274KernelBug ReportVery LowHighAn error is reported at each start-up phaseAllUnconfirmed Task Description

1.Error log:
[ 63.368179] i915 0000:00:02.0: Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
[ 63.379745] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

2.Problem:Sometimes the power is suddenly cut off and the machine crashes

3.System information:
Intel(R) Celeron(R) J4105 CPU @ 1.50GHz : 4 Core 4 Thread
OpenWrt R20.7.20 / LuCI Master (git-20.191.45716-b73d3a4)

4.I tried to use the graphics driver to the kernel.The mistake did not disappear.In addition, I swiped in the latest firmware compiled by others.The problem remains
I tried to upgrade the kernel to 5.4.56, which did not solve the problem.Please help me

11.08.20203281PackagesBug ReportVery LowHighdnsmasq: option nonwildcard=0 and localservice=1 can no...TrunkUnconfirmed Task Description

Latest snapshot OpenWrt

It can be reproduced on many platform, you can just verify with Virtualbox and x86 images.

First restore to factory, then set ‘option nonwildcard=0’, reboot, ssh to OpenWrt, run ‘nslookup he.net’, you will get ‘;; connection timed out; no servers could be reached’ error, manually restarting dnsmasq service or setting ‘option localservice=0’ could fix it.

13.08.20203282Base systemBug ReportVery LowHigh[bug/crypto] rockchip: nanopi r2s crypto performance is...TrunkUnconfirmed Task Description

Hello everyone.

I found a serious crypto performance problem with NanoPi R2S.

Some proxy softwares, like shadowsocks-libev, can only reach to low
speed (about ~13 MB/s with aes-128-gcm). On this board, I don’t think
it’s normal.

Otherwise, all the chippers perform terriblly, not just aes-128-gcm.
I tried run commands like openssl speed -evp aes-128-gcm, and the
scores were good, but when running other softwares like trojan which
using openssl to crypt / decrypt, the speed totally doesn’t match the
score.

I’ve ever tried to enable the kernel crypto modules, but it seemded to
be useless.

15.08.20203285KernelBug ReportVery LowHighCan't change MTU on IPQ806x devicesTrunkUnconfirmed Task Description

- I’ve personally tested it on ZyXEL NBG6817
- Any version with https://patchwork.kernel.org/patch/11283121/ patch applied
- To reproduce:
# ifdown wan
# ifconfig (wan_interface) MTU 1499 (or 1501 or anything other than 1500)

This bug is caused by txfifosz being 0 on IPQ806x devices (and possibly more) unless tx-fifo-depth is specified in device tree, potential fix would be to specify tx-fifo-depth in device tree for all affected devices, or, check if txfifosz == 0 and then allow MTU change.

24.08.20203303Base systemBug ReportVery LowHighntfs drive not mountingTrunkUnconfirmed Task Description

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

 

This problem is occurring on a BT HomeHub 5A. I have two of these and the problem happens on both of them. I am currently using V5.X and the issue is only here but it is working in v19.07.3.

The issue is that I am not able to auto-mount my NTFS drive with bootup through fstab.
The error is as follows:

Sun Aug 23 21:56:03 2020 kern.notice kernel: [   11.711119] scsi 0:0:0:0: Direct-Access     Seagate  Expansion        0608 PQ: 0 ANSI: 6
Sun Aug 23 21:56:03 2020 kern.notice kernel: [   11.725022] sd 0:0:0:0: [sda] 976773167 512-byte logical blocks: (500 GB/466 GiB)
Sun Aug 23 21:56:03 2020 kern.notice kernel: [   11.733044] sd 0:0:0:0: [sda] Write Protect is off
Sun Aug 23 21:56:03 2020 kern.debug kernel: [   11.736665] sd 0:0:0:0: [sda] Mode Sense: 4f 00 00 00
Sun Aug 23 21:56:03 2020 kern.notice kernel: [   11.738710] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sun Aug 23 21:56:03 2020 kern.warn kernel: [   11.739527] overlayfs: upper fs does not support xattr, falling back to index=off and metacopy=off.
Sun Aug 23 21:56:03 2020 kern.info kernel: [   12.012011]  sda: sda1
Sun Aug 23 21:56:03 2020 kern.notice kernel: [   12.020464] sd 0:0:0:0: [sda] Attached SCSI disk

Sun Aug 23 21:56:10 2020 daemon.err block: No "mount.ntfs" utility available
Sun Aug 23 21:56:10 2020 daemon.err block: mounting /dev/sda1 (ntfs) as /tmp/data-hdd failed (25) - Not a tty

Although I can mount the drive manually through ntfs-3g and the package is already installed but somehow the system thinks it is not available. For now the workaround is to manually mount the drive when the boot ends.

Please fix this issue thanks.

05.09.20203319Base systemBug ReportVery LowHigherratic behaviour wireless network control on system wi...TrunkUnconfirmed Task Description

Device: Ubiquiti Routerstation (ar71xx)
Software: OpenWrt SNAPSHOT, r14382+7-ad0f0df909 (local compilation after Sep 3 2020 git pull)
Symptoms: commands like ‘wifi up wlan1’ on a system with wlan0, wlan1, and wlan2 (phy0,1,2) , make other wlanN disapperar than wlan1.
plus in dmesg messages like
[ n.n] do_page_fault(): sending SIGSEGV to hostapd for invalid write access to 00000000
[ n.n] epc = 77e79e6c in libc.so[77e4c000+9c000]
[ n.s] ra = 77e1e309 in libubus.so[77e1c000+13000]

Bug found through experimentation:
script: /lib/netifd/wireless/mac80211.sh
function: drv_mac80211_teardown()
line: json_select data
problem: ‘data’ does not produce phy, ‘config’ does.
corrected line: json_select config

Going though experimentations also found that there may be problems in
script: /lib/netifd/hostapd.sh
function: wpa_supplicant_run()
line: ubus call wpa_supplicant config_add
and the lines that follow with parameters and line continuations.
Replaced:

ubus call wpa_supplicant config_add "{ \
	\"driver\": \"${_w_driver:-wext}\", \"ctrl\": \"$_rpath\", \
	\"iface\": \"$ifname\", \"config\": \"$_config\" \
	${network_bridge:+, \"bridge\": \"$network_bridge\"} \
	${hostapd_ctrl:+, \"hostapd_ctrl\": \"$hostapd_ctrl\"} \
	}"

By:

local br=${network_bridge:+',"bridge":"'$network_bridge'"'}
local hc=${hostapd_ctrl:+',"hostapd_ctrl":"'$hostapd_ctrl'"'}
local jsonstr='{"driver":"'${_w_driver:-wext}'","iface":"'${ifname}'"'${br}${hc}',"ctrl":"'${_rpath}'","config":"'${_config}'"}'
ubus call wpa_supplicant config_add ${jsonstr}

because in a separate test script just to see the workings of the original I could not get it to work due to the nested parameter substitution.
Have removed all the \” as the " do not need to be escaped when within single quotes.


11.09.20203332Base systemBug ReportVery LowHighpacket loss on miwifi-mini @ 19.07.4openwrt-19.07Assigned Task Description

mt7620 / miwifi-mini
19.07.3 works fine
19.07.4 works bad:

kern.err kernel: [ 6615.438086] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
kern.info kernel: [ 6615.444416] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:80000065
kern.info kernel: [ 6615.450586] mtk_soc_eth 10100000.ethernet eth0: tx_ring=0, base=07780000, max=1024, ctx=17, dtx=17, fdx=16, next=17
kern.info kernel: [ 6615.461258] mtk_soc_eth 10100000.ethernet eth0: rx_ring=0, base=06408000, max=1024, calc=47, drx=48
kern.err kernel: [ 6619.306350] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
kern.info kernel: [ 6619.312684] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:80000065
kern.info kernel: [ 6619.318854] mtk_soc_eth 10100000.ethernet eth0: tx_ring=0, base=07780000, max=1024, ctx=28, dtx=28, fdx=16, next=28
kern.info kernel: [ 6619.329525] mtk_soc_eth 10100000.ethernet eth0: rx_ring=0, base=06470000, max=1024, calc=63, drx=64
kern.err kernel: [ 6623.157217] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
kern.info kernel: [ 6623.163553] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:80000065
kern.info kernel: [ 6623.169720] mtk_soc_eth 10100000.ethernet eth0: tx_ring=0, base=07780000, max=1024, ctx=25, dtx=25, fdx=16, next=25
kern.info kernel: [ 6623.180398] mtk_soc_eth 10100000.ethernet eth0: rx_ring=0, base=06408000, max=1024, calc=59, drx=60
14.09.20203338Base systemBug ReportVery LowHighTL-WR841N v13 unstable Ethernet and WiFi workopenwrt-19.07Unconfirmed Task Description

I am using default build of OpenWRT 19.07.4 for TL-WR841N v13 without any additional packages. I have Ethernet PPPoE from provider, some ethernet and WiFi WPA2 clients. WiFi and Ethernet are unstable: they can disappear for 30-60 seconds without any serious reason. On 18.06.8 there wasn’t those problems. I attached system log. Thanks for help.

19.09.20203350KernelBug ReportVery LowHighKernel Warning in module mac80211/tx.copenwrt-19.07Unconfirmed Task Description

Hi,

I am using the following with the latest update of openwrt:

Model Netgear R6220
Architecture MediaTek MT7621 ver:1 eco:3
Firmware Version OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.260.30581-915a64c
Kernel Version 4.14.195

The problem occured already with 19.07.3 several times, so I upgraded to 19.07.4, but the problem remains.
The wifi module kept crashing and in consequence a part of the wifi devices cannot connect anymore. Sometimes the router
recovers by itself, sometimes not and a reboot is necessary to get wifi working again. It mostly affects the 2,4 GHz band
and not the 5 GHz band, but that might be related which device is renewing DHCP or which ones are not (I am not sure).
A reboot solves the problem, but after some time, the problem occurs again. After the below warning, the router runs without
further problems for 2 days now. So it seems pretty rare. Nevertheless, the same hardware was working fine with 18.x
openwrt for a year at least. No kernel warning at the time. I cannot completely rule out that the HW is broken as it is
of age, as you can see. Any hint on what I should report or test myself is welcome! I can help debug and even install
updates that should fix the problem, if necessary. The router ist just used as an access point - routing is taking
place elsewhere.

Here is the korresponding kernel warning, where I included the immediate log entries before and after:

Thu Sep 17 22:02:05 2020 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5680 ht_enabled=1 chan_offset=-1 chan_width=2 cf1=5670 cf2=0
Thu Sep 17 22:02:05 2020 daemon.notice hostapd: wlan1: DFS-NEW-CHANNEL freq=5220 chan=44 sec_chan=1
Thu Sep 17 22:02:05 2020 daemon.info hostapd: wlan1: IEEE 802.11 driver starting channel switch: freq=5220, ht=1, vht_ch=0×0, offset=1, width=2 (40 MHz), cf1=5230, cf2=0
Thu Sep 17 22:02:05 2020 daemon.notice hostapd: wlan1: CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5220 ht_enabled=1 ch_offset=1 ch_width=40 MHz cf1=5230 cf2=0 dfs=0
Thu Sep 17 22:02:06 2020 daemon.info hostapd: wlan1: IEEE 802.11 driver had channel switch: freq=5220, ht=1, vht_ch=0×0, offset=1, width=2 (40 MHz), cf1=5230, cf2=0
Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: CTRL-EVENT-CHANNEL-SWITCH freq=5220 ht_enabled=1 ch_offset=1 ch_width=40 MHz cf1=5230 cf2=0 dfs=0
Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: AP-CSA-FINISHED freq=5220 dfs=0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.685439] ————[ cut here ]———— Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.694747] WARNING: CPU: 1 PID: 14 at backports-4.19.137-1/net/mac80211/tx.c:4292 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.716632] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_netlink nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT slhc nfnetlink nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack 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 leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.858467] usbcore nls_base usb_common
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.866285] CPU: 1 PID: 14 Comm: ksoftirqd/1 Not tainted 4.14.195 #0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.878915] Stack : 00000000 00000000 00000000 86dae9b0 00000000 00000000 00000000 00000000
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.895548] 00000000 00000000 00000000 00000000 00000000 00000001 87c67b70 53261622
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.912178] 87c67c08 00000000 00000000 00006298 00000038 8049c858 00000008 00000000
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.928810] 00000000 80550000 000d37ed 00000000 87c67b50 00000000 00000000 877e7fd0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.945442] 877acbc4 000010c4 86f0a480 86dae9b0 00000003 802ad210 00000004 806b0004
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.962073] ...
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.966931] Call Trace:
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.966973] [<8049c858>] 0x8049c858
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.978757] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.990532] [<802ad210>] 0x802ad210
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.997462] [<8000c1a0>] 0x8000c1a0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.004393] [<8000c1a8>] 0x8000c1a8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.011325] [<804856b4>] 0x804856b4
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.018260] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.030029] [<80072a84>] 0x80072a84
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.036956] [<8002e608>] 0x8002e608
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.043892] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.055668] [<8002e6f0>] 0x8002e6f0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.062600] [<80053b7c>] 0x80053b7c
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.069536] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.081310] [<877af408>] 0x877af408 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.093086] [<80067ca8>] 0x80067ca8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.100018] [<80017f6c>] 0x80017f6c
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.106957] [<87777b90>] 0x87777b90 [mt76x02_lib@87770000+0×9700]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.119081] [<877af86c>] 0x877af86c [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.130870] [<87777bd0>] 0x87777bd0 [mt76x02_lib@87770000+0×9700]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.142999] [<877b65e0>] 0x877b65e0 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.154789] [<877b66bc>] 0x877b66bc [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.166573] [<87774a94>] 0x87774a94 [mt76x02_lib@87770000+0×9700]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.178702] [<800329f4>] 0x800329f4
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.185630] [<804a3658>] 0x804a3658
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.192561] [<8004fd10>] 0x8004fd10
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.199494] [<8004fd10>] 0x8004fd10
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.206420] [<80032cc8>] 0x80032cc8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.213348] [<8004feb8>] 0x8004feb8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.220280] [<8049ebd8>] 0x8049ebd8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.227208] [<8004bf38>] 0x8004bf38
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.234139] [<8004be08>] 0x8004be08
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.241070] [<8004be08>] 0x8004be08
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.248002] [<8004be08>] 0x8004be08
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.254933] [<80006f78>] 0x80006f78
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.261870]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.265166] —[ end trace 9a8b15fbb768cb19 ]— Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: STA 6c:ad:f8:f1:5a:4b IEEE 802.11: did not acknowledge authentication response
Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: STA 6c:ad:f8:f1:5a:4b IEEE 802.11: did not acknowledge authentication response

23.09.20203358PackagesBug ReportVery LowHighiwinfo.scan ubus call failed with latest uhttpdTrunkUnconfirmed Task Description

With latest uhttpd package (2020-09-18), the wireless scan failed in our MT7688 devices (ramps mt76x8). The original uhttpd (2020-08-05-212f8364) version works before.

The iwinfo.scan is using the nobatch=true flag when calling rpc.declare (luci/modules/luci-base/htdocs/luci-static/resources/network.js:83)

09.10.20203373Base systemBug ReportVery LowHighIPV6 flow offload brokenTrunkUnconfirmed Task Description

Enabling this option makes the ipv6 connection unstable.

Example: connecting to #openwrt-devel from hexchat (Ubuntu) makes you constantly disconnect.
Disabling flow offload makes the connection stable.


10.10.20203376Base systemBug ReportVery LowHighMemory leak in cfg80211/mac80211 in trunk on TP Archer ...TrunkUnconfirmed Task Description

- Device TP Archer c7 v2
- Software OpenWrt SNAPSHOT r14651+16-23c7fb7600
- How to reproduce: Just wait a few hours (Usually just 6 hours)
- I tried both ath10k drivers (ath10k and ath10k-ct) with the same result

After compiling the current trunk for TP Archer c7 v2 there seems to be a memory leak in the kernel.
The memory usage is creeping up over a few hours until it triggers an OOM and a reboot.
There is no user space process consuming the memory and an analysis with kmemleak showed always the following entries:

unreferenced object 0x84639900 (size 176):
  comm "hostapd", pid 1622, jiffies 5733 (age 112.956s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 85 5f f0 00 00 00 00 00  ........._......
    00 00 00 00 00 00 00 00 40 22 00 1b 00 07 00 00  ........@"......
  backtrace:
    [<c100ebc5>] kmem_cache_alloc+0xf4/0x23c
    [<bba668db>] __build_skb+0x34/0xd0
    [<968af6d0>] __netdev_alloc_skb+0xf8/0x1ac
    [<3bb1be69>] ieee80211_mgmt_tx+0x120/0x5a0 [mac80211]
    [<bb1a7ed1>] nl80211_parse_chandef+0x1bb8/0x2be8 [cfg80211]

gdb resolved this to

ieee80211_mgmt_tx (backports-5.8-1/net/mac80211/offchannel.c:890).
885			ret = -EBUSY;
886			goto out_unlock;
887		}
888	
889		skb = dev_alloc_skb(local->hw.extra_tx_headroom + params->len);
890		if (!skb) {
891			ret = -ENOMEM;
892			goto out_unlock;
893		}
894		skb_reserve(skb, local->hw.extra_tx_headroom);
nl80211_tx_mgmt (backports-5.8-1/net/wireless/nl80211.c:10990).
10985			}
10986		}
10987	
10988		params.chan = chandef.chan;
10989		err = cfg80211_mlme_mgmt_tx(rdev, wdev, &params, &cookie);
10990		if (err)
10991			goto free_msg;
10992	
10993		if (msg) {
10994			if (nla_put_u64_64bit(msg, NL80211_ATTR_COOKIE, cookie,

As far as I understood this belongs to the remain_on_channel functionality
But unfortunately I was unable to spot why the skb is not released

12.10.20203382KernelBug ReportVery LowHighKernel doesn't find the 5GHz interface on MikroTik RB96...openwrt-19.07Unconfirmed Task Description

Booting openwrt-19.07.4-ar71xx-mikrotik-rb-nor-flash-16M-ac-initramfs-kernel.bin via tftp. Relevant dmesg chunk at driver load demonstrating that only 2.4GHz interface is detected:

Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257636] ath: EEPROM regdomain: 0×0 Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257643] ath: EEPROM indicates default country code should be used
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257646] ath: doing EEPROM country→regdmn map search
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257659] ath: country maps to regdmn code: 0x3a
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257663] ath: Country alpha2 being used: US
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257666] ath: Regpair used: 0x3a
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.274863] ieee80211 phy0: Selected rate control algorithm ‘minstrel_ht’ Tue Sep 8 07:29:00 2020 kern.info kernel: [ 10.276460] ieee80211 phy0: Atheros AR9550 Rev:0 mem=0xb8100000, irq=47

14.10.20203386KernelBug ReportVery LowHighRegression: Broadcom Roboswitch B53TrunkUnconfirmed Task Description

Hi,

in the current trunk version, Broadcom Roboswitch will not work for certain router models. However, in the past it did work.

Building OpenWrt from scratch results in a working switch with v17.01.5 (from 15 Jul 2018 21:25:16) for target profile “Broadcom SOC, BCM43xx Wifi (brcmsmac)”. Building OpenWrt from scratch for v18.06.0 (from 30 Jul 2018 18:44:34) results in the switch not working for the same target. So the problematic commit must have been between 15 Jul 2018 and 30 Jul 2018, and the problem is still present today.


For v17.01.5
# dmesg | grep switch
[ 3.596260] bgmac_bcma bcma0:2: Support for Roboswitch not implemented
[ 3.683106] b53_common: found switch: BCM5325, rev 4

Despite the message “Roboswitch not implemented” the switch comes up automatically and I can ping other computers connected through the switch.

# swconfig dev switch0 show
Global attributes:

      enable_vlan: 1
      ports: 0x003f

Port 0:

      pvid: 2
      link: port:0 link:down

Port 1:

      pvid: 1
      link: port:1 link:down

Port 2:

      pvid: 1
      link: port:2 link:down

Port 3:

      pvid: 1
      link: port:3 link:up speed:100baseT full-duplex auto

Port 4:

      pvid: 1
      link: port:4 link:down

Port 5:

      pvid: 0
      link: port:5 link:up speed:100baseT full-duplex

VLAN 1:

      ports: 1 2 3 4 5t

VLAN 2:

      ports: 0 5t

For v18.06.0
# dmesg | grep switch
[ 4.174603] bgmac_bcma bcma0:2: Support for Roboswitch not implemented
[ 4.275337] b53_common: unsupported switch detected (BCM5304/BCM4)
[ 4.281640] Broadcom B53 (2) bcma_mdio-0-0:1e: failed to register switch: -22

The switch does not come up and thus I cannot ping.


I tested this for the (unsuported) router Huawei B593u-12. You can find details about the router, logs, etc. under https://openwrt.org/toh/huawei/b593u-12

This also seems to address other routers, e.g. ZTE H218N, see https://forum.openwrt.org/t/b53-failed-to-detect-switch-on-bcm5358/20011

20.10.20203395KernelBug ReportVery LowHighbrcm47xxopenwrt-18.06Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on:

wgt634u - restart after multithreaded load wan ↔ lan eg = example speedtest, iperf

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

openwrt-19.07 openwrt-18.06

- Steps to reproduce

multithreaded load wan ↔ lan eg = example speedtest, iperf

 


16.08.201694Base systemBug ReportVery LowMediumnetifd: PPPoE MTU problemTrunkNew Task Description

When you set the MTU of a ppp interface with proto=pppoe and ifname=nas0 via the mtu option,
the configured mtu will not be set on the ppp interface (what you want), but on the
underlying interface named by ifname (what you normally don’t want to change).

This leeds to log messages like this:


pppd[5641]: Interface nas0 has MTU of 1448 – should be at least 1500.


and MTUs other than what you really want.

example:


desired PPPoE MTU: 1448
actual nas0 MTU: 1448
actual PPPoE MTU: 1440

This issue seems to be related to the commit 7ac29b75319fd69a8a7c0aeea7804d381ec07d3d of netifd.

Regards,
Martin

24.08.2016115Base systemBug ReportVery LowMediumWWAN-connections using 3g with HUAWEI ME909u-521 unstab...TrunkUnconfirmed Task Description

Actually, I am trying to stabilize wwan (3g actually; LTE later on) using pppd with my HUAWEI ME909u-521,
because either my MT7620-based router locks up during boot already; or after short period of real usage.
During night, when router is almost idle, just some watchdog date sent via wwan, no problem.

First trace of a possible problem was this msg in logread:
daemon.notice netifd: wwan (1676): Error setting WWAN mode!

Wich is expected, as in /lib/netifd/proto/3g.sh:

...

                      elif echo "$cardinfo" | grep -qi huawei; then
                              case "$service" in
                                      umts_only) CODE="14,2";;
                                      gprs_only) CODE="13,1";;
                                      *) CODE="2,2";;
                              esac
                              export MODE="AT^SYSCFG=${CODE},3FFFFFFF,2,4"    #####Will not work !!!!! Switching USB-Stick to 3g-preferred ?

...
...

                      [ -n "$MODE" ] && gcom -d "$device" -s /etc/gcom/setmode.gcom

Will not work, because the ME909u-521 rejects AT^SYSCFG . However, AT^SYSCFGEX will work, but having different syntax.
MODE=”AT^SYSCFG=${CODE},3FFFFFFF,2,4” will be effective for simpler modems.

/etc/gcom/setmode.gcom returns exit 1; but this error is not checked in 3g.sh

Not shure, whether this is the reason for my problems; however, reason of concern, as high speed modems
are more and more common.
Willing to participate in testing/debugging.

For details regarding my modem, consult
HUAWEI ME909u-521 LTE LGA Module AT Command Interface Specification
http://www.paoli.cz/out/media/HUAWEI_ME909u-521_LTE_LGA_Module_AT_Command_Interface_Specification-V100R001_02.pdf

30.08.2016126KernelBug ReportVery LowMediumkernel panic on brcm47xx (netgear wgt634u) when routing...TrunkUnconfirmed Task Description

With LEDE version reboot-1444-g1bb914d, when pulling data through the WAN interface to the LAN interface at a sufficiently high speed, e.g. on a Raspberry Pi connected by ethernet to a LAN port, and the WAN interface connected to a gigabit internet service and issuing a command like:

curl https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.7.2.tar.xz > /dev/null

From the pi, I see something like:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  9 86.2M    9 7977k    0     0  1834k      0  0:00:48  0:00:04  0:00:44 1835k[  352.295252] smsc95xx 1-1.1:1.0 eth0: link down
  9 86.2M    9 7977k    0     0  1255k      0  0:01:10  0:00:06  0:01:04 1155k[  353.959380] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
  9 86.2M    9 7977k    0     0  43292      0  0:34:48  0:03:08  0:31:40     0

or

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  8 86.2M    8 7440k    0     0  1478k      0  0:00:59  0:00:05  0:00:54 1478k[ 1100.164849] smsc95xx 1-1.1:1.0 eth0: link down
  8 86.2M    8 7440k    0     0  1232k      0  0:01:11  0:00:06  0:01:05 1300k[ 1101.836954] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
  8 86.2M    8 7440k    0     0   740k      0  0:01:59  0:00:10  0:01:49     0

Where the “link down” is the WGT634U panic’ing and rebooting. The panic on the WGT634U looks like this:

[  171.966841] CPU 0 Unable to handle kernel paging request at virtual address 008224d8, epc == 80077ecc, ra == 801d8100
[  171.977700] Oops[#1]:
[  171.980093] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.20 #0
[  171.986265] task: 8181e008 ti: 8182a000 task.ti: 8182a000
[  171.991711] $ 0   : 00000000 1000b800 008224d8 b41c479b
[  171.997140] $ 4   : 008224d8 00010000 80361ef8 00000000
[  172.002557] $ 8   : 81018b14 8101da14 00100100 dceb27b8
[  172.007983] $12   : ffffffff 00000001 ffffff80 000042c6
[  172.013400] $16   : b41c479b 00000001 81b450a8 81b7d260
[  172.018817] $20   : 803b5dcc 00000002 00000008 0000000a
[  172.024235] $24   : 00000000 80072b24                  
[  172.029653] $28   : 8182a000 8182bdb8 00000100 801d8100
[  172.035083] Hi    : 00000000
[  172.038026] Lo    : 0000006c
[  172.041036] epc   : 80077ecc put_compound_page+0x78/0x240
[  172.046547] ra    : 801d8100 skb_release_data+0xa8/0x10c
[  172.051920] Status: 1000b803 KERNEL EXL IE 
[  172.056254] Cause : 00800008
[  172.059194] BadVA : 008224d8
[  172.062144] PrId  : 00029007 (Broadcom BMIPS3300)
[  172.066891] Modules linked in: pppoe ppp_async iptable_nat ath5k ath pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables leds_gpio ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common ssb_hcd
[  172.132913] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, task=8181e008, tls=00000000)
[  172.141213] Stack : 1000b803 00000000 0000006c b41c479b 81b45080 801d8100 00000000 0000012c
          00000001 801e7d60 81becb60 81b7d260 81b7d260 80335b3c 81bece60 801d818c
          80360000 803623e0 81becb60 80335b3c 803623e0 801e63d8 8182be10 8182be10
          00000001 00000002 803b5dd0 00000001 803b5dd4 00000003 803b0000 80024fec
          81841048 80361100 819bb770 80007664 80364510 8181e008 80362898 04208040
          ...
[  172.178058] Call Trace:
[  172.180640] [<80077ecc>] put_compound_page+0x78/0x240
[  172.185822] [<801d8100>] skb_release_data+0xa8/0x10c
[  172.190895] [<801d818c>] __kfree_skb+0x28/0xb4
[  172.195466] [<801e63d8>] net_tx_action+0xd8/0x140
[  172.200329] [<80024fec>] __do_softirq+0x184/0x2b0
[  172.205184] [<80025140>] run_ksoftirqd+0x28/0x80
[  172.209953] [<8003bae0>] smpboot_thread_fn+0x148/0x178
[  172.215246] [<80039390>] kthread+0xdc/0xe8
[  172.219459] [<800010a8>] ret_from_kernel_thread+0x14/0x1c
[  172.224921] 
[  172.226470] 
Code: 30840001  0204100a  00402021 <8c420000> 000211c2  30420001  10400018  00000000  8e020000 
[  172.237022] ---[ end trace 89a3318b662df6d8 ]---
[  172.250536] Kernel panic - not syncing: Fatal exception in interrupt
[  172.262338] Rebooting in 3 seconds..

or

[ 1317.958261] Unhandled kernel unaligned access[#1]:
[ 1317.963173] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.20 #0
[ 1317.969349] task: 8181e008 ti: 8182a000 task.ti: 8182a000
[ 1317.974795] $ 0   : 00000000 1000b801 00000001 00200000
[ 1317.980232] $ 4   : 647b394a 00010000 00018da4 00000000
[ 1317.985658] $ 8   : 8181e040 b1e1b104 00000017 40000000
[ 1317.991085] $12   : 500018dd 00000000 00000000 010102f2
[ 1317.996510] $16   : 80e4d1e0 00000001 80e4d208 81acb0e0
[ 1318.001936] $20   : 803b5dcc 00000002 00000008 0000000a
[ 1318.007362] $24   : 00000010 8001ead0                  
[ 1318.012789] $28   : 8182a000 8182bdd0 00000100 801d8100
[ 1318.018220] Hi    : 00000001
[ 1318.021160] Lo    : 00000001
[ 1318.024169] epc   : 80078474 put_page+0x0/0x4c
[ 1318.028732] ra    : 801d8100 skb_release_data+0xa8/0x10c
[ 1318.034104] Status: 1000b803 KERNEL EXL IE 
[ 1318.038439] Cause : 00800010
[ 1318.041380] BadVA : 647b394a
[ 1318.044330] PrId  : 00029007 (Broadcom BMIPS3300)
[ 1318.049076] Modules linked in: pppoe ppp_async iptable_nat ath5k ath pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables leds_gpio ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common ssb_hcd
[ 1318.115124] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, task=8181e008, tls=00000000)
[ 1318.123424] Stack : 00000000 80c60c94 00db35c0 626a006e ff330000 81acb0e0 81acb0e0 80335b3c
          80c28260 801d818c 80360000 8004f368 00000018 0000000a 803623e0 801e63d8
          8182be10 8182be10 80361100 00000002 803b5dd0 00000001 803b5dd4 00000013
          803b0000 80024fec 80364510 80361100 80360000 8000736c 80364510 8181e008
          80362898 04208040 00018da4 80360000 80310000 803b5dcc 803615a0 803114f4
          ...
[ 1318.160295] Call Trace:
[ 1318.162885] [<80078474>] put_page+0x0/0x4c
[ 1318.167108] [<801d8100>] skb_release_data+0xa8/0x10c
[ 1318.172182] [<801d818c>] __kfree_skb+0x28/0xb4
[ 1318.176752] [<801e63d8>] net_tx_action+0xd8/0x140
[ 1318.181614] [<80024fec>] __do_softirq+0x184/0x2b0
[ 1318.186471] [<80025140>] run_ksoftirqd+0x28/0x80
[ 1318.191238] [<8003bae0>] smpboot_thread_fn+0x148/0x178
[ 1318.196530] [<80039390>] kthread+0xdc/0xe8
[ 1318.200744] [<800010a8>] ret_from_kernel_thread+0x14/0x1c
[ 1318.206200] 
[ 1318.207747] 
Code: 00003021  0801e0ce  24a57888 <8c820000> 3042c000  10400003  00801821  0801df95  00000000 
[ 1318.218397] ---[ end trace 2502a626803fb4b9 ]---
[ 1318.231740] Kernel panic - not syncing: Fatal exception in interrupt
[ 1318.243362] Rebooting in 3 seconds..

This looks similar to: https://dev.openwrt.org/ticket/11091

17.09.2016181Base systemBug ReportVery LowMediumChanging TX power doesn't nothing (MediaTek MT7628AN ve...TrunkUnconfirmed Task Description

Hello,

As I said, if I change the TX power from 0 dBm to 20 dBm doesn’t nothing. There isn’t any visible change in tx power. I tested other powers too (5, 8, 15,..).

It is a Xiaomi Nano (lite).

SoC Type: MediaTek MT7628AN ver:1 eco:2
MIPS: machine is MiWiFi Nano
Linux version 4.4.19 (-) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1444) ) #0 Fri Aug 26 15:03:40 2016.

24.01.2017427Base systemBug ReportVery LowMediumSwitch broken with WRT3200ACM (removes wifi adapters an...TrunkUnconfirmed Task Description

- Device problem occurs on:

WRT3200ACM

- Software versions of LEDE release, packages, etc.:

master tree (and v17.01), bisected to f24ffb901e0408917748773b883841eca52eea05.

- Steps to reproduce

* Flash a recent LEDE snapshot on the WRT3200ACM (and factory reset),
* enable wifi (2 or 5 Gz) → Wifi works
* disable wifi → errors in the dmesg about not being able to set a feature (can’t remember the exact error)
* re-enable wifi → errors in the dmesg saying that the adapter does not exist. This gets shouted in the dmesg every 5 seconds

A reboot doesn’t fix the issue. I need to downgrade the firmware prior to f24ffb901e0408917748773b883841eca52eea05 and factory reset to get the wifi adapters back.

For the Vlan bridge, symptoms are easier to detect:
* create a new adapter bridged on eth0.100 eth1.100
* no traffic goes through it. An snapshot before f24ffb901 used to work
(the setup is the Free french provider which has a vlan between the modem and the TV adapter over VLAN 100. So the LEDE box should act like a pass-through here only)

I bisected to the commit mentioned above (which, to me seems suspicious given that the driver is for mvsw61xx and the switch in the WRT3200ACM is MV88E6352, so a different generation). I don’t have enough knowledge of the chip to understand why this fails, but I don’t feel confident enough to simply send a PR with the revert.

Reverting f24ffb901e on top of master makes the Wifi and VLAN back to normal.


04.02.2017461Base systemBug ReportVery LowMediumMass Cascade of DHCP ULA Prefix Assignments with DHCP-P...AllUnconfirmed Task Description

Here is one that gets a bit ugly. Lets say we chain a bunch of LEDE based routers together. Lets also enable a nice numbering system in IP4 and IP6. Lets enable DHCP-PD through the network, because our ISP was generous with a /56. The IP4 is only static and is easy to control, see table below. Its tedious, but easy. The problem is in parallel the IP6 addresses compound in the ULA region. Each router DHCP-PD the ULA above it, and gets its own ULA from Global settings in Network UCI. There seems no easy way to control this mass cascade of ULA, and get good fail over.

Ideal Requirements:
(1) If router above is unavailable, then next tier router uses ULA (network global UCI) to begin assigning addresses to clients and subnets.
(2) If router above is available, then next tier router expires its self-generated ULA and subnets, and gets ULA from delegation above to then re-delegate to subnets.
(*) Bonus: make some parts optional

IP4 WAN Name Serves Subnet
(NAT) Router-1 172.16.0.1/24
172.16.0.2 Router-2A 172.17.0.1/24
172.17.0.2 Router-3A 172.24.0.1/24
172.17.0.3 Router-3B 172.25.0.1/24
172.16.0.3 Router-2B 172.18.0.1/24

IP6 Roots Name Serves Subnet Delegates Subnet
2001:db8/56 Router-1 2001:db8::1/64 2001:db8:0:10/60
fd00:ac10/48 fd00:ac10::1/64 2001:db8:0:20/60

                                                fd00:ac10:0:10/60
                                                fd00:ac10:0:20/60

2001:db8:0:10/60 Router-2A 2001:db8:0:10::1/64 2001:db8:0:14/62
fd00:ac10:0:10/60 fd00:ac10:0:10::1/64 2001:db8:0:18/62
fd00:ac11/48 fd00:ac11::1/64 fd00:ac10:0:14/62

                                                fd00:ac10:0:18/62
                                                fd00:ac11:0:14/62
                                                fd00:ac11:0:18/62

* please, i don’t want to type more. see how the ULA prefixes just keep multiplying.
** ‘172.16’ = ‘ac10’

06.02.2017472Base systemBug ReportVery LowMedium6to4 support with 1:1 natTrunkWaiting on reporter Task Description

One-to-one NAT means you have LAN address on interface and its mapped 1:1 to external ip addresses.
You can have incoming connections.

In such configuration “ipaddr” must be specified in 6to4 protocol section.
But due to bug this addr is submitted as local address for tunnel creation.
It does not work.

I fixed this with the following patch to /lib/netifd/proto/6to4.sh

48,53c48,53
< [ -z “$ipaddr” ] && {
< if ! network_get_ipaddr ipaddr “$wanif”; then
< proto_notify_error “$cfg” “NO_WAN_ADDRESS” < return
< fi
< }

if ! network_get_ipaddr ipladdr “$wanif”; then
> proto_notify_error “$cfg” “NO_WAN_ADDRESS”
return
> fi
>
> [ -z “$ipaddr” ] && ipaddr=$ipladdr
76c76
< json_add_string local “$ipaddr”

json_add_string local “$ipladdr”

I suggest you integrate this patch or do something similar yourself.

09.02.2017488Base systemBug ReportVery LowMediumdynamic VLAN doesn't work on ath10kopenwrt-19.07Unconfirmed Task Description

Dynamic vlan config on ath10k seems not to work. Same config on ath9k works fine.

Config:

config wifi-device  radio0
        option type     mac80211
        option channel  36
        option hwmode   11a
        option path     'pci0000:01/0000:01:00.0'
        option htmode   VHT80
[...]

config wifi-iface
        option device   radio0
        option network  vlan1
        option mode     ap
[...]
        option dynamic_vlan     '1'
        option 'vlan_tagged_interface' 'eth1'
        option 'vlan_bridge' 'br-vlan'
        option 'vlan_naming' '0'

Log:

Thu Feb  9 15:54:37 2017 daemon.err hostapd: WPA initialization for VLAN 1 failed (-1)
Thu Feb  9 15:54:37 2017 daemon.err hostapd: WPA deinit of wlan0.1 failed
Thu Feb  9 15:54:37 2017 daemon.debug hostapd: wlan0: STA ac:22:0b:a1:c7:6b IEEE 802.11: could not add dynamic VLAN interface for vlan=1
13.02.2017506Base systemBug ReportVery LowMediumBT Home Hub 5: 5g WiFi jumps to channel 36 and stops wo...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on BT Home Hub 5
- Software versions of LEDE release, packages, r3425-f28eef4 and previous versions
- Steps to reproduce

It can be after a few hours, if WiFi 5g radio0 Qualcomm Atheros QCA9880 802.11nac (radio0) is configured to a Band B channel, it jumps to Channel 36 even though there is no apparent interference.
This appears to happen more frequently overnight during long periods of inactivity. Whilst the device is being used it does not happen.

After it does make the jump, if I stop and restart the device (using luci disable/enable) the device stops, but it fails to restart. Attempts to change the channel and re-enable the device also do not help.

It requires a reboot to restore service.

 


05.03.2017599Base systemBug ReportVery LowMediumHame MPR-A2 switch has unknown topologyTrunkUnconfirmed Task Description

Vlan don’t work.


10.03.2017614Base systemBug ReportVery LowMedium/usr/lib/lua/luci/util.lua:623: Unable to establish ubu...TrunkUnconfirmed Task Description

when save&apply on system>mount luci always crash
error message:
/usr/lib/lua/luci/util.lua:623: Unable to establish ubus connection
stack traceback:

[C]: in function 'assert'
/usr/lib/lua/luci/util.lua:623: in function 'ubus'
/usr/lib/lua/luci/dispatcher.lua:347: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:141: in function </usr/lib/lua/luci/dispatcher.lua:140>
 


17.03.2017634Base systemBug ReportMediumMediumFactory flashing fails because LEDE filename is too lon...AllNew Task Description

On a TP-Link TL-WR841N v11, flashing LEDE from the web interface of the stock firmware is not possible.

This is caused by a stupid check that refuses filename longer than 64 chars in the web interface. The check is implemented in javascript and returns a cryptic error message like “Please select a file to upload”, as if no file was selected.

The current naming scheme is quite long:

$ echo ‘lede-17.01.0-r3205-59508e3-ar71xx-generic-tl-wr841-v11-squashfs-factory-eu.bin’ | wc -c
79

Shortening the name like the following would decrease the length below 64 chars, and leave some space for a custom suffix (e.g. using EXTRA_IMAGE_NAME in the Imagebuilder):

$ echo ‘lede-17.01.0-ar71xx-tlwr841v11-squashfs-factory-eu.bin’ | wc -c
55

Showing tasks 201 - 250 of 1125 Page 5 of 23<<First - 3 - 4 - 5 - 6 - 7 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing