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 TypePrioritySeveritySummaryReported InStatus
12.01.20202730KernelBug ReportVery LowHighTL-WR841N v8 ath79 Link Unstableopenwrt-19.07New Task Description

Probably related to https://bugs.openwrt.org/index.php?do=details&task_id=2216 which was reported almost a year ago. The bug is still not fixed though.

Are there any plans to fix it or will 18.06 be the last stable version for this and probably other devices?

[8451.981464] eth1: link up (100Mbps/Full duplex)
[37071.909045] eth1: link down
[37072.988861] eth1: link up (100Mbps/Full duplex)
[48492.291332] eth1: link up (10Mbps/Half duplex)
[48632.691559] eth1: link up (100Mbps/Full duplex)
[55697.449886] eth1: link down
[55698.491082] eth1: link up (100Mbps/Full duplex)
[62395.095374] eth1: link up (10Mbps/Half duplex)
[62507.411488] eth1: link up (100Mbps/Full duplex)
[62726.853998] eth1: link up (10Mbps/Half duplex)
[62732.053093] eth1: link up (100Mbps/Full duplex)
[71071.460663] eth1: link down
[71072.618285] eth1: link up (100Mbps/Full duplex)
[73435.556373] eth1: link down
[73436.597169] eth1: link up (100Mbps/Full duplex)
[73547.879987] eth1: link up (10Mbps/Half duplex)
[73558.277169] eth1: link up (100Mbps/Full duplex)
[74438.121970] eth1: link down
[74439.162824] eth1: link up (100Mbps/Full duplex)
[75341.889076] eth1: link up (10Mbps/Half duplex)
[75352.290230] eth1: link up (100Mbps/Full duplex)
[76274.772404] eth1: link down
[76275.813134] eth1: link up (100Mbps/Full duplex)

12.01.20202729Base systemBuild FailureVery LowLowError building profile iom_ix2_200TrunkUnconfirmed Task Description

Error building profile iom_ix2_200

imagebuilder iom_ix2_200

I’m trying to build image for Iomega StorCenter ix2-200 using the last snapshot (https://downloads.openwrt.org/snapshots/targets/kirkwood/generic/openwrt-imagebuilder-kirkwood.Linux-x86_64.tar.xz, today 2020-01-12) using the command:

make image PROFILE=iom_ix2_200

I got the error:

Collected errors:
 * opkg_install_cmd: Cannot install package kmod-i2c-mv64xxx.
make[2]: *** [Makefile:157: package_install] Error 255
make[1]: *** [Makefile:118: _call_image] Error 2
make: *** [Makefile:197: image] Error 2

The package kmod-i2c-mv64xxx is missing...
I removed the package from .targetinfo:

Target-Profile: DEVICE_iom_ix2_200
Target-Profile-Name: Iomega StorCenter ix2-200
Target-Profile-Packages:  kmod-gpio-button-hotplug kmod-i2c-mv64xxx kmod-hwmon-lm63
Target-Profile-hasImageMetadata: 1
Target-Profile-SupportedDevices: iom,ix2,200

Target-Profile-Description:
Build firmware images for Iomega StorCenter ix2-200

thus:

Target-Profile-Packages:  kmod-gpio-button-hotplug kmod-hwmon-lm63

all ok, but sysupgrade fail image check:

Device iom,ix2-200 not supported by this image
Supported devices: iom,ix2,200
Image check failed.

to install image i need to force it:

sysupgrade -F /tmp/openwrt-kirkwood-iom_ix2_200-squashfs-sysupgrade.bin

output:

Device iom,ix2-200 not supported by this image
Supported devices: iom,ix2,200
Image check failed but --force given - will update anyway!
Saving config files...
Commencing upgrade. Closing all shell sessions.
Connection to storage.lan closed by remote host.
Connection to storage.lan closed.

al last, I have an extroot configuration and after a sysupgrade I have always a bad .extroot-uuid, but this is another story...

11.01.20202725Base systemBug ReportVery LowMediumopkg remove does not remove empty foldersAllUnconfirmed Task Description

Tested: Turris Omnia, mvebu, OpenWrt {18.06,19.07,master}

When you install python3-simplejson on router, it will install following files:

tree /usr/lib/python3.7/site-packages/simplejson*
/usr/lib/python3.7/site-packages/simplejson
├── __init__.pyc
├── _speedups.cpython-37.so
├── compat.pyc
├── decoder.pyc
├── encoder.pyc
├── errors.pyc
├── ordered_dict.pyc
├── raw_json.pyc
├── scanner.pyc
└── tool.pyc
/usr/lib/python3.7/site-packages/simplejson-3.16.0-py3.7.egg-info
├── PKG-INFO
├── SOURCES.txt
├── dependency_links.txt
└── top_level.txt

When you do opkg-remove python3-simplejson, it will not remove folder egg-info, but contents of that folder, it does.

When the folder is present, Python3 detects is as installed.

root@turris:~# python3
Python 3.7.4 (default, Oct 01 2019, 23:50:45) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import simplejson
>>> simplejson.loads('{}')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'simplejson' has no attribute 'loads'
>>> 

When you remove the folders manually, which were not removed by opkg then the import of simplejson does not work as it should.

root@turris:~# python3
Python 3.7.4 (default, Oct 01 2019, 23:50:45) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import simplejson
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'simplejson'

Explained here: https://github.com/openwrt/packages/issues/10136

11.01.20202724Base systemBug ReportVery LowLowBusybox ping does not handle -I <interface name> correc...TrunkUnconfirmed Task Description

Device: Netgear R7800
Version: OpenWrt SNAPSHOT r11954-7936cb94a9 / LuCI Master git-20.009.37523-c8909a6

This has been going on for quite a while; however, I was able to get around it by using iputils-ping which apparently doesn’t exist anymore.

The Busybox version of ping does not handle the -I switch correctly in a multi-wan setup. See below:

Interface configuration information (WAN links):

eth1.100  Link encap:Ethernet  HWaddr 38:94:ED:B8:EA:64
          inet addr:<AT&T Static IP>  Bcast:<AT&T Static broadcast IP>  Mask:255.255.255.248
          inet6 addr: <redacted> Scope:Global
          inet6 addr: <redacted> Scope:Global
          inet6 addr: <redacted> Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4168 errors:0 dropped:972 overruns:0 frame:0
          TX packets:1687 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:403572 (394.1 KiB)  TX bytes:118858 (116.0 KiB)

eth1.99   Link encap:Ethernet  HWaddr 38:94:ED:B8:EA:63
          inet addr:<Comcast DHCP IP>  Bcast:<Comcast Broadcast IP>  Mask:255.255.252.0
          inet6 addr: <redacted> Scope:Link
          inet6 addr: <redacted> Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:173068 errors:0 dropped:0 overruns:0 frame:0
          TX packets:181502 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:910743533 (868.5 MiB)  TX bytes:19114819 (18.2 MiB)

On the primary (WAN) interface, everything works as expected:

root@orion:~# ping -I eth1.99 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=55 time=19.096 ms
64 bytes from 8.8.8.8: seq=1 ttl=55 time=14.651 ms
64 bytes from 8.8.8.8: seq=2 ttl=55 time=14.331 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 14.331/16.026/19.096 ms
root@orion:~# ping -I <Comcast IP> 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from <Comcast IP>: 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=55 time=14.481 ms
64 bytes from 8.8.8.8: seq=1 ttl=55 time=15.447 ms
64 bytes from 8.8.8.8: seq=2 ttl=55 time=14.301 ms
64 bytes from 8.8.8.8: seq=3 ttl=55 time=20.306 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 14.301/16.133/20.306 ms

However, if I try the same on the AT&T link, I get the following:

root@orion:~# ping -I eth1.100 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss
root@orion:~# ping -I <AT&T IP addr> 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from <AT&T IP addr>: 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=55 time=13.816 ms
64 bytes from 8.8.8.8: seq=1 ttl=55 time=14.625 ms
64 bytes from 8.8.8.8: seq=2 ttl=55 time=16.299 ms
64 bytes from 8.8.8.8: seq=3 ttl=55 time=16.515 ms
64 bytes from 8.8.8.8: seq=4 ttl=55 time=14.710 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 13.816/15.193/16.515 ms
root@orion:~#

I only have this issue with the Busybox version of ping. The old iputils-ping version did not have this issue.

The interesting part is that other people seem to have the opposite issue as me, where Busybox works and iputils-ping doesn’t. Unfortunately, this breaks mwan3 for me.

10.01.20202723Base systemBug ReportVery LowHighAfter libubus/ubox: procd - failed to open/remove pidfi...openwrt-19.07Assigned Task Description

Device problem occurs on Turris Omnia (mvebu), Turris MOX (aarch64).
OpenWrt 19.07 and the latest OpenWrt master branch.

How to reproduce it?

Master:

# opkg list-installed | grep ubus
libubus - 2020-01-05-d35df8ad-1.0
libubus-lua - 2020-01-05-d35df8ad-1.0
python3-ubus - 0.1-3.8-1.7
ubus - 2020-01-05-d35df8ad-1.0
ubusd - 2020-01-05-d35df8ad-1.0

# opkg list-installed | grep libubox
libubox - 2019-12-28-cd75136b-1.0

Find any package which has in init script hard coded path for pid file

procd_set_param pidfile 

E.g. Install i2pd package and run:

/etc/init.d/i2pd start

Then stop it:

/etc/init.d/i2pd stop

And here you go, the router crashes:

[  587.264257] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[  587.264257] 
[  587.273419] CPU1: stopping
[  587.276135] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.93 #0
[  587.282153] Hardware name: Marvell Armada 380/385 (Device Tree)
[  587.288098] [<c010f2e0>] (unwind_backtrace) from [<c010b208>] (show_stack+0x10/0x14)
[  587.295862] [<c010b208>] (show_stack) from [<c085f240>] (dump_stack+0x94/0xa8)
[  587.303103] [<c085f240>] (dump_stack) from [<c010dfe4>] (handle_IPI+0xf0/0x19c)
[  587.310435] [<c010dfe4>] (handle_IPI) from [<c052e648>] (gic_handle_irq+0x8c/0x90)
[  587.318024] [<c052e648>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
[  587.325523] Exception stack(0xef09bf60 to 0xef09bfa8)
[  587.330587] bf60: 00000000 001bda5c ef6e12c4 c0114fc0 ffffe000 c0d03c6c c0d03cac 00000002
[  587.338783] bf80: 00000000 c0d03c48 c0c4d628 00000000 2ea95000 ef09bfb0 c0108644 c0108648
[  587.346977] bfa0: 60000013 ffffffff
[  587.350478] [<c0101a0c>] (__irq_svc) from [<c0108648>] (arch_cpu_idle+0x34/0x38)
[  587.357898] [<c0108648>] (arch_cpu_idle) from [<c0150950>] (do_idle+0xf4/0x1f0)
[  587.365226] [<c0150950>] (do_idle) from [<c0150ccc>] (cpu_startup_entry+0x18/0x1c)
[  587.372814] [<c0150ccc>] (cpu_startup_entry) from [<001023ec>] (0x1023ec)
[  587.380295] Rebooting in 3 seconds..

With this issue, we have been able to reproduce another issue with the package fosquitto, which is not available in OpenWrt feeds. In the init script, we commented out procd_set_param pidfile and then restart the process, we see these rows in the system log.

Jan 10 17:32:51 turris procd: Failed to removed pidfile: ������t.d/fosquitto: No such file or directory
Jan 10 17:32:51 turris procd: failed to open pidfile for writing: ������t.d/fosquitto: No such file or directory

I'm sure that this can be reproduced with other packages from packages feed as well.

This happens after the latest changes in libubox and ubus. Anyway, it was not a good idea to include the latest changes in libubox and ubus 2 days before tagging the OpenWrt 19.07. Reverting to libubox to 2019-10-29 and ubus to 2018-10-06 helps for both issues.

09.01.20202720PackagesBuild FailureVery LowHighlibcap compile failure at tests stepTrunkUnconfirmed Task Description

libcap build is failing since the update to 2.30

+ The toolchain options used are:
  - binutils 2.31.1
  - gcc 8.x
  - glibc

For reproducing one just need to run the folling

 $make package/feeds/packages/libcap/compile V=s

The flow breaks at tests stage:

make -C tests all
make[4]: Entering directory ‘/data/workspace/hbk/Perception/Embedded/OpenWrt/build_dir/target-i386_pentium4_glibc/libcap-2.30/tests’ i486-openwrt-linux-gnu-gcc -Os -pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/data/workspace/hbk/Perception/Embedded/OpenWrt/build_dir/target-i386_pentium4_glibc/libcap-2.30=libcap-2.30 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fPIC -I/data/workspace/hbk/Perception/Embedded/OpenWrt/build_dir/target-i386_pentium4_glibc/libcap-2.30/tests/../libcap/include/uapi -I/data/workspace/hbk/Perception/Embedded/OpenWrt/build_dir/target-i386_pentium4_glibc/libcap-2.30/tests/../libcap/include libcap_psx_test.c -o libcap_psx_test -L/data/workspace/hbk/Perception/Embedded/OpenWrt/build_dir/target-i386_pentium4_glibc/libcap-2.30/tests/../libcap -lcap -L/data/workspace/hbk/Perception/Embedded/OpenWrt/build_dir/target-i386_pentium4_glibc/libcap-2.30/tests/../libcap -lpsx -lpthread -Wl,-wrap,pthread_create –static
/data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofclose.o): in function `_IO_new_fclose.cold.0’:
iofclose.c:(.text.unlikely+0×34): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofclose.o):(.eh_frame+0×13): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofclose.o):(.eh_frame+0x6f): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofflush.o): in function `_IO_fflush.cold.0’:
iofflush.c:(.text.unlikely+0×34): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofflush.o):(.eh_frame+0×13): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofflush.o):(.eh_frame+0×73): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(ioputs.o): in function `_IO_puts.cold.0’:
ioputs.c:(.text.unlikely+0×34): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(ioputs.o):(.eh_frame+0×13): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(ioputs.o):(.eh_frame+0×77): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(wfileops.o): in function `_IO_wfile_underflow.cold.2’:
wfileops.c:(.text.unlikely+0×34): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(wfileops.o):(.eh_frame+0x6b): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(wfileops.o):(.eh_frame+0x12b): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(fileops.o): in function `_IO_new_file_underflow.cold.6’:
fileops.c:(.text.unlikely+0×38): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(fileops.o):(.eh_frame+0×103): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(fileops.o):(.eh_frame+0x17f): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofputs.o): in function `_IO_fputs.cold.0’:
iofputs.c:(.text.unlikely+0×34): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofputs.o):(.eh_frame+0×13): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofputs.o):(.eh_frame+0x8f): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofwrite.o): in function `_IO_fwrite.cold.0’:
iofwrite.c:(.text.unlikely+0×34): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofwrite.o):(.eh_frame+0×13): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iofwrite.o):(.eh_frame+0x7f): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iogetdelim.o): in function `_IO_getdelim.cold.0’:
iogetdelim.c:(.text.unlikely+0×35): undefined reference to `_Unwind_Resume’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iogetdelim.o):(.eh_frame+0×13): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libc.a(iogetdelim.o):(.eh_frame+0x8f): undefined reference to `gcc_personality_v0’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libpthread.a(unwind.o): in function `unwind_stop’:
unwind.c:(.text+0×47): undefined reference to `_Unwind_GetCFA’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: unwind.c:(.text+0×88): undefined reference to `_Unwind_GetCFA’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: unwind.c:(.text+0xed): undefined reference to `_Unwind_GetCFA’ /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/bin/ld: /data/workspace/hbk/Perception/Embedded/OpenWrt/staging_dir/toolchain-i386_pentium4_gcc-8.3.0_glibc/lib/gcc/i486-openwrt-linux-gnu/8.3.0/../../../../i486-openwrt-linux-gnu/lib/libpthread.a(unwind.o): in function `__pthread_unwind’:
unwind.c:(.text+0×156): undefined reference to `_Unwind_ForcedUnwind’ collect2: error: ld returned 1 exit status

09.01.20202719Base systemBug ReportVery LowHighBuffalo WBMR-HP-G300H: DSL does not connect at all with...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: Buffalo WBMR-HP-G300H
- Software versions of OpenWrt/LEDE release, packages, etc.: OpenWRT 19.07, kmod-ltq-adsl-ar9-fw-a 0.1-1, which shows up as 4.4.4.0.0.1 in dsl_control status.
- Steps to reproduce:

1. Get an ADSL line from Rostelecom.
2. Upgrade the router to OpenWRT 19.07.
3. Reboot.

Result: DSL does not connect. In /etc/init.d/dsl_control status, it goes through all phases, then briefly shows as “Up”, but then the “dsl0” interface is not created, and the following lines are logged in dmesg:

 [   56.597766] [DSL_BSP_Showtime 914]: Datarate US intl = 1024000, fast = 0
 [   56.603091] [DSL_BSP_Showtime 934]: no hookup from ATM driver to set cell rate

The error does not exist with the 4.5.4.9.1.1 firmware obtained from unofficial sources. The bug has been submitted through the affected ADSL line with the unofficial firmware.

Status:

# /etc/init.d/dsl_control status
ATU-C Vendor ID: Broadcom 161.149
ATU-C System Vendor ID: 00,00,00,00,00,00,00,00
Chipset: Ifx-AR9
Firmware Version: 4.5.4.9.1.1
API Version: 3.24.4.4
XTSE Capabilities: 0×4, 0×0, 0×0, 0×0, 0×0, 0×0, 0×0, 0×0 Annex: A
Line Mode: G.992.1 (ADSL)
Profile:
Line State: UP [0×801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 413342 / Far: 0
Errored seconds (ES): Near: 0 / Far: 0
Severely Errored Seconds (SES): Near: 0 / Far: 0
Loss of Signal Seconds (LOSS): Near: 0 / Far: 0
Unavailable Seconds (UAS): Near: 253 / Far: 253
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: / Far:
Pre-emtive CRC errors (CRCP_P): Near: / Far:
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 8.0 ms [Interleave] 8.0 ms [Interleave]
Data Rate: Down: 9.952 Mb/s / Up: 1.024 Mb/s
Line Attenuation (LATN): Down: 32.2 dB / Up: 19.5 dB
Signal Attenuation (SATN): Down: 32.6 dB / Up: 19.5 dB
Noise Margin (SNR): Down: 6.1 dB / Up: 13.0 dB
Aggregate Transmit Power (ACTATP): Down: 20.0 dB / Up: 12.3 dB
Max. Attainable Data Rate (ATTNDR): Down: 8.848 Mb/s / Up: 1.204 Mb/s
Line Uptime Seconds: 1164
Line Uptime: 19m 24s

(yes, very bad line)

Config:

config atm-bridge ‘atm’

option vpi '1'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
option vci '50'
option unit '0'
option atmdev '0'

config dsl ‘dsl’

option annex 'a'
option firmware '/lib/firmware/dsl_ar9_firmware_adsl_a-04.05.04.09.01.01.bin'

config interface ‘wan’

option ifname 'dsl0'
option proto 'pppoe'
option ipv6 '1'
option username 'censored'
list dns '8.8.8.8'
list dns '8.8.4.4'
option peerdns '0'
option keepalive '60 5'
option password 'censored'
08.01.20202718Base systemBug ReportVery LowCritical/overlay is empty and nothing can be written thereTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

Only on TPLink Archer C7 v5 (current model).
Other models are OK: A7 (”V5”) (also current), C7 V2, C7 V4 (both earlier)

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

Only Trunk has this problem, and only on C7 v5. rc19.07 does *not* have this problem.

- Steps to reproduce

make menuconfig for target C7 V5
load squashfs-factory version in a C7 V5
boot

...and presto, there’s nothing in /overlay. /rom/overlay is populated. I have found no way to write anything on /overlay. Luci can’t save anything either – not even a password.

There’s nothing weird in my make menuconfig config, unless you count python3-light, bind-dig, ca-certificates, etc. as weird. And the other C7 and C7-like models work fine.

 


08.01.20202717Base systemBug ReportVery LowMediumYouku YK-L1C (MT7620A): WLAN stops working periodicallyTrunkUnconfirmed Task Description

Device: Youku YK-L1C
PCB: MTO-WR976N V1.0
Chip: MT7620A ver:2 eco:6
CPU0 revision: 00019650 (MIPS 24KEc)
MIPS: YOUKU YK1

With several OpenWRT versions starting from 2018 (when I bought the router), WLAN periodically stops working after a week or after a month. Wired Ethernet ports remain working. WLAN restart does not help.

Kernel log suggests to file a bug report on rt2x00.serialmonkey.com but the site is not functioning.

The trail of the kernel log:

[ 34.827909] IPv6: ADDRCONF(NETDEV_UP): wlan0-1: link is not ready
[ 35.428393] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-1: link becomes ready
[ 35.458300] IPv6: ADDRCONF(NETDEV_UP): wlan0-2: link is not ready
[ 36.064758] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-2: link becomes ready
[ 36.097912] IPv6: ADDRCONF(NETDEV_UP): wlan0-3: link is not ready
[ 36.699145] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-3: link becomes ready
[ 49.518071] random: crng init done
[ 4837.370372] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 5834.538102] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 5834.556560] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[ 5834.574974] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[60224.028009] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[83621.461506] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
[83993.491441] mtk_soc_eth 10100000.ethernet eth0: port 1 link up (100Mbps/Full duplex)
[84062.284581] device wlan0 left promiscuous mode
[84062.293643] br-lan: port 2(wlan0) entered disabled state
[84062.621840] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
[84063.227188] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
[84067.508458] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[84067.575677] br-lan: port 2(wlan0) entered blocking state
[84067.586360] br-lan: port 2(wlan0) entered disabled state
[84067.597335] device wlan0 entered promiscuous mode
[84074.967563] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[84074.980512] br-lan: port 2(wlan0) entered blocking state
[84074.991139] br-lan: port 2(wlan0) entered forwarding state
[84075.018713] IPv6: ADDRCONF(NETDEV_UP): wlan0-1: link is not ready
[84076.101273] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-1: link becomes ready
[84076.128677] IPv6: ADDRCONF(NETDEV_UP): wlan0-2: link is not ready
[84077.809446] IPv6: ADDRCONF(NETDEV_UP): wlan0-3: link is not ready
[84078.043454] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-2: link becomes ready
[84079.829418] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-3: link becomes ready
[84079.869727] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2
[84079.869727] Please file bug report to http://rt2x00.serialmonkey.com

07.01.20202716Base systemBug ReportVery LowMediumAfter 1 day WiFi clients connected to 2.4 and 5 GHZ ban...TrunkUnconfirmed Task Description

Model: TOTOLINK A7000R
Architecture: MediaTek MT7621 ver:1 eco:3
Firmware Version: OpenWrt SNAPSHOT r11835-0590d74db2 / LuCI Master git-19.364.49900-d07cfba
Kernel Version: 4.14.160

Installed packages: luci luci-ssl luci-app-sqm luci-app-ddns ddns-scripts_no-ip_com luci-app-adblock luci-app-bcp38 luci-app-wol luci-app-statistics luci-app-wireguard luci-app-openvpn luci-app-upnp

Configured only WiFi interfaces with separate names OpenWrt and OpenWrt5, psk2 with passphrase and hidden SSID.

After 1 day OpenWrt still showing:

cat /sys/devices/virtual/net/br-lan/lower_wlan0/brport/hairpin_mode
1
cat /sys/devices/virtual/net/br-lan/lower_wlan0/brport/multicast_to_unicast
1
cat /sys/devices/virtual/net/br-lan/lower_wlan0/brport/isolated
0
cat /sys/devices/virtual/net/br-lan/lower_wlan1/brport/hairpin_mode
1
cat /sys/devices/virtual/net/br-lan/lower_wlan1/brport/multicast_to_unicast
1
cat /sys/devices/virtual/net/br-lan/lower_wlan1/brport/isolated
0

On forum found workaround to manually add

option multicast_to_unicast 0

to all affected /etc/config/wireless wifi-iface sections didn‘t helped.
So temporary added /sbin/wifi command to crontab at every night.

03.01.20202714Base systemBug ReportVery LowLowsh: acs_survey: out of rangeAllUnconfirmed Task Description

When channel is set to “0”, script enables channel=acs_survey in hostapd config. But this variable is used later and spams in log:

Fri Jan  3 20:58:36 2020 daemon.notice netifd: radio0 (3124): sh: acs_survey: out of range
Fri Jan  3 20:58:36 2020 daemon.notice netifd: radio0 (3124): sh: acs_survey: out of range
02.01.20202711Base systemBug ReportVery LowLowlogread -r gives wrong return-codeopenwrt-18.06Unconfirmed Task Description

what I am doing:

root@ffsaar-HammelsbergVa:~# logread -?
    -r    <server> <port>    Stream message to a server
root@ffsaar-HammelsbergVa:~# logread -r syslog.ffsaar 515
root@ffsaar-HammelsbergVa:~# echo $?
0
root@ffsaar-HammelsbergVa:~#

Due to the return-code “0”, I was thinking that everything went fine and my log was perfectly streamed to the server, but:

root@ffsaar-HammelsbergVa:~# logread -l 1
Wed Jan  1 21:52:47 2020 daemon.info logread[3904]: failed to send log data to syslog.ffsaar:515 via tcp
root@ffsaar-HammelsbergVa:~# 

expected behaviour: If there is some trouble sending the data, then the return-code of logread -r should be anything but “0”, right?

ENV:
OpenWrt 18.06-SNAPSHOT, r7835+25-89808e211c
gluon-ffsaar 1.8.0 / gluon v2019.1

29.12.20192709Base systemBug ReportVery LowMediumUnable to connect wifi on mvebu platform with esp8266openwrt-19.07Unconfirmed Task Description

- Device problem occurs on mvebu platform - Linksys wrt3200acm Marvell 88W8964 802.11bgn wifi while trying to connect by esp8266
- Software versions OpenWrt 19.07

esp8266 is not getting dhcp address and even when trying to communicate with static IP it is not possible to acquire connection. esp8266 is unable to get access to the router. Same problem exists in openwrt 18.06

 


28.12.20192707KernelBug ReportVery LowHighmt7621/ath9k: unreliable AP with hardware encryptionTrunkUnconfirmed Task Description

Board: MikroTik Routerboard RBM33G (ramips/mt7621)
Interface: MikroTik R11e-2HPnD (ath9k/ar9582)
Tested versions: 18.06.5, snapshot

Some background: I’ve been using RB433AH & UBNT XR2 (ath5k) as home AP for many years. It was extremely reliable with OpenWRT, LEDE and OpenWRT once again. However, the 802.11g is not sufficient nowadays, so I decided to upgrade. I’ve acquired a RBM33G board and R11e-2HPnD module, but this setup is very unreliable for me.

The bug: At some point, the AP cannot receive (decrypt?) packets from a station, but the connection is still established.

Details:

  • It can happen on any active station connected to AP, but only one stalls at a given time (not all of them).
  • AP actually receives data from STA, as the RX byte counter increases, but the RX packet count is typically stuck at the same value. For example, several subsequent calls to `iw wlan0 station dump` show: rx bytes: 12121338 / 12127266 / 12141740, rx packets: 1282 / 1282 / 1282.
  • Driver discards the packets, as the replay counter greatly increases when this bug occurs. (e.g. /sys/kernel/debug/ieee80211/phy0/keys/3/replays: 484947)
  • There is nothing relevant in `dmesg` or `logread`.

Reproducibility:

  • It happens after several hours of a typical traffic.
  • I can trigger it manually much faster by passing high data throughput between clients (e.g. using iperf).

Configuration:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'NOHT'
        option txpower '16'
        option disabled '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid '<SSID>'
        option encryption 'psk2+ccmp'
        option key '<KEY>'

Stations tested:

  • Dell Latitude E7440 with Intel Wireless 7260 (iwlwifi), running linux 5.4.6
  • Dell Latitude E7270 with Intel Wireless 8260 (iwlwifi), running linux 4.19.91
  • RB411U with DBII F20-PRO (ath5k, AR5414), running LEDE 17.01.4 (in WDS link)


What does NOT help:

  • Changing the basic configuration (SSID, key).
  • Disabling 802.11n.
  • Disabling WDS (both AP & STA).
  • Disabling SMP (nosmp kernel cmdline option).
  • Using another version of hostapd, i.e. wpad-mesh.
  • Changing miniPCIe slot on the RBM33G board.
  • Disabling CPU powersave in MikroTik bootloader.

Workarounds:

  • Disable the encryption at all, but that’s obviously not an option.
  • Disable hardware encryption with ath9k’s nohwcrypt=1 parameter.

This bug does not occur with software encryption, at least in 802.11g mode. In 802.11n mode, the throughput is limited to a little over 30 Mbps and there are frequent disconnects. Apparently, the CPU is not the limiting factor, as `top` reports usage of approximately 10%.

Unfortunately, this bug renders the AP unusable for me, because I need the best reliability.

I also tested this setup with different board and (so far) I cannot reproduce this bug on RW2458N (ar71xx) & R11e-2HPnD with OpenWRT 18.06.5.

28.12.20192702KernelBug ReportVery LowMediumPerformance degradation after kernel.warn ath10k_core@8...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:

- Device problem occurs on
Archer C7v2

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

[---] PACKAGES INSTALLED
echo [INFO] Downloading package information ...
opkg update
#
echo [INFO] Removing packages ...
opkg remove wpad-basic
#
echo [INFO] Installing packages ...
opkg install bash
opkg install block-mount
opkg install curl
opkg install e2fsprogs
opkg install htop
# opkg install igmpproxy
opkg install kmod-br-netfilter
opkg install kmod-fs-ext4
opkg install kmod-fs-msdos
opkg install kmod-fs-ntfs
opkg install kmod-scsi-core
opkg install kmod-usb-storage
opkg install libncurses
opkg install libpcre
opkg install lua luafilesystem
opkg install luci-mod-rpc
opkg install luci-proto-relay
opkg install mailsend
opkg install nano
opkg install relayd
opkg install rpcd
opkg install terminfo
opkg install tcpdump
opkg install uhttpd-mod-ubus
opkg install vsftpd
opkg install wget
opkg install wpad
#
# batman-adv
opkg install kmod-batman-adv
opkg install batctl-full
[---]

- Steps to reproduce
Today worked on batman-adv via ad-hoc between two devices. Device A has LAN to bat0, batman-adv works over ad-hoc wifi, Device B has bat0 to LAN. (Device B has only one wired client behind)
Both devices (Archer C7v2 with OpenWrt 19.07-rc.2) had multiple crashes of the below printed type resulting in only 10 MBit/s download speed on the computer attached via LAN to Device B. Before the kernel.warn log line appeared on one of the APs, the speed was full 100 MBit/s. As soon I reboot the “kernel.warn”ing AP, the speed is 100 MBit again. bat0 is bridged to eth0.101 on both ends.

 
Sat Dec 28 14:50:04 2019 daemon.notice hostapd: wlan0-1: AP-ENABLED
Sat Dec 28 14:50:05 2019 kern.info kernel: [ 2416.392454] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:05 2019 daemon.notice wpa_supplicant[16106]: Successfully initialized wpa_supplicant
Sat Dec 28 14:50:06 2019 kern.info kernel: [ 2417.755684] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:06 2019 daemon.notice wpa_supplicant[16106]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
Sat Dec 28 14:50:06 2019 daemon.notice wpa_supplicant[16176]: wlan0: Trying to associate with SSID 'Permakultur'
Sat Dec 28 14:50:06 2019 kern.info kernel: [ 2417.950938] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2417.991646] ------------[ cut here ]------------
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2417.996394] WARNING: CPU: 0 PID: 16176 at /builder/shared-workdir/build/build_dir/target-mips_24kc_musl/linux-ath79_generic/ath10k-ct-2019-09-09-5e8cd86f/ath10k-4.19/mac.c:6598 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.016231] Modules linked in: ath9k ath9k_common pppoe ppp_async batman_adv ath9k_hw 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 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 libcrc32c iptable_mangle iptable_filter ip_tables crc_ccitt compat br_netfilter ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp437
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.088204]  usb_storage sd_mod scsi_mod ext4 mbcache jbd2 crc16 crc32c_generic crypto_hash ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.103218] CPU: 0 PID: 16176 Comm: wpa_supplicant Tainted: G        W       4.14.156 #0
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.111503] Stack : 000000f8 800b2a94 80500000 804af544 00000000 00000000 00000000 00000000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.120128]         00000000 00000000 00000000 00000000 00000000 00000001 853c59d8 ebe9a33e
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.128783]         853c5a70 00000000 00000000 00009378 00000038 80447958 00000008 00000000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.137442]         000001c9 6e8dd5be 000001c8 00000000 853c59b8 80000000 00000000 8704e480
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.146036]         8700bd24 000019c6 86310d28 87428800 00000003 8027f944 00000000 80630000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.154570]         ...
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.157183] Call Trace:
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.157198] [<800b2a94>] 0x800b2a94
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.163293] [<80500000>] 0x80500000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.166873] [<80447958>] 0x80447958
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.170485] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.176813] [<8027f944>] 0x8027f944
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.180352] [<8006a56c>] 0x8006a56c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.184017] [<8006a574>] 0x8006a574
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.187559] [<80084c20>] 0x80084c20
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.191102] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.197583] [<80084d08>] 0x80084d08
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.201136] [<80318194>] 0x80318194
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.204714] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.211078] [<87795f70>] 0x87795f70 [mac80211@87780000+0x6c280]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.217204] [<8772d0d0>] 0x8772d0d0 [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.223313] [<8772941c>] 0x8772941c [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.229530] [<8771ddc0>] 0x8771ddc0 [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.235711] [<80134f00>] 0x80134f00
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.239316] [<80350498>] 0x80350498
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.243000] [<803501ac>] 0x803501ac
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.246630] [<8034eb44>] 0x8034eb44
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.250375] [<8034f410>] 0x8034f410
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.253980] [<8034c9bc>] 0x8034c9bc
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.257540] [<8034e208>] 0x8034e208
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.261197] [<8034e6e4>] 0x8034e6e4
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.264845] [<802f7c1c>] 0x802f7c1c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.268386] [<8034bcf8>] 0x8034bcf8
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.271988] [<8034e308>] 0x8034e308
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.275625] [<802f7e7c>] 0x802f7e7c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.279170] [<800ac680>] 0x800ac680
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.282723] [<802f5f34>] 0x802f5f34
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.286301] [<802f6718>] 0x802f6718
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.289840] [<8034bdec>] 0x8034bdec
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.293390] [<802f681c>] 0x802f681c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.297024] [<8013fd78>] 0x8013fd78
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.300656] [<802fd5c0>] 0x802fd5c0
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.304252] [<802f8704>] 0x802f8704
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.307808] [<802f6718>] 0x802f6718
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.311405] [<8006f72c>] 0x8006f72c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.314981] [<802f84a4>] 0x802f84a4
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.318624]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.320140] ---[ end trace b03503722668fd71 ]---
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.329016] wlan0: Selected IBSS BSSID [MAC] based on configured SSID
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-1' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-2' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-3' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is enabled
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' has link connectivity
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is setting up now
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.899578] batman_adv: bat0: Adding interface: wlan0
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.904876] batman_adv: bat0: Interface activated: wlan0
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is now up
Sat Dec 28 14:50:08 2019 daemon.notice wpa_supplicant[16176]: wlan0: Associated with [MAC]


28.12.20192700Base systemBug ReportVery LowLownettle fails to compile on ARMEBTrunkUnconfirmed Task Description

https://downloads.openwrt.org/snapshots/faillogs/armeb_xscale/base/nettle/compile.txt

This also prevents dnsmasq from being compiled.

The error is here: https://github.com/gnutls/nettle/blob/master/arm/memxor.asm#L148

Passing –disable-assembler works, but is probably not ideal.

27.12.20192698Base systemBug ReportVery LowMediumnetifd DFS-delayed wireless interfaces not correctly ha...TrunkUnconfirmed Task Description

Found on TP-Link Archer C7 v4 on master (commit db992e7b53 - 5 days ago).

When having 3 interfaces on channel requiring radar scan (DFS), only the main interface is shown - see logs, where radio0 wifi should have 3 interfaces wlan0-lan, wlan0-guest and wlan0-admin, but only wlan0-lan is shown. Due to DFS scan it comes up after a minute after `/etc/init.d/network start` is executed.

Configuration:

  • 2 wifis: 2,4GHz (radio1) + 5GHz (radio0)
  • each band has 3 SSIDs (domaci-soukroma, domaci, domaci-admin), each one’s interface assigned to one bridge - lan, guest and admin, respectively.

Called `ubus call network.wireless status`, received result:

  • wlan0-lan exists
  • wlan0-guest and wlan0-admin not recognised
  • wlan1-lan, wlan1-guest, wlan1-admin exist

Expected result:

  • wlan0-guest and wlan0-admin recognised

Configuration, logread (produced by `/sbin/netifd -d 15 -l 7`), `ubus network.device status` and `ubus network.wireless status` attached (removed IP and MAC addresses).

27.12.20192697ToolchainBug ReportVery LowLowopenwrt-imagebuilder-ar71xx-tiny: Cannot satisfy the fo...lede-17.01Unconfirmed Task Description

So I pulled the imagebuilder from here:

https://downloads.openwrt.org/snapshots/targets/ar71xx/tiny/openwrt-imagebuilder-ar71xx-tiny.Linux-x86_64.tar.xz

And tried to build with the following commandline:

make clean;make image PROFILE=tl-wr703n-v1 PACKAGES="uhttpd uhttpd-mod-ubus libiwinfo-lua luci-base luci-app-firewall luci-mod-admin-full luci-theme-bootstrap kmod-rt2800-lib kmod-rt2800-usb rt2800-usb-firmware kmod-usb-storage kmod-fs-ext4 block-mount -ppp -ppp-mod-pppoe -ip6tables -odhcp6c -kmod-ipv6 -kmod-ip6tables -odhcpd-ipv6only"

However I got the following exception:

Configuring uhttpd.
Configuring uhttpd-mod-ubus.
Configuring kmod-ipt-offload.
Configuring urngd.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-firewall:
 * 	libip4tc2
 * 	libip6tc2
 * opkg_install_cmd: Cannot install package luci-app-firewall.
make[2]: *** [Makefile:156: package_install] Error 255
make[1]: *** [Makefile:117: _call_image] Error 2
make: *** [Makefile:196: image] Error 2

So I tried removing luci-app-firewall from the list of packages and ran with this command line:

make clean;make image PROFILE=tl-wr703n-v1 PACKAGES="uhttpd uhttpd-mod-ubus libiwinfo-lua luci-base luci-mod-admin-full luci-theme-bootstrap kmod-rt2800-lib kmod-rt2800-usb rt2800-usb-firmware kmod-usb-storage kmod-fs-ext4 block-mount -ppp -ppp-mod-pppoe -ip6tables -odhcp6c -kmod-ipv6 -kmod-ip6tables -odhcpd-ipv6only"

But I got the same exception for another package:

Configuring kmod-ipt-offload.
Configuring urngd.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for firewall:
 * 	libip4tc2
 * 	libip6tc2
 * opkg_install_cmd: Cannot install package firewall.
make[2]: *** [Makefile:156: package_install] Error 255
make[1]: *** [Makefile:117: _call_image] Error 2
make: *** [Makefile:196: image] Error 2

I tried appending these package to the list of packages I want , but that didn’t help:

make clean;make image PROFILE=tl-wr703n-v1 PACKAGES="uhttpd uhttpd-mod-ubus libiwinfo-lua luci-base luci-mod-admin-full luci-theme-bootstrap kmod-rt2800-lib kmod-rt2800-usb rt2800-usb-firmware kmod-usb-storage kmod-fs-ext4 block-mount libip4tc2 libip6tc2 -ppp -ppp-mod-pppoe -ip6tables -odhcp6c -kmod-ipv6 -kmod-ip6tables -odhcpd-ipv6only" 

Got the same exception:

Configuring kmod-ipt-offload.
Configuring urngd.
Collected errors:
 * opkg_install_cmd: Cannot install package libip4tc2.
 * opkg_install_cmd: Cannot install package libip6tc2.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for firewall:
 * 	libip4tc2
 * 	libip6tc2
 * opkg_install_cmd: Cannot install package firewall.
make[2]: *** [Makefile:156: package_install] Error 255
make[1]: *** [Makefile:117: _call_image] Error 2
make: *** [Makefile:196: image] Error 2

I have also noticed the following when it was downloading the packages:

Installing ubox (2019-06-16-4df34a4d-3) to root...
Downloading http://downloads.openwrt.org/snapshots/packages/mips_24kc/base/ubox_2019-06-16-4df34a4d-3_mips_24kc.ipk
Unknown package 'libip4tc2'.
Unknown package 'libip6tc2'.
Installing base-files (198-r10242-3c401f4) to root...
Downloading http://downloads.openwrt.org/snapshots/targets/ar71xx/tiny/packages/base-files_198-r10242-3c401f4_mips_24kc.ipk

Am I doing something wrong there or there’s some bug involved? I tried following these instructions: https://openwrt.org/docs/guide-user/additional-software/saving_space

26.12.20192696Base systemBug ReportVery LowMedium[ramips/mt7621] Sysupgrade not working for master image...TrunkUnconfirmed Task Description

Recent builds from master seem to have broken sysupgrade on mt7621. I have observed this on the following devices:
- DIR-860L rev B1
- DIR-878 rev A1 (pull request here)

It first happened on the DIR-878 A1, where I flashed the author’s image and was unable to switch to either newer master builds or 19.07 builds. I then verified this on the DIR-860L, and it showed the same behaviour.

Sysupgrade does not show any errors. It closes all pending sessions and seems to proceed normally, but after a reboot the firmware has not been upgraded.

 


26.12.20192695KernelBug ReportVery LowCriticalKernel panic during boot on Gehua ghl-r-001TrunkNew Task Description

See https://github.com/openwrt/openwrt/pull/2483

without this patch the ghl-r-001 cannot be boot.

reproduct in both 19.7-rc2 and git master.

25.12.20192694Base systemBug ReportVery LowMediumClearfog Pro: Default LAN / WAN Interface assignment is...openwrt-19.07Unconfirmed Task Description

On my Clearfog Pro Rev 2.0 the interfaces map as follows:

eth0: switch
eth1: SFP
eth2: standalone ethernet

This does not match the current description in /etc/board.d/02_network:

# eth0 is standalone ethernet
# eth1 is switch (-pro) or standalone ethernet (-base)
# eth2 is SFP
ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"

While I don’t agree with the lan/wan decision made here, at least the comment should match reality.
So I suggest changing it to:

# eth2 is standalone ethernet
# eth0 is switch (-pro) or standalone ethernet (-base)
# eth1 is SFP
ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2"

Please also see the attached patch file, which also changes the switch configuration accordingly.

19.12.20192689Base systemBug ReportVery LowMediumnetifd /etc/config/wireless wifi-iface requires a key o...TrunkUnconfirmed Task Description

What the subject says.

If /etc/config/wireless is configured to use a wpa_psk_file to supply the wpa pre shared keys, but no “key” option is provided, the interface will refuse to start.

You can see the flawed logic here: https://github.com/openwrt/openwrt/blob/24b97579d20b6ac6df81654a953386d2912fc324/package/network/services/hostapd/files/hostapd.sh

psk|sae|psk-sae)
			json_get_vars key wpa_psk_file
			if [ ${#key} -lt 8 ]; then
				wireless_setup_vif_failed INVALID_WPA_PSK
				return 1
			elif [ ${#key} -eq 64 ]; then
				append bss_conf "wpa_psk=$key" "$N"
			else
				append bss_conf "wpa_passphrase=$key" "$N"
			fi
			[ -n "$wpa_psk_file" ] && {
				[ -e "$wpa_psk_file" ] || touch "$wpa_psk_file"
				append bss_conf "wpa_psk_file=$wpa_psk_file" "$N"
			}
			[ "$eapol_version" -ge "1" -a "$eapol_version" -le "2" ] && append bss_conf "eapol_version=$eapol_version" "$N"

			wps_possible=1

The existence of the wpa_psk_file option should mean that the key value is optional. But instead the wpa_psk_file option is treated as an additional option, not a replacement.

19.12.20192688Base systemBug ReportVery LowLownetifd /etc/config/wireless wpa_psk_file changes not de...TrunkUnconfirmed Task Description

If a wifi-iface is configured to use a wpa_psk_file to supply the pre-shared keys for wifi authentication, and that wpa_psk_file has it’s contents changed (The file path stays the same), then reload_config has no effect.

Hostapd, apparently, does not check the wpa_psk_file after startup, and netifd / UCI does not understand to track the contents of the file to determine if the hostapd instance should be restarted.

Ideal outcome:

If the contents of the file indicated by the wpa_psk_file option in the wifi-iface section of /etc/config/wireless changes when reload_config is called, then hostapd is sent a signal that causes it to gracefully reload the wpa_psk_file information without shutting down existing connections.

Acceptable outcome:

If the contents of the file indicated by the wpa_psk_file option in the wifi-iface section of /etc/config/wireless changes when reload_config is called, then hostapd is restarted.

18.12.20192687Base systemBug ReportVery LowVery LowWiFi LED does not dynamically track state of radio on Z...openwrt-19.07Unconfirmed Task Description

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

 

Occurs on ZBT-WE3526 (16M) an MT76 unit with 512MB Ram

Stock 19.07, but has been this way since 18.06.xx

Steps to reproduce:
Log into to LuCi and disable a wifi radio, LED remains on.

reboot, radiox LED is now off, so LED is only set at boot

Log back into luci, turn radio on, radio becomes operational (STAs can connect) but LED remains off.

Desired behavior: LED tracks state of radio without requiring a reboot.

18.12.20192686Base systemBug ReportVery LowLowKernel reports -> ath: phy0: DMA failed to stop in 10 m...TrunkUnconfirmed Task Description

Netgear WNDR3800 - Atheros AR7161 rev 2

OpenWrt 19.07.0-rc2 r10775-db8345d8e4 / LuCI openwrt-19.07 branch git-19.344.41526-af5d665

I have this router configured on its 5G wifi as a WDS Client bridged to the 2.4G wifi acting as a repeater.

I have seen other reports of these errors but the ticket was closed with no action.

The reports appear randomly.

root@Repeater:~# logread -e DMA
Wed Dec 18 10:11:47 2019 kern.err kernel: [60495.010703] ath: phy0: DMA failed to stop in 10 ms AR_CR=0×00000024 AR_DIAG_SW=0×42100020 DMADBG_7=0x000084c0
Wed Dec 18 10:54:06 2019 kern.err kernel: [63034.316390] ath: phy0: DMA failed to stop in 10 ms AR_CR=0×00000024 AR_DIAG_SW=0×42100020 DMADBG_7=0x000084c0
Wed Dec 18 11:36:40 2019 kern.err kernel: [65588.469314] ath: phy0: DMA failed to stop in 10 ms AR_CR=0×00000024 AR_DIAG_SW=0×42100020 DMADBG_7=0x000084c0
Wed Dec 18 11:51:04 2019 kern.err kernel: [66451.903016] ath: phy0: DMA failed to stop in 10 ms AR_CR=0×00000024 AR_DIAG_SW=0×42100020 DMADBG_7=0x000084c0
Wed Dec 18 12:27:57 2019 kern.err kernel: [68665.271786] ath: phy0: DMA failed to stop in 10 ms AR_CR=0×00000024 AR_DIAG_SW=0×42100020 DMADBG_7=0x000084c0
Wed Dec 18 16:41:11 2019 kern.err kernel: [83858.406636] ath: phy0: DMA failed to stop in 10 ms AR_CR=0×00000024 AR_DIAG_SW=0×42100020 DMADBG_7=0x000084c0

18.12.20192685Base systemBug ReportVery LowLowColdplug too soon; hotplug.d scripts not run for some e...openwrt-19.07Unconfirmed Task Description

OpenWrt 19.07.0-rc2, latest openwrt-packages.

Occurs on at least ath79 but looking at the code this is not device-specific.

1. Have USB devices for which you have hotplug scripts (e.g. from p910d and sane-backends)
2. Boot (or reboot) with usb devices already plugged in.
3. Observe that the actions in the hotplug script (e.g. setting permissions / group ownership that don’t belong in the base system (i.e. hotplug.json)) as it’d be bloat to detect product:vendor ip pairs and take appropriate action for all the various packages and devices hotplug handles – if hotplug.json could have hotplug.json.d or somesuch it would alleviate most of this pain.

Looking at the procd code coldplug (udevtrigger) is called during ‘early’ init, which means that hotplug.d scripts are not yet present. Because /etc/init.d/boot (or any other initscript) no longer does a later call to udevtrigger, the events get missed).

If udevtrigger were called during regular init this wouldn’t be an issue (but probably the coldplug is needed earlier *as well* for devices needed to boot the system.

See also #1903 and #996 (they are likely the same root cause).

18.12.20192684KernelFeature RequestVery LowLowUpdate mt76 driver to latest versionTrunkUnconfirmed Task Description

Device: TP-Link RE650v1
Release: Trunk

It would be nice, if the the mt76-driver could be updated to the latest version from https://github.com/openwrt/mt76 as
the version which ist referenced in the openwrt-masterbranch is fairly old.

The new version from openwrt/mt76 supports "survey noise" at least for the mt7615 chip, which is a very nice thing.

Thanks


17.12.20192681Base systemBug ReportVery LowHighISP's DHCP option 121 makes 18.06.5 get no default GWopenwrt-18.06Unconfirmed Task Description

HW: TP-Link TL-WR1043ND v1
Openwrt affected: tried 18.06.4, 18.06.5

DHCP offer from ISP:

22:48:09.365836 00:04:96:51:fe:50 > 74:ea:3a:d1:2d:16, ethertype IPv4 (0x0800), length 354: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 340)
    10.45.64.5.67 > 213.xx.xx.23.68: BOOTP/DHCP, Reply, length 312, hops 1, xid 0x3313791, secs 63, Flags [none]
	  Your-IP 213.xx.xx.23
	  Gateway-IP 10.45.64.5
	  Client-Ethernet-Address 74:ea:3a:d1:2d:16
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 46.xx.xx.202
	    Lease-Time Option 51, length 4: 43200
	    Subnet-Mask Option 1, length 4: 255.255.255.128
	    Default-Gateway Option 3, length 4: 213.xx.xx.5
	    Domain-Name-Server Option 6, length 8: 10.81.3.19,10.59.3.19
	    Domain-Name Option 15, length 10: "abcxyz.ru"
	    BR Option 28, length 4: 213.xx.xx.127
	    Classless-Static-Route Option 121, length 14: (213.xx.xx.0/25:213.xx.xx.5),(default:213.xx.xx.5)

18.06.5 reaction to Classless-Static-Route Option 121:

root@OpenWrt:~# ip r
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1
213.хх.хх.0/25 via 213.хх.хх.5 dev eth0.2  src 213.хх.хх.23

Fixing:

root@OpenWrt:~# ip r del 213.xx.xx.0/25
root@OpenWrt:~# ip r add 213.xx.xx.0/25 dev eth0.2 src 213.xx.xx.23
root@OpenWrt:~# ip r add default via 213.xx.xx.5 dev eth0.2
root@OpenWrt:~# ip r
default via 213.xx.xx.5 dev eth0.2 
192.168.2.0/24 dev br-lan scope link  src 192.168.2.1 
213.xx.xx.0/25 dev eth0.2 scope link  src 213.xx.xx.23

All things above rised from my attempt to switch from 15.05.1 to new stable 18.06.x branch of Openwrt
15.05.1 works without a glitch with this ISP.

16.12.20192678Base systemBug ReportVery LowLowWireless client cannot connect to open wireless network...TrunkUnconfirmed Task Description

Wireless client won’t connect to an open wireless network (encryption set to none) after previous encrypted connection. A reboot fixes the problem. Sounds similar to OpenWISP problem: https://github.com/openwisp/netjsonconfig/issues/113

I’m using Comfast CF-E110N-V2 8MB
OpenWRT SNAPSHOT r11676-a15f658ed0
target: ath79/generic mips_24kc

Steps to reproduce:
1. Connect to an encrypted wireless network, eg.
config wifi-iface ‘wifinet0’ option ssid ‘homewifi’ option device ‘radio0’ option mode ‘sta’ option network ‘wwan’ option key ‘versecurepassword’ option encryption ‘psk2’ 2. Confirm it’s working.
3. Disable ssid ‘homewifi’ option disabled ‘1’ 4. Connect to an open wireless network, eg.
config wifi-iface ‘wifinet1’ option ssid ‘airport free wifi’ option device ‘radio0’ option mode ‘sta’ option network ‘wwan2’ option encryption ‘none’ 5. Confirm that the device doesn’t connect to the ‘airport free wifi’ network
6. restart device
7. confirm that the device now connects to the ‘airport free wifi’ network.

16.12.20192677Base systemBug ReportVery LowMediumAth79 Reset button not workingTrunkUnconfirmed Task Description

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

 Press the reset button, observe that nothing happens.  We expect the device to reboot or perform factory reset.

https://forum.openwrt.org/t/ath79-reset-button-not-working/50564

I am on the latest master snapshot using a Comfast CF-E5. The reset button is supposed to be on GPIO17. I have an IRQ entry of gpio-ath79 17 on my system but when I press the button I can never see any response in the logs, and the device never responds to the key with either a reboot or firstboot. What can I check? It used to work on an older version. I have documented what I have found on the forum.

https://forum.openwrt.org/t/ath79-reset-button-not-working/50564

cat /proc/interrupts

         CPU0       
3:      16348      MIPS   3  ehci_hcd:usb1
4:          0      MIPS   4  19000000.eth
5:      24687      MIPS   5  1a000000.eth
7:     153665      MIPS   7  timer
9:         30      MISC   3  ttyS0

12: 93596 INTC 0 ath9k
17: 0 gpio-ath79 17 keys
ERR: 49

Here is the relevant portion of the DTS file

keys {
	compatible = "gpio-keys";
	reset {
		label = "reset";
		linux,code = <KEY_RESTART>;
		gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
	};
};

root@OpenWrt:~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-31, parent: platform/18040000.gpio, 18040000.gpio:
gpio-0 ( |cf-e5:blue:wlan ) out hi
gpio-1 ( |sysfs ) out hi
gpio-2 ( |cf-e5:blue:rssi0 ) out hi
gpio-3 ( |cf-e5:blue:rssi1 ) out hi
gpio-4 ( |cf-e5:blue:wan ) out hi
gpio-11 ( |sysfs ) out hi
gpio-12 ( |sysfs ) out hi
gpio-14 ( |sysfs ) out hi
gpio-15 ( |cf-e5:blue:rssi2 ) out hi
gpio-16 ( |cf-e5:blue:lan ) out lo
gpio-17 ( |reset ) in hi IRQ

15.12.20192676Base systemBug ReportVery LowLowUnexpected realpath behaviouropenwrt-19.07Unconfirmed Task Description

There is a problem with creating chrooted SFTP access using OpenSSH package. However, it seems that the problem isn’t with the package, rather with realpath function of OpenWRT. The whole description of the problem was already provided in forum, here I only copy the part of the log file:

Nov 29 10:06:27 OpenWrt internal-sftp[12557]: realpath "."
Nov 29 10:06:27 OpenWrt internal-sftp[12557]: debug3: request 46352: sent status 2
Nov 29 10:06:27 OpenWrt internal-sftp[12557]: sent status No such file

Tested on both 18.06.5 and 19.07.0-rc1 with the same result.

15.12.20192675Base systemBug ReportVery LowLowsmall fix for WPA3TrunkUnconfirmed Task Description

There is a error in readme for 19.07:

Highlights in OpenWrt 19.07
   * WPA3 configuration support
     * Install wpad-openssl or wpad-wolfssl for WPA3 support
                               ^^^^^^^^^^^^

this is incorrect. I wasted some hours trying to get WPA3 to work with wpad-wolfssl and failed, apparently WPA3 only works with wpad-openssl.

please remove mention of wpad-woflssl for WPA3 in readme.

Others have encountered the same problem, based on the same mistake in readme:

[1]

https://forum.openwrt.org/t/problems-trying-out-wpa3/49249/3

wolfssl didn’t work → “I have changed to use wpad-openssl and it seems to work.”

[2]

https://forum.openwrt.org/t/wpa3-wolfssl-fail-openssl-success/50161

wolfssl - fails, openssl - works

[3]

https://forum.openwrt.org/t/no-option-in-gui-to-set-wpa3-auth/45652/6

“It seems like wpad-openssl is working in general better then wpad-wolfssl”

[4]

https://forum.openwrt.org/t/wpa3-support-in-openwrt/10554/115

“many reports of better success on openssl rather than wolfssl”

13.12.20192673Base systemBug ReportVery LowLowrsn_preauth_interface should be configurableTrunkUnconfirmed Task Description

OpenWrt currently automatically uses the client-facing interface ($network_bridge) as rsn_preauth_interface.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/hostapd/files/hostapd.sh;h=4bf6a6c9712785f40d059445f80f19d4f2992f4b;hb=HEAD#l554

It would be preferable to be able to configure this manually, since this is the interface where 802.11i preauthentication frames are transmitted over. This should not be mixed with the actual client network.

The hostapd configuration says the following:

# Space separated list of interfaces from which pre-authentication frames are
# accepted (e.g., 'eth0' or 'eth0 wlan0wds0'. This list should include all
# interface that are used for connections to other APs. This could include
# wired interfaces and WDS links. The normal wireless data interface towards
# associated stations (e.g., wlan0) should not be added, since
# pre-authentication is only used with APs other than the currently associated
# one.
#rsn_preauth_interfaces=eth0
13.12.20192671PackagesFeature RequestVery LowLowAdd golang tag supportTrunkUnconfirmed Task Description

I’m maintaining the nextdns package, which is written in Go. As they are statically linked, Go binaries tend to be large. Some features of this software are not relevant to openwrt and some others could be made optional. Those features and their dependencies could easily be stripped off using go tags at compile time.

Would you consider adding Go compile tag support? I can help if needed.

12.12.20192670KernelBug ReportVery LowHigh[ATH79] unstable USB on WR1043 v2openwrt-19.07Unconfirmed Task Description

Hi there!

I recently upgraded my TP-Link TL-WR1043 v2 device to the ath79 targeted 19.07-rc2 release using my custom build, which I have compiled with the image builder.

make image PROFILE=tplink_tl-wr1043nd-v2 PACKAGES="block-mount curl diffutils ethtool iperf3 iwinfo htop kmod-fs-ext4 kmod-usb-storage luci mailsend-nossl minidlna nfs-kernel-server ppp-mod-pppoe shadow-su transmission-daemon-mbedtls transmission-web vsftpd zram-swap -ip6tables -kmod-ip6tables -kmod-ipv6 -kmod-nf-conntrack6 -kmod-nf-ipt6 -libopenssl1.1 -odhcp6c -odhcpd-ipv6only -luci-proto-ipv6 -libip6tc2"

I just recently rolled back to an EXT4 partition, because of it's smaller memory footprint. (just mounting a ~50GB f2fs partition consumes around 10MBs of memory)
So in the very first attempt I wanted to copy back everything to my Transcend 790K. But after the first 500-1000 MBs(mix of archives, image, text and video files), the transaction speed has fallen down couple of times. I thought maybe the passive FTP connection was the problem, because after a few automatic reconnect attempts, the speed of the copy has been normalized again and in the end the device was connected. Later I found that the USB devices was reseted.
I had another try with a Sandisk Ultra Fit drive (SDCZ-43), but the result and the configuration was pretty sam. ~50GB EXT4 partition without journal and without barrier.
I force upgraded the machine to the ar71xx target and Filezilla so far copied back 16GBs without any problem.
Target ATH79 seem to be has so many problems with the USB subsystem, please see my other bugreport for the WDR4300 as well: FS#2567 - [ATH79] USB speed degradation on WDR4300.

Let me know if I can help the bughunting any way,
thanks and regards!

10.12.20192667Base systemBug ReportVery LowMediumLantiq specific, "dsl interfae" VDSL driver, unhelpful ...openwrt-19.07Unconfirmed Task Description

Probably, FAO "John Crispin" Lantiq maintainer, apparently!,

On OpenWRT 19.07.0rc2, both on TP-LINK TD-W8980 and also BT-Homehub-v5-type-A [lantiq xrx200 devices] ...

I am finding a consistent frustrating limitation, that the default config, and LuCI web interface, does not provide any way to expose the MTU capability of the built-in VDSL driver, which allows for full 1500 MTU to be carried on PPPoE on VDSL, as is commonplace in provided routers.

Specifically, the VDSL device "dsl0" (and, in my case, VLAN 101, "dsl0.101"), has an unhelpful default MTU restriction to 1500, such that PPPoE (as is common in UK!) does not work at the normally expected 1500MTU, requiring workarounds 1492MTU MSS-clamping hacks. Turns out this is fixable at the configuration-level, but not via anything exposed in web-interface (as underlying DSL MTU is wrong from the start...).

Example below, extra /etc/config/network lines to support the standard MTU:-

config interface 'wan'

      option ifname 'dsl0.101'
      option proto 'pppoe'
      option password 'PASSWORD'
      option ipv6 'auto'
      option username 'USERNAME'
      option mtu '1500'           #exposed via web, still needs setting, to try to negotiate that MTU 1500 inside PPPoE...

config device 'wan_dev'

      option name 'dsl0'
      option macaddr 'e8:11:22:33:44:4b'
      option mtu '1508'           #This line Had to be added manually

config device 'wan_dev2' # Extra section added, if not done,

      option name 'dsl0.101'             #  MTU wrong for the dsl 0.101 link!
      option macaddr 'e8:11:22:33:44:4b' #  As in this case having to use VLAN101
      option mtu '1508'                  #  As per UK Openreach VDSL configuration...

In my view, at the very least, the 'internal' DSL driver, should be allowing a larger mtu like 1508, 'by default'. Possibly, if this is done at driver level, the PPPoE MTU won't need to be specified at all.

The PPPoE over VDSL configuration, also needed to be told to attempt 1500 MTU, which I understand relies upon rfc4638 PPP extension, in order to have fully functional 1500MTU connection. Not having this has caused connectivity issues requiring MSS clamping etc. and is, in short, undesirable!.

It think, the PPPoE over PTM over VDSL should, additionally, attempt this 1500-MTU 'by default' unless the MTU is reduced manually in the configuration.

I understand this should be passed to Lantiq maintainer, "John Crispin" apparently!, according to IRC-discussions!.

With many thanks,

09.12.20192666Base systemBug ReportVery LowMediumprocd: reboot inside lxc container causes shutdownopenwrt-19.07Assigned Task Description

- Device problem occurs on
armvirt64
- Software versions of OpenWrt/LEDE release, packages, etc.
openwrt-19.07-rc2
- Steps to reproduce

Create a lxc package from the openwrt-19.07-rc2 rootfs package.
Start a lxc container using the openwrt lxc package.
Initiate a `reboot` command from inside the container.

Expected result: Container reboots.
Actual result: Container halts.

Current Version openwrt-19.07-rc2.
While running in a lxc container, initiating a reboot from openwrt results in a shutdown of the container instead of rebooting the container.

This appears to have been caused by commit <832369078d818d19ab64051fdc8da9e06c90ad88> state: fix shutdown when running in a container ( FS#2425 ).
Instead of triggering reboot(reboot_event);, it detects that it is inside a container and exits pid 1, resulting in the container halting.

There is a patch at [0] to resolve this, but would likely break the original intention of the fix above.

09.12.20192662Base systemBug ReportVery LowLowmt7628an_hiwifi_hc5761a usb has no powerTrunkUnconfirmed Task Description

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

 

I have test on hiwifi_hc5761a usb is no power,can’t not work.

verison: openwrt trunk latest version


08.12.20192661Base systemBug ReportVery LowLowWeekdays restrcition in FW rule do not workTrunkUnconfirmed Task Description

Supply the following if possible:
- Device Netgear R6220
- Software versions LuCI openwrt-19.07 branch (git-19.334.63023-039ef1f) / OpenWrt 19.07.0-rc2 r10775-db8345d8e4
- Steps to reproduce
Create accept FW rule with some weekday restrictions.
Weekdays restrictions are stored in the configuration file as list, and do not get applied to the firewall rules. (ie rule is just ignored by firewall)
Manually changing the firewall config file from
list weekdays ‘Sun’ list weekdays ‘Sat’

to
Option weekdays ‘Sun Sat’

will fix the issue. The rule is properly load and shows up in the GUI. Upon edition, the GUI put back the list weekdays.

 


07.12.20192658Base systemBug ReportVery LowLowAter upgrade from 18.06.2 to 18.06.5 WAN LED stopped t...openwrt-18.06Unconfirmed Task Description

- Device problem occurs on

 Linksys WRT3200ACM

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

 OpenWrt 18.06.5 r7897-9d401013fc / LuCI openwrt-18.06 branch (git-19.309.48729-bc17ef6) 

- Steps to reproduce

Ater upgrade from 18.06.2 to 18.06.5 WAN LED stopped to work after reboot. I can force this LED saving configuration (I do not change anything simply press Save & Apply)


config led ‘led_wan’

      option name 'WAN'
      option sysfs 'pca963x:rango:white:wan'
      option trigger 'netdev'
      option mode 'link tx rx'
      option dev 'pppoe-wan'
      option default '1'
07.12.20192657Base systemBug ReportVery LowLowFailsafe mode dosn't work on MikroTik (RB750r2, RB951Ui...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: MikroTik RB750r2, RB951Ui-2HnD
- Software versions of OpenWrt/LEDE: 18.06.5 fresh install

So I have several of both of these devices, and I can’t seem to do
boot to failsafe on them. After some initial difficulties I tried
some experiements with freshly flashed systems...

1) If I try the “wait for the 5Hz flashing LED then press button” method, it goes to 10Hz flashing and never stops... never responds
to pings on 192.168.1.1.

2) If I try the “watch for message on network with tcpdump”
method, no such message appears. Here I’ve tried both WAN and LAN
ports, and used tcpdump with and without filters (without filters
I see a bunch of stuff, but not the “please press button now”
message).

The above holds for both types of boxes. They work fine otherwise,
for basic as routers/access points.

I’d be happy to more testing... I have ar least one 750r2 that’s not
in service.

04.12.20192651KernelBug ReportVery LowLowOut of memory errors with 5 GHz Wi-Fi enabledopenwrt-19.07Waiting on reporter Task Description

- Device problem occurs on Archer C60 V2
- Software versions: Powered by LuCI Master (git-19.337.71995-796301a) / OpenWrt SNAPSHOT r11618-416d2cc71e

I’ve installed via TFTP “openwrt-19.07.0-rc2-ath79-generic-tplink_archer-c60-v2-squashfs-factory.bin” but because of some “out of memory” errors, i’ve upgraded to “openwrt-ath79-generic-tplink_archer-c60-v2-squashfs-sysupgrade.bin” in the hope of solving.
The problems continued, so i wrote to forum (https://forum.openwrt.org/t/tp-link-archer-c60-v2-19-07-0-rc2-ath79-snapshot-out-of-memory/49725) and i saw that other users had the same problem that they solved by disabling 5 Ghz.
Disabling the 5Ghz actually “out of memory” problems disappear. I was also able to install additional packages without problem.

 


03.12.20192650Base systemBug ReportVery LowLowr7800 19.07-rc2 unable to change channel for ACopenwrt-19.07Waiting on reporter Task Description

- Device problem occurs on - Linux r7800 4.14.156 #0 SMP Sat Nov 30 15:52:33 2019 armv7l GNU/Linux
- Software versions of OpenWrt/LEDE release - 19.07-rc2

in Luci when change channel number change actually never gets committed, when do manually in /etc/config/wireless and then reboot router comes up with 5GHz network disabled, after changing back to default channel 36 5GHz network is usable again.

please provide steps to collect log

in dmesg only:

(wlan0) entered blocking state
(wlan0) entered disabled state
   
01.12.20192647Base systemBug ReportVery LowHighEA6350v3 (IPQ4018) memory usage climbs until processes ...openwrt-19.07Unconfirmed Task Description

Device is Linksys EA6350v3

Issue occurs on 19.07 rc1, 19.07 rc2 and snapshot r11595 (snapshot version is by memory, but pretty sure that’s what I had on it).

Information for this bug report is based on 19.07 rc2 with the following packages installed for future potential use, but most not in use:
luci-app-sqm luci-proto-wireguard luci-app-wireguard ca-bundle curl https_dns_proxy luci-app-https_dns_proxy luci-app-statistics luci-app-samba kmod-usb-printer p910nd luci-app-p910nd diffutils minidlna luci-app-minidlna

Note: sqm, wireguard, https_dns_proxy, samba, usb printer, p910nd server, and minidlna are NOT in use. These are just the typical packages I add to my
router for future use.

Steps to reproduce:
Problem occurs after router runs for a few hours. EA6350v3 is set up as a wired access point for an EdgeRouter X (also on 19.07 rc2). The Edgerouter provides sqm and DNS and DHCP for LAN, guest and IOT VLANs. There are ~3 “Guest” 2.4 G wifi clients (a smart switch, an IP camera, a DEEBOT vacuum); the IOT VLAN is mapped to a physical port with an Ooma Telo plugged in (I know - I need to map the guest devices to IOT wifi someday...). The LAN is mapped to a physical port with a Roku 3 plugged in and to normal wifi. There are another ~4 or 5 5GHz wifi clients on the LAN wifi (a laptop, a couple Amazon Echo’s, a Google Home Mini, a Samsung Orbit Android phone) and a 2.4G LG Android phone on the 2.4 GHz wifi. CPU loading is quite low.

Memory usage starts out rather high (~100MB, climbs and climbs, eventually drops, climbs again, repeats. Eventually (a day or two) processes start getting killed to free up memory and things start dying. I have an EA8500 setup almost identically as a second AP in the house, and it’s memory usage sits around 50 MB versus 100MB to 200+MB for the EA6350v3. Something’s just not right...

The final message in the logs that repeats until processes begin to get killed is:

kern.warn kernel: [15897.905286] ath10k_ahb a000000.wifi: failed to increase tx pending count: -16, dropping

But the weird memory usage pattern precedes this message in the logs.

I’ve attached memory usage graphs and system and kernel logs from 19.07 rc2 to illustrate the problem. rc1 and snapshot behaved the same. This post also has logs showing processes getting killed if that helps diagnose: https://forum.openwrt.org/t/ipq4018-linksys-ea6350v3-wifi-dead-after-24-48-hrs/49080/3?u=eginnc

01.12.20192646Base systemBug ReportVery LowLowKernel panics with docler on openwrt x86-64TrunkUnconfirmed Task Description

I have been setting up openwrt for an i7-3770 server. I have it booting from uefi, with dual rootfs partition so I can upgrade with sysupgrade safely from openwrt itself. It’s really cool building openwrt from inside itself.

All seems to work wonderfully, but one important detail, which renders the whole thing unusable. The kernel panics again and again when using docker. The back traces are so different that I have no clue what the problem really is.

All I know for sure is it happens when docker is running. The usually are (if not always) general protection faults, but the hardware is rock solid, has been for 6+ years. The same dockers work fine on ubuntu on the same hardware, so I suspect the kernel, but as I said, I haven’t been able to stabilize it at all. I tried both 4.14 and 4.19, and I even tried to build openwrt with a newer kernel, but that’s not a 2 hours job, it’s way more involved.

01.12.20192645Base systemBug ReportVery LowCritical18.06.3 - Broken compatibility with flash on bcm6538 ba...openwrt-18.06Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: Pirelli A226M
- Software versions of OpenWrt/LEDE release: 18.06.3
- Steps to reproduce: just flash a 18.06.3 version or greater and verify the device won’t boot, hanging when it gets to mount local flash. 18.06.1 is working, never tried 18.06.2.

[    1.065798] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    1.073562] Please append a correct "root=" boot option; here are the available partitions:
[    1.082174] 1f00             128 mtdblock0 [    1.086283]  (driver?)
[    1.088718] 1f01           16128 mtdblock1 [    1.092823]  (driver?)
[    1.095210] 1f02             128 mtdblock2 [    1.099366]  (driver?)
[    1.101798] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
 


01.12.20192644Base systemBug ReportVery LowLowdnsmasq-full: Cannot satisfy dependenciesopenwrt-19.07Unconfirmed Task Description

Environment:
arch: mips
model: TP-link WDR4300
Openwrt: 19.07.0-rc1

Description:
I probably overlooked but hit the following issue where unable to install dnsmasq-full. Actually downloading only already gives the following warning and wonder if I can/should force-install:

# opkg install dnsmasq-full --download-only
Downloading http://downloads.openwrt.org/releases/19.07.0-rc1/packages/mips_24kc/base/dnsmasq-full_2.80-14_mips_24kc.ipk
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for dnsmasq-full:
 * 	kernel (= 4.14.151-1-342af9e4f67b3447c53216ab8e3b12a1)
 * opkg_install_cmd: Cannot install package dnsmasq-full.
30.11.20192643Base systemBug ReportVery LowHighEspressoBin: Internal error: synchronous parity or ECC ...TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)

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

11595-g5d2a900163

- Steps to reproduce

Boot and wait about an hour. Here are a series of kernel panics:

[ 4228.773060] Internal error: synchronous parity or ECC error: 86000018 [#1] SMP
[ 4228.777653] Modules linked in: ath9k ath9k_common xt_connlimit nf_conncount iptable_nat ipt_MASQUERADE ath9k_hw ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_NETMAP xt_FLOWOFFLOAD xt_CT 
nf_nat_ipv4 nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_recent xt_quota xt_pkttype xt_owner xt_multiport xt_mark xt
_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_condition xt_comment xt_bpf xt_addrtype xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptabl
e_mangle iptable_filter ipt_ECN ip_tables compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables
[ 4228.850958]  nf_reject_ipv6 tun gpio_button_hotplug
[ 4228.855992] Process kworker/1:2 (pid: 594, stack limit = 0x00000000a141aece)
[ 4228.863262] CPU: 1 PID: 594 Comm: kworker/1:2 Not tainted 4.19.85 #0
[ 4228.869776] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
[ 4228.876450] Workqueue:            (null) (events)
[ 4228.881258] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[ 4228.886204] pc : kthread_data+0x8/0x40
[ 4228.890035] lr : wq_worker_sleeping+0xc/0xb0
[ 4228.894410] sp : ffffff8009463d60
[ 4228.897819] x29: ffffff8009463d60 x28: 0000000000000000 
[ 4228.903281] x27: 0000000000000000 x26: ffffff80080b5318 
[ 4228.908746] x25: 0000000000000000 x24: ffffffc03e479a18 
[ 4228.914213] x23: ffffff8008868738 x22: ffffff800884e018 
[ 4228.919678] x21: ffffff8008853500 x20: ffffffc03e479500 
[ 4228.925146] x19: ffffffc03ffdd500 x18: 0000000000000000 
[ 4228.930609] x17: 0000000000000000 x16: 0000000000000000 
[ 4228.936076] x15: 0000000000000000 x14: 0000000000000000 
[ 4228.941541] x13: 0000000000000002 x12: 0000000000000001 
[ 4228.947006] x11: ffffffc03ffd94d0 x10: 00000000000007c0 
[ 4228.952472] x9 : ffffffc03e13d668 x8 : ffffff80088a9b08 
[ 4228.957937] x7 : 0000000000000000 x6 : 00000000050ebc0a 
[ 4228.963404] x5 : 0000000000000004 x4 : 0000000000000002 
[ 4228.968869] x3 : 00000000fffffff9 x2 : 0000000800000000 
[ 4228.974335] x1 : 0000000000000001 x0 : ffffffc03e479500 
[ 4228.979797] Call trace:
[ 4228.982331]  kthread_data+0x8/0x40
[ 4228.985813]  wq_worker_sleeping+0xc/0xb0
[ 4228.989859]  __schedule+0x140/0x570
[ 4228.993436]  schedule+0x58/0x80
[ 4228.996656]  worker_thread+0x370/0x468
[ 4229.000513]  kthread+0x110/0x120
[ 4229.003829]  ret_from_fork+0x10/0x1c
[ 4229.007521] Code: d65f03c0 d503201f a9be7bfd 910003fd (f9000bf3) 
[ 4229.013769] ---[ end trace 4f1be3f746ce5030 ]---
[ 4229.024169] Kernel panic - not syncing: Fatal exception
[ 4229.026728] SMP: stopping secondary CPUs
[ 4229.030757] Kernel Offset: disabled
[ 4229.034342] CPU features: 0x0,00002008
[ 4229.038186] Memory Limit: none
[ 4229.044024] Rebooting in 3 seconds..
[ 3676.038431] Internal error: synchronous parity or ECC error: 86000018 [#1] SMP
[ 3676.043028] Modules linked in: ath9k ath9k_common xt_connlimit nf_conncount iptable_nat ipt_MASQUERADE ath9k_hw ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_NETMAP xt_FLOWOFFLOAD xt_CT 
nf_nat_ipv4 nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_recent xt_quota xt_pkttype xt_owner xt_multiport xt_mark xt
_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_condition xt_comment xt_bpf xt_addrtype xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptabl
e_mangle iptable_filter ipt_ECN ip_tables compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables
[ 3676.116317]  nf_reject_ipv6 tun gpio_button_hotplug
[ 3676.121338] Process kworker/0:1 (pid: 41, stack limit = 0x000000008b9ea8ea)
[ 3676.128509] CPU: 0 PID: 41 Comm: kworker/0:1 Not tainted 4.19.85 #0
[ 3676.134953] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
[ 3676.141596] Workqueue:            (null) (events)
[ 3676.146426] pstate: 60400085 (nZCv daIf +PAN -UAO)
[ 3676.151361] pc : update_cfs_group+0x0/0xb0
[ 3676.155565] lr : dequeue_task_fair+0x440/0x960
[ 3676.160130] sp : ffffff8008a23cf0
[ 3676.163535] x29: ffffff8008a23cf0 x28: ffffffc03ffcd500 
[ 3676.169001] x27: ffffffc0043a5e80 x26: ffffff80088523f0 
[ 3676.174466] x25: afb504000afb5041 x24: ffffff80088c85c0 
[ 3676.179932] x23: 00000357e4f6aec0 x22: ffffff800884e018 
[ 3676.185397] x21: 0000000000000009 x20: ffffffc0043a5f40 
[ 3676.190863] x19: ffffffc03ffcd580 x18: 0000000000000000 
[ 3676.196329] x17: 0000000000000000 x16: 0000000000000000 
[ 3676.201793] x15: 0000000000000000 x14: 0000000000000000 
[ 3676.207259] x13: 0000000000000000 x12: 0000000000000000 
[ 3676.212726] x11: 0000000000000000 x10: 00000000000007c0 
[ 3676.218191] x9 : ffffffc0042eea68 x8 : ffffff80088a9b08 
[ 3676.223657] x7 : 0000000000000001 x6 : 00000000050e6eea 
[ 3676.229122] x5 : 00000000000000e8 x4 : ffffffc0043a3ff0 
[ 3676.234587] x3 : ffffffc03ffcdef8 x2 : ffffffc0043a5f70 
[ 3676.240053] x1 : 0000000000000001 x0 : ffffffc0043a5f40 
[ 3676.245519] Call trace:
[ 3676.248032]  update_cfs_group+0x0/0xb0
[ 3676.251887]  deactivate_task+0x6c/0x80
[ 3676.255740]  __schedule+0x10c/0x570
[ 3676.259321]  schedule+0x58/0x80
[ 3676.262546]  worker_thread+0x370/0x468
[ 3676.266400]  kthread+0x110/0x120
[ 3676.269715]  ret_from_fork+0x10/0x1c
[ 3676.273393] Code: a9425bf5 a8c37bfd d65f03c0 d503201f (f9404407) 
[ 3676.279660] ---[ end trace fa914749a4dc6031 ]---
[ 3676.285581] Kernel panic - not syncing: Fatal exception
[ 3676.289785] SMP: stopping secondary CPUs
[ 3676.293816] Kernel Offset: disabled
[ 3676.297399] CPU features: 0x0,00002008
[ 3676.301249] Memory Limit: none
[ 3676.304922] Rebooting in 3 seconds..
[12929.680240] Internal error: synchronous parity or ECC error: 86000018 [#1] SMP
[12929.684836] Modules linked in: ath9k ath9k_common xt_connlimit nf_conncount iptable_nat ipt_MASQUERADE ath9k_hw ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_NETMAP xt_FLOWOFFLOAD xt_CT nf_nat_ipv4 nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_recent xt_quota xt_pkttype xt_owner xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_condition xt_comment xt_bpf xt_addrtype xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables
[12929.758123]  nf_reject_ipv6 tun gpio_button_hotplug
[12929.763145] Process kworker/0:0 (pid: 5, stack limit = 0x00000000f766a017)
[12929.770227] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 4.19.85 #0
[12929.776582] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
[12929.783224] Workqueue:            (null) (events)
[12929.788054] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[12929.792990] pc : __schedule+0x348/0x570
[12929.796923] lr : __schedule+0x2d0/0x570
[12929.800862] sp : ffffff800804bd90
[12929.804268] x29: ffffff800804bd90 x28: 0000000000000000 
[12929.809733] x27: ffffffc03ffccef0 x26: ffffffc03ffccea0 
[12929.815199] x25: 0000000000000000 x24: ffffffc00427af10 
[12929.820664] x23: ffffff8008666460 x22: ffffff800884e018 
[12929.826129] x21: ffffffc00427de80 x20: ffffffc00427aa00 
[12929.831595] x19: ffffffc03ffcd500 x18: 0000000000000000 
[12929.837061] x17: 0000000000000000 x16: 0000000000000000 
[12929.842526] x15: 0000000000000000 x14: 0000000000000000 
[12929.847992] x13: 0000000000000002 x12: 0000000000000000 
[12929.853458] x11: ffffffc03ffc94d0 x10: 00000000000007c0 
[12929.858924] x9 : ffffffc004230168 x8 : ffffff80088a9b08 
[12929.864388] x7 : 0000000000000000 x6 : 000000199ea477c6 
[12929.869855] x5 : 000000000000030f x4 : 00000bc26cff1000 
[12929.875320] x3 : ffffffc03ffcdef8 x2 : ffffffc03ffcdef8 
[12929.880785] x1 : ffffffc03ffcdef8 x0 : 0000000000000008 
[12929.886251] Call trace:
[12929.888764]  __schedule+0x348/0x570
[12929.892348]  schedule+0x58/0x80
[12929.895575]  worker_thread+0x370/0x468
[12929.899428]  kthread+0x110/0x120
[12929.902742]  ret_from_fork+0x10/0x1c
[12929.906418] Code: b5fffeb7 d4210000 f9800291 c85f7e80 (927ef800) 
[12929.912686] ---[ end trace 5f4e2dd5c1da7acd ]---
[12929.918593] Kernel panic - not syncing: Fatal exception
[12929.922812] SMP: stopping secondary CPUs
[12929.926844] Kernel Offset: disabled
[12929.930426] CPU features: 0x0,00002008
[12929.934277] Memory Limit: none
[12929.937946] Rebooting in 3 seconds..
29.11.20192642Base systemBug ReportVery LowMediumStill "Internet LED" Problem In 18.06.5TrunkUnconfirmed Task Description

Hello;
- Device: TP-Link TD-W8970 V1
- OpenWRT Release: 18.06.4 to 18.06.5

In 18.06.2 I have a problem with “wifi LED” and I reported it as “ FS#2098 “. In 18.06.4, It was fixed but I have a new problem: When PPP Link established and Internet connected, the Internet LED does not Light up! If I use “/etc/init.d/led restart” command to restart It manually after the connection was established, the LED will light, But in case of restating the pppoe-wan or rebooting the device, It will turn off again.

29.11.20192641KernelBug ReportVery LowMediumDevice file for USB does not appear /dev/ttyUSB*openwrt-19.07Waiting on reporter Task Description

With new version 19.07.0rc I could not make my USB cellular (3g) modem dongle to work due to it simply no any serial device like /dev/ttyUSB* file appear with insertion.
In kernel log it appears report about new device insertion and nothing happenings after.
I made several attempts, with ‘modeswitch’ or without and several other ‘mods’ the result is the same no any /dev/ttyUSB*
With other version it was not such problem it appeared exactly three /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 es well as on my Ubuntu 19.04 And Ubuntu 16.04 Ubuntu 18.04

Both router and dongle are USB-2
Actually router is Asus RT-N16
and modem dongle is Alcatel One Touch X090S

P.S. I need this one to be solved to report other bugs. :)

Showing tasks 51 - 100 of 945 Page 2 of 19 - 1 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing