OpenWrt/LEDE Project

Welcome to the OpenWrt Project bug reporting and issue tracking system

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

Notifications of all submissions and task changes are sent to

OpenedIDCategoryTask Type  ascPrioritySeveritySummaryReported InStatus
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 (, 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

Build firmware images for Iomega StorCenter ix2-200


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


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

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

12.09.20192492ToolchainBuild FailureVery LowMediumWhen building an image from an imagebuilder the build f...TrunkUnconfirmed Task Description

When building an image (from git commit 81764319637f408623ed9f4bae3f0d149b010f07) from already built imagebuilder for ar71xx target, the build fails at the end (after “Finalizing root filesystem”) because of missing ‘mips-openwrt-linux-musl’. I searched the original build directory in openwrt tree and this lib seems to be to find (among others) in:


but for some reason is not saved into the imagebuilder image.

This is the message from the end of imagebuilder build.

Finalizing root filesystem...
Enabling urandom_seed
Enabling urngd
/home/risa/openwrt/openwrt-imagebuilder-ar71xx-generic.Linux-x86_64/staging_dir/host/bin/find: '/home/risa/openwrt/openwrt-imagebuilder-ar71xx-generic.Linux-x86_64/staging_dir/target-mips_24kc_musl/root-ar71xx': No such file or directory
/home/risa/openwrt/openwrt-imagebuilder-ar71xx-generic.Linux-x86_64/staging_dir/host/bin/find: '/home/risa/openwrt/openwrt-imagebuilder-ar71xx-generic.Linux-x86_64/staging_dir/target-mips_24kc_musl/root-ar71xx': No such file or directory
Traceback (most recent call last):
  File "/home/risa/openwrt/openwrt-imagebuilder-ar71xx-generic.Linux-x86_64/staging_dir/host/bin/mklibs", line 426, in <module>
    inode = os.stat(prog)[ST_INO]
FileNotFoundError: [Errno 2] No such file or directory: 'mips-openwrt-linux-musl'
make[2]: *** [Makefile:163: prepare_rootfs] Error 1
make[1]: *** [Makefile:119: _call_image] Error 2
make: *** [Makefile:197: image] Error 2
31.07.20192418Base systemBuild FailureVery LowVery LowBuild failure - Netgear 6220 (mt7621)TrunkUnconfirmed Task Description

04.04.20192221PackagesBuild FailureVery LowLowbuilding grub on 32 bit host failsTrunkUnconfirmed Task Description

The build for x86 stops at the following step:

make[8]: Entering directory '/home/lars/opennet/git/firmware/openwrt/build_dir/hostpkg/grub-2.02/grub-core'
i486-openwrt-linux-musl-gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -m32 -nostdinc -isystem /home/lars/opennet/git/firmware/openwrt/staging_dir/toolchain-i386_pentium4_gcc-7.4.0_musl/lib/gcc/i486-openwrt-linux-musl/7.4.0/include -I../include -I../include -DGRUB_FILE=\"lib/i386/relocator64.S\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/    -I/home/lars/opennet/git/firmware/openwrt/staging_dir/host/include -I/home/lars/opennet/git/firmware/openwrt/staging_dir/hostpkg/include -I/home/lars/opennet/git/firmware/openwrt/staging_dir/target-i386_pentium4_musl/host/include -D_FILE_OFFSET_BITS=64 -g  -m32 -msoft-float -DGRUB_FILE=\"lib/i386/relocator64.S\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/ -DASM_FILE=1    -O2 -I/home/lars/opennet/git/firmware/openwrt/staging_dir/host/include -I/home/lars/opennet/git/firmware/openwrt/staging_dir/hostpkg/include -I/home/lars/opennet/git/firmware/openwrt/staging_dir/target-i386_pentium4_musl/host/include -MT lib/i386/relocator_module-relocator64.o -MD -MP -MF lib/i386/.deps-core/relocator_module-relocator64.Tpo -c -o lib/i386/relocator_module-relocator64.o `test -f 'lib/i386/relocator64.S' || echo './'`lib/i386/relocator64.S
lib/i386/relocator64.S: Assembler messages:
lib/i386/relocator64.S:66: Error: unknown pseudo-op: `.code64'
lib/i386/relocator64.S:74: Error: bad register name `%rax'
lib/i386/relocator64.S:98: Error: bad register name `%rax'
lib/i386/relocator64.S:132: Error: bad register name `%rip)'
make[8]: *** [Makefile:28991: lib/i386/relocator_module-relocator64.o] Error 1
make[8]: Leaving directory '/home/lars/opennet/git/firmware/openwrt/build_dir/hostpkg/grub-2.02/grub-core'

The build host is a 32 bit Linux system.
This does not seem to happen on a 64 bit build host.

01.12.20181980Base systemBuild FailureVery LowMediumBuild fails due to incorrectly detecting x32TrunkUnconfirmed Task Description

When attempting to build OpenWRT, the toolchain generation fails due to tools/gmp/Makefile trying to detect an x32 compiler. It builds successfully but MPFR then fails to compile as it targets x86_64 but gmp has been built as x32

Deleting the following conditional from the GMP Makefile fixes the issue:

ifeq ($(GNU_HOST_NAME),x86_64-linux-gnux32)

11.05.20181543PackagesBuild FailureVery LowCriticalMany packages in snapshot failing on one build, ok on n...TrunkUnconfirmed Task Description

Occurs on all architectures apparently at random with faillogs.
After next build some that failed will be ok and some that previously built will fail.
eg submit a PR on Travis shows fail on dependencies. After next automated build, Travis errors will be different, or if lucky will pass, only to fail again after the next build.
It seems the build system is chasing its tail somehow.

06.03.20181414ToolchainBuild FailureVery LowVery Lowmbedtls: building with ccache: /staging_dir/host/bin/cc...TrunkUnconfirmed Task Description

I am currently trying to compile OpenWRT for


I am using


I am building in the following way:

The build was carried out on a git clone git://, later brought up to date with a git pull, with latest commit from 2018-03-05T10:44:20+01:00, commit hash 5cbd22bb0f.

Into this git clone a previously generated .config seed, made previously by make menuconfig and ./scripts/, was copied over to ./.config.

From there on, the following commands were issued:

./scripts/feeds update -a
./scripts/feeds install -a
make -j1 V=s defconfig
make -j1 V=s download
make -j1 V=s IGNORE_ERRORS=m | tee make.log

When it comed to building mbedtls, there are the following lines of output which indicate something is wrong:

make[3]: [Makefile:75: /home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/2018-02-26_12-04-45_-_custom-wo-pie_feeds-rooter-custom/build_dir/target-mips_24kc_musl/mbedtls-2.7.0/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 123 (ignored)
/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/2018-02-26_12-04-45_-_custom-wo-pie_feeds-rooter-custom/staging_dir/host/bin/ccache: invalid option -- 'd'
    ccache [options]

Build continues, (seemingliy) successfully: Indicated by the further output of make, and issuing later a make -j1 V=s (i.e. without IGNORE_ERRORS=m), does not bring this up again.

The toolchain (./staging_dir/toolchain-*) is mips_24kc_gcc-5.5.0_musl.

Build is carried out on an x86_64 Arch Linux machine.

Attached are the following files:

  • .config-diffconfig-seed: The .config-seed used for make defconfig,
  • .config: The .config created by the make defconfig and used for the build,
  • mbedtls.log: The pa[.config-diffconfig-seed.txt]( of the output of make -j1 V=s IGNORE_ERRORS=m regarding building mbedtls,
  • make.log.stdout.xz: For your interest, the full output of make -j1 V=s IGNORE_ERRORS=m (.xz compressed; decompresses to about 29 MB) (Note that at the end another build error occurs, which seems not to be related to embedtls),
  • feeds.conf: The feeds.conf used.

(Note that I just forgot to capture stderr too, but the error messages seem to be present in stdout. Since a full rebuild takes a day on my machine, I won’t do that if not necessary.)

05.03.20181412Base systemBuild FailureVery LowLowLINK busybox_unstripped fails: cc1: note: someone does ...TrunkUnconfirmed Task Description

I am currently trying to compile OpenWRT for


While the default configuration (i.e. just setting this three options, then running make defconfig, then compiling) compiles fine, the compilation of my custom configuration aborts with an error when trying to link busybox and it is not really clear for me what the origin of the error is.

The, I think, important bits of the output of make are:

  LINK    busybox_unstripped
Trying libraries: crypt m rpc
 Library crypt is not needed, excluding it
 Library m is not needed, excluding it
 Library rpc is needed, can't exclude it (yet)
Final link with: rpc
cc1: note: someone does not honour COPTS correctly, passed 0 times
make[4]: *** [Makefile:717: busybox_unstripped] Error 1

I am building in the following way:

The build was carried out on a git clone, later brought up to date with a git pull, with latest commit from 2018-03-05T10:44:20+01:00, commit hash 5cbd22bb0f.

Into this git clone a previously generated .config seed, made previously by make menuconfig and ./scripts/, was copied over to ./.config.

From there on, the following commands were issued:

./scripts/feeds update -a
./scripts/feeds install -a
make -j1 V=s defconfig
make -j1 V=s download
make -j1 V=s IGNORE_ERRORS=m 2>%1 | tee make.log

(Note: Those commands were already issued earlier, then the build error occured, and for preparing this report I updated to the newest state with git pull and issued the commands again. It made (re)compile faster due to ccache and due to already compiled files present, but might affect the output of make. Just to note if things might be suspicious. The actual error messages just before the build aborts did stay the same.)

The last lines of the make output are:

  CC      util-linux/volume_id/util.o
  CC      util-linux/volume_id/volume_id.o
  AR      util-linux/volume_id/lib.a
  LINK    busybox_unstripped
Trying libraries: crypt m rpc
 Library crypt is not needed, excluding it
 Library m is not needed, excluding it
 Library rpc is needed, can't exclude it (yet)
Final link with: rpc
cc1: note: someone does not honour COPTS correctly, passed 0 times
make[4]: *** [Makefile:717: busybox_unstripped] Error 1
make[4]: Leaving directory '/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45/build_dir/target-mips_24kc_musl/busybox-1.27.2'
make[3]: *** [Makefile:121: /home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45/build_dir/target-mips_24kc_musl/busybox-1.27.2/.built] Error 2
make[3]: Leaving directory '/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45/package/utils/busybox'
make[2]: *** [package/Makefile:108: package/utils/busybox/compile] Error 2
make[2]: Leaving directory '/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45'
make[1]: *** [package/Makefile:102: /home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45/staging_dir/target-mips_24kc_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45'
make: *** [/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/custom-wo-pie_feeds-rooter-custom.2018-02-26_12-04-45/include/ world] Error 2

The toolchain (./staging_dir/toolchain-*) is mips_24kc_gcc-5.5.0_musl.

Build is carried out on an x86_64 Arch Linux machine.

Attached are the following files:

  • .config-diffconfig-seed: The .config-seed used for make defconfig,
  • .config: The .config created by the make defconfig and used for the build,
  • make.log.tail: The last part of the output of make -j1 V=s IGNORE_ERRORS=m 2>%1,
  • make.log.xz: The full output of make -j1 V=s IGNORE_ERRORS=m 2>%1 (.xz compressed; decompresses to about 29 MB)
  • feeds.conf: The feeds.conf used.

What am I doing wrong/ what is going wrong? I am not sure at all if this is indeed a bug in the build system, or something I am doing wrong. (Note: I am not familiar with linker at all.)

(Also note, that there are also previously 47 messages

cc1: note: someone does not honour COPTS correctly, passed 2 times

(see the full make log).)

18.01.20181282KernelBuild FailureVery LowLow"CONFIG_STRIP_KERNEL_EXPORTS" breaks kernel compilation...TrunkUnconfirmed Task Description

Target: brcm2708_bcm2710 (rpi-3)
Affected openwrt revision: git-head (26045049baf646aa2ce3dce78106da5acf4936ea)
(openwrt-17.01 is not affected)

  • Reproducing

git clone ; cd openwrt
make menuconfig
# Select:
# Target: Broadcom BCM27xx
# Subtarget: BCM2710 64 bit based boards
# Global build settings —> Strip unnecessary exports from the kernel image: Enabled
make -j 1 V=s

  • Build log
make -C /home/torte/openwrt/nfs/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710/linux-4.9.76 HOSTCFLAGS="-O2 -I/home/torte/openwrt/nfs/openwrt/staging_dir/host/include  -Wall -Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="aarch64-openwrt-linux-musl-" ARCH="arm64" KBUILD_HAVE_NLS=no KBUILD_BUILD_USER="" KBUILD_BUILD_HOST="" KBUILD_BUILD_TIMESTAMP="Thu Jan 18 10:39:42 2018" KBUILD_BUILD_VERSION="0" HOST_LOADLIBES="-L/home/torte/openwrt/nfs/openwrt/staging_dir/host/lib" CONFIG_SHELL="bash" V=''  cmd_syscalls= KERNELRELEASE=4.9.76 EXTRA_LDSFLAGS="-I/home/torte/openwrt/nfs/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710 -include symtab.h" CC="aarch64-openwrt-linux-musl-gcc" modules
make[5]: Entering directory '/home/torte/openwrt/nfs/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710/linux-4.9.76'
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/
  LDS     arch/arm64/kernel/vdso/
cc1: fatal error: symtab.h: No such file or directory
compilation terminated.
scripts/ recipe for target 'arch/arm64/kernel/vdso/' failed
make[6]: *** [arch/arm64/kernel/vdso/] Error 1
arch/arm64/Makefile:145: recipe for target 'vdso_prepare' failed
make[5]: *** [vdso_prepare] Error 2
  • Details

The option CONFIG_STRIP_KERNEL_EXPORTS adds “-include symtab.h” for all linker script invokations. See openwrt/include/

        EXTRA_LDSFLAGS="-I$(KERNEL_BUILD_DIR) -include symtab.h"

On recent kernels (4.9.x, arm64 build), linker scripts are used to generate “” at the “make modules” stage.
But the file “symtab.h” is generated later (at the install/image generation stage). See openwrt/include/

        touch $$@

As a result, kernel compilation fails.

  • Sidenotes:

- 32bit arm (brcm2708_bcm2708) is not affected, the vdso stuff is generated by normal .c files

- On arm64 4.4 kernels, the vdso stuff is not compiled for reasons, that I don’t know. Anyway, openwrt-17.01 is not affected

20.10.20171091PackagesBuild FailureVery LowLowlibiconv-full undefined reference compile-time linking ...TrunkUnconfirmed Task Description

LEDE Trunk using latest commit fbde9ac718409720a937671f3354837223b5db76
Feeds all using latest trunk sources, though that shouldn't affect this
Target is "x86" Generic (also tried x86_64)
Selected GCC 7 for compiler options
.config is attached

Problem discovered when enabling the 'minidlna' package, which has a dependency on 'libiconv-full' - a core LEDE package.

Compilation fails on 'libiconv-full' with undefined reference errors (linking errors) for objects 'aliases_lookup' and 'aliases2_lookup' in "":

make[5]: Entering directory '/home/jstaehle/prem2/depot/lede/build_dir/target-i386_pentium4_musl/libiconv-1.11.1/src'
/bin/sh ../libtool --mode=link i486-openwrt-linux-musl-gcc -L/home/jstaehle/prem2/depot/lede/staging_dir/target-i386_pentium4_musl/usr/lib -L/home/jstaehle/prem2/depot/lede/staging_dir/target-i386_pentium4_musl/lib -L/home/jstaehle/prem2/depot/lede/staging_dir/toolchain-i386_pentium4_gcc-7.2.0_musl/usr/lib -L/home/jstaehle/prem2/depot/lede/staging_dir/toolchain-i386_pentium4_gcc-7.2.0_musl/lib -znow -zrelro  iconv_no_i18n.o ../srclib/libicrt.a ../lib/ -o iconv_no_i18n
i486-openwrt-linux-musl-gcc -znow -zrelro iconv_no_i18n.o -o iconv_no_i18n  -L/home/jstaehle/prem2/depot/lede/staging_dir/target-i386_pentium4_musl/usr/lib -L/home/jstaehle/prem2/depot/lede/staging_dir/target-i386_pentium4_musl/lib -L/home/jstaehle/prem2/depot/lede/staging_dir/toolchain-i386_pentium4_gcc-7.2.0_musl/usr/lib -L/home/jstaehle/prem2/depot/lede/staging_dir/toolchain-i386_pentium4_gcc-7.2.0_musl/lib ../srclib/libicrt.a ../lib/.libs/ -Wl,--rpath -Wl,/home/jstaehle/prem2/depot/lede/build_dir/target-i386_pentium4_musl/libiconv-1.11.1/lib/.libs
../lib/.libs/ undefined reference to `aliases_lookup'
../lib/.libs/ undefined reference to `aliases2_lookup'
collect2: error: ld returned 1 exit status
Makefile:64: recipe for target 'iconv_no_i18n' failed
make[5]: *** [iconv_no_i18n] Error 1

Full build log is also attached

Tested with a full default configuration and only options enabled being GCC 7 and a modular option for the libiconv-full package, so that should rule out any external influence.

I did find one other reference to this issue on the LEDE forums a few months ago here: LEDE Forums: compilation fails on libiconv-full

12.02.2017503KernelBuild FailureVery LowMediumBuild fails with CONFIG_KERNEL_GIT_CLONE_URI beig setAllAssigned Task Description

When specifying


a clean build fails, as the system assumes a already downloaded/cloned/packed linux-source is present in dl/ which on a freshly checked out openwrt/lede source isn’t the case yet, when


is about to be built.

The build error looks like:

make[3]: Entering directory `/build/lede.git/toolchain/kernel-headers'
zcat /build/lede.git/dl/linux-4.4.42.tar.gz | tar -C /build/lede.git/build_dir/toolchain-arm_cortex-a9+neon_gcc-6.3.0_glibc-2.24_eabi -xf -
gzip: /build/lede.git/dl/linux-4.4.42.tar.gz: No such file or directory
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

The issue apparently is located in


, line 53ff::

  ifeq ($(strip $(CONFIG_KERNEL_GIT_CLONE_URI)),"")
    define Kernel/Prepare/Default
        $(if $(QUILT),touch $(LINUX_DIR)/.quilt_used)
    define Kernel/Prepare/Default

For the package


it just tries to access the not-yet downloaded/cloned/packed linux kernel source archive.

08.01.2017375ToolchainBuild FailureVery LowMediumBulidbots should have multilib support installed to pre...TrunkUnconfirmed Task Description

I’ve run into this earlier myself and now we are seeing at least one package failing because of it.

People seem to have run into this issue before since it’s listed as a requirement for Ubuntu 64-bit as an example.

14.11.20192596Base systemFeature RequestVery LowLowSupport using environment variable CCACHE_DIR to determ...TrunkUnconfirmed Task Description

Right now, the CCACHE_DIR is set unconditionally to ${STAGING_DIR}/ccache.

This is great if you’re going to have a single build tree, but for large team that are working closely together on an OpenWRT based firmware, where multiple development branches might be in use simultaneously, this is wasteful.

At least in my environment, I want to set the ccache directory to be outside of the build tree, so that multiple build trees can share a cache.

Because OpenWRT sets this variable unconditionally, instead of respecting the external environment’s CCACHE_DIR, or even allowing for the path to be set in .config, I have to patch the build tree to set the CCACHE_DIR that I want to use.

14.09.20192494Base systemFeature RequestVery LowVery LowImplement system to allow LuCI to display messages prio...AllUnconfirmed Task Description

Currently there is no system to alert users to possible issues they may encounter when flashing a new image. This has led to certain features being delayed or even withheld (the switch from swconfig → DSA is a good example). Simply put there is no way to alert the average user to configuration breaking changes a new image might make.

A short header that contains important information could be inserted into OpenWrt images. The header is parsed and displayed via LuCI if certain criteria are/aren’t met. This could be something as simple as a image version check or something more complex like configuration and package comparisons.

This is really more of a forward looking feature, but it would allow more drastic changes (changes that cannot be migrated) be made between OpenWrt versions.

11.08.20192437Base systemFeature RequestVery LowMediumAdd algorithm for auto channel selection (ACS)TrunkUnconfirmed Task Description

Apparently OpenWrt currently does not offer an algorithm for auto channel selection of a wireless channel. Instead it just always seems to default to channel 1 if autochannel is activated. This is not the intended behaviour and not what a user expects. So I suggest adding some selection algorithm to it (there is already available at least one, so it should not be too hard to add it).

24.05.20192292KernelFeature RequestVery LowLowSupport AWS ENA NICTrunkUnconfirmed Task Description


it’s possible to provide the ena kernel driver as separat module/package? The latest generation of EC2 requires the usage of ENA and this driver is inside the official linux long time ago.

Kernel Module:

ENA documentation:

11.05.20192278Base systemFeature RequestVery LowVery LowRFE: Replace iptables(legacy) with iptables(nf_tables)TrunkUnconfirmed Task Description

Supported since iptables 1.8:

21.04.20192248PackagesFeature RequestVery LowLowuhttpd: implement ubus event listener via Server-Sent E...TrunkWaiting on reporter Task Description

As a web developer I would benefit from having the possibility to send events from the server to the browser so the browser can react to it dynamically.

The proposed implementation is the leanest possible.

A SSE (Server-Sent Event) is a simple protocol on top of basic http polling to send messages from the http server to the browser for the purpose of instant notifications.
It comes implemented in all major browsers, including mobile.

If paired with `ubus listen` or `ubus monitor`, a seamless integration with the ubus pipeline could be implemented.

We tried to implement it by adding an option in this line of code but got stuck in our lack of corutine mechanisms and how uhttpd works.

The difference with the call and list options is that this one should be long-lived and progressive, preventing the dreaded polling from the web (also, better us of resources, more elegant implementation, etc).

As an example, a very basic implementation of a SSE server in php:

header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');

echo "data: \"hello world\"" . PHP_EOL;
echo PHP_EOL;
echo "data: \"goodbye world\"" . PHP_EOL;
echo PHP_EOL;

An example of a very basic implementation of a SSE client in HTML:

	var source = new EventSource("demo_sse.php");
	source.onmessage = function(event) {
		document.getElementById("result").innerHTML += + "<br>";
21.04.20192247KernelFeature RequestVery LowHighAllwinner H+ Enable wifi xradio-xr819 and soc-audio.AllUnconfirmed Task Description

Openwrt-master and openwrt-18.06.02, lede-18.06.02
Included support for wifi xradio-xr819 and soc-audio - Allwinner H + Xunlong Orange Pi Zero.

Patches are created. It is better if someone from the experts adds to the source code.

Patch openwrt-18.06.02

Patch Openwrt-master

Copy patch dts-add-usb2-usb3-soc_codec-opi_zero-wifi_xradio_xr819_openwrt-18.06.02.patch to <buld-dir Openwrt-master>

patch -p1 < dts-add-usb2-usb3-soc_codec-opi_zero-wifi_xradio_xr819_openwrt-18.06.02.patch

Copy patch dts-add-usb2-usb3-soc_codec-opi_zero-wifi_xradio_xr819_openwrt-master.patch>

patch -p1 < dts-add-usb2-usb3-soc_codec-opi_zero-wifi_xradio_xr819_openwrt-master.patch
21.02.20192138PackagesFeature RequestVery LowLowmwan3-luci: sort order of shown interfaces not like as ...TrunkUnconfirmed Task Description

on current trunk
it hurts, that the ORDER on the mwan3 graphs is different as ORDERED on configuration of mwan3.
is it possible to fix that ?
sorry, i don’T know how i could fix that by myself and to provide a fix for it.

root@router02.dreamteam:/root # opkg list-installed | grep mwan3
luci-app-mwan3 - git-19.043.27122-eda8f02-1
mwan3 - 2.7.10-1

cu Erwin


11.02.20192118OtherFeature RequestVery LowHighRenaming pre-configured firewall-zone names...AllUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
This is a suggestion and is not a model-specific bug report.

- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 18.06.1, r7258-5eb055306f

- Steps to reproduce
Description below:

This is a decade-old suggestion I’ve held within and I really hope the words will gather enough attention and momentum of the dev team. Streight to the conclusion, two pre-configured firewall-zones IMHO should be renamed from “lan” to “internal” and “wan” to “external” respectively. There are a few reasons for which I confidently feel this should be done. I’d like to argue that this is important if not essential because;
a.)Those who prefer making changes to current configurations by editing /etc/config/*, using stuff like “sed -i ‘s/before/after/g’ ${file}” (and then proceeding to reboot) is powerful and is almost mistake-free. checking for config-mistakes using grep is also powerful (and this applies to folks using uci CUI tool as well). What I do now is rename these two zones from GUI and then proceed to these steps, and it works great but having to take this extra step is rather inconvenient if not annoying.
b.)Current presets for interfaces have IPv4-WAN named as “wan” and IPv6-WAN named as “wan6” where the IPv4-WAN‘s label “wan” is no different from the firewalled-zone labeled as “wan”. This is simply comfusing. In early days when I I had just heard about the OpenWrt and had started messing with releases like Kamikaze,I had hard times understanding which string corresponded to which (sure you may argue this is documented in details but things don’t work like that for newbies).
c.)If needs for either firewall-zones or the interface-labels to be renamed are understood, I’d then have to say I’m against renaming interface-labels because those who’d decide to use VLANs would most likely name the interfaces as “config interface ‘vlan_ID’” and the string lan would stay in there.

I hope the above proposal is powerful enough...

30.01.20192093PackagesFeature RequestVery LowMediumThere is 'dslite' but not 'ipip6'?AllUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
This is a suggestion and is not a model-specific bug report.

- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 18.06.1, r7258-5eb055306f

- Steps to reproduce
Description below:

I don't understand why people have not come across this, but I honestly think there should be a package providing users with a generic implementation of IPv4-over-IPv6 tunnel. There is 'dslite' which contains '' but is too specifically optimized for DS-Lite since it has IPv4 addresses of hard-coded. Sure, I could alter these values locally for personal use, but that just doesn't feel right...I find it rather inflexible. I'm not saying 'dslite' should be renamed to 'ipip6' but I do think folks will be happier if there were a separate package named like 'ipip6' implemented with more flexibility. Or am

27.12.20182029PackagesFeature RequestVery LowLowfw3, IPv6: create rules with hostnames instead of dest_...TrunkUnconfirmed Task Description

Currently, opening a port on fw3 to allow a local server to be reached from the Internet via IPv6, requires the hardcoding of the destination IPv6 address in the


option. Here's the example on the fw3 IPv6 Configuration Examples wiki page:

config rule
        option src       wan
        option proto     tcp
        option dest      lan
        option dest_ip   2001:db8:42::1337
        option dest_port 80
        option family    ipv6
        option target    ACCEPT

Having an hardcoded IPv6 address becomes troublesome when the public IPv6 prefix changes. This can happen regularly with some ISPs, forcing users to edit the rule.

It would much helpful if one could specify a destination hostname instead of an IP address. fw3 would then have to check the current leases and translate the hostname.

An hardcoded IP address in the firewall rules was no issue with IPv4, since on most scenarios all destination addresses were local and could be statically attributed on


. IPv6 public prefix delegation changes this and IMO requires more flexible rules on fw3.

This feature request follows the How to set up OpenWrt traffic rule for port forwarding IPv6 server on my LAN? question on SuperUser by James Johnston.

27.12.20182028Base systemFeature RequestVery LowLowIGMP/MLD snooping on WRT3200ACM (88E6352 switch)TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

Linksys WRT3200ACM

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

Latest OpenWRT trunk (as of 2018/12/27)

- Steps to reproduce

I’m askinf for you to add the function so I can enable switch level IGMP and MLD snooping (as the switch supports it )

Currently I have this setup:

    WAN (VLAN 12)
|  SWITCH  |--- LAN1 (VLAN 12)
    CPU (VLAN 12 and others)

In the mencioned LAN1 I have a STB, and my ISP uses IGMP for IPTV.
When the STB is running, the wan interface gets flooded with the stream, not requested by the router, only by the STB, so I’d like to enable IGMP snooping so I can stop this. This is the reason why I dont have the STB in my LAN.


08.12.20181988Base systemFeature RequestVery LowLowusbmode doesn't support HuaweiAltMode from USB_ModeSwit...TrunkUnconfirmed Task Description

USB_ModeSwitch v2.5.1 added a new option called HuaweiAltMode that isn’t present in usbmode yet. It would be great if this could be ported to usbmode as well, please.

13.11.20181948Base systemFeature RequestVery LowLowlibubox and libubus in C++ codeAllUnconfirmed Task Description


we try to develop UBUS and UCI application in C++. For now we are not able to compile our applications without patching ubus and libubox in the following way.

[develict@DCompiler ~]$ tmux att -t 8
--- a/libubus.h
+++ b/libubus.h
@@ -14,6 +14,10 @@
 #ifndef __LIBUBUS_H
 #define __LIBUBUS_H

+#ifdef __cplusplus
+extern "C" {
 #include <libubox/avl.h>
 #include <libubox/list.h>
 #include <libubox/blobmsg.h>
@@ -414,4 +418,8 @@ static inline int ubus_unregister_event_
     return ubus_remove_object(ctx, &ev->obj);

+#ifdef __cplusplus

Is it possible to use this libraries without its patching?


27.10.20181910Base systemFeature RequestVery LowLowAdd Xiaomi Mi Router R3 support to base systemTrunkUnconfirmed Task Description

Please add this device. Files are implemented from Shibajee Roy.
ramips: add Xiaomi Mi Router R3 support

26.10.20181908FlysprayFeature RequestVery LowMediumEditing an Existing Task, At Least the Tags and Title, ...TrunkUnconfirmed Task Description

When posting a feature request for the NETGEAR DM200 on OpenWRT, I have tagged it incorrectly (adding commas in between tags, since I am used to doing this on other systems similar to Flyspray), and then I saw that I cannot edit my own post.
Also, I wanted to fix the title (capitalizing letters where necessary, and likewise, the opposite).

Can editing existing tasks one had authored be possible in the future, or at least improving the tagging system, to enable fixing such mistakes?

26.10.20181907Base systemFeature RequestVery LowLowPossibility of unlocking Gigabit speeds on the Netgear ...TrunkUnconfirmed Task Description

I was wondering if it would be possible to add Gigabit networking to the NETGEAR DM200 by modding the physical connectors, since from what I have seen, the chipset (Lantiq VRX220) supports Gigabit speeds, and there is a firmware which supports such speeds, however the DM200 officially supports only up to 100Mbts speeds.

When taking a look at my DM200’s board, I have noticed that the Ethernet connector only utilizes 4 out of the 8 pins, while the modem connector only utilizes 2 out of the pins, so I was thinking that it may be possible to solder the other pins (as required, of course), we may be able to “upgrade” the DM200 to Gigabit.

If the DM200 can boot properly with the Gigabit-enabled firmware, and this mod is undertaken, does anyone think that anything may come out of this?

30.08.20181825KernelFeature RequestVery LowLowath79 cannot support any responsive partition table sch...TrunkUnconfirmed Task Description

Currently in ath79 the partition table are all defined as fixed partition table in device tree, instead of detecting it dynamically in the kernel.

This makes hardware modding not possible except with the firmware patched (which means that the firmware will thus receive no official support from OpenWRT).

In ar71xx, at least for TP-Link devices, we use some auto-detecting partition table driver to decide the partition table, and usually it can well suite modded hardware.

28.08.20181821Base systemFeature RequestVery LowLowAvoid conf-opkg when package config files hasn't changeTrunkUnconfirmed Task Description


Today, during a package installation, opkg checks if a config file exists in rootfs.
If it does not match hash from package, it saves the new file with a config-opkg suffix.

Would it be possible, during a package update check if the old version hash match and avoid
creating the config-opkg file? Something like:

foreach config
   if old_pkg.hash(config) == new_pkg.hash(config)
   if not fs.exists(config)
   if fs.hash(config) == new_pkg.hash(config)

It would be even better if the /usr/lib/opkg/status somehow could be temporary saved between system upgrades to feed
old_pkg.hash(config) function. If config hashes lived outside status (like inside /usr/lib/opkg/info/pkg.conffiles), one
could simply add these files to backup. old_pkgs.hash will simply read /usr/lib/opkg/info/pkg.conffiles before it is overwritten
by the new version.

12.08.20181769PackagesFeature RequestVery LowMediumEnable built-in RADIUS support for full version of host...TrunkUnconfirmed Task Description

hostapd has built-in RADIUS server and capable to perform EAP authentication without external authenticator. Unfortunately OpenWRT package builds full version of hostapd with internal crypto backend. All functions related to EAP-TLS in internal crypto backend stubbed with empty bodies returning error immediately.

Recently I used FreeRADIUS running directly on my router, but it requires pretty remarkable amount of RAM. I ended up with patch for openwrt build specs in order to build fully functional hostapd. Also I made some ugly hacks in netifd scripts to compose proper hostapd.conf. Finally, I got working EAP-TLS auth virtually with no additional costs.

Probably support for internal RADIUS and some authentication methods should be added to LUCI/UCI configuration interface.

I guess secure WLAN is not a luxury feature and EAP auth is mandatory for modern secure networks.

My device is: TP-Link Archer C50 V1
My current OpenWRT version is: OpenWrt 18.06.0, r7188-b0b5c64c22

09.08.20181756KernelFeature RequestVery LowMediumquantenna chipset supportTrunkUnconfirmed Task Description


At first, thanks for the great work on openwrt !

As you probably already know, quantenna driver are now available on linux wireless

Is there a chance to include this driver on openwrt ? It will be profitable for several routers like netgear r7500 or asus rt-ac87u...


08.08.20181750DocumentationFeature RequestVery LowLowProvide notification channel for release announcementsAllUnconfirmed Task Description

After installing OpenWrt on any device, I have to actively monitor the project website to know whenever a new release is available, potentially fixing security issues with my installation.

I propose creating a release-announce mailinglist used only for that purpose, readable & subscribable for everyone.

There might already be other channels offering more push-like notifications, but I didn’t find any ones that are officially sanctioned thus reliably complete.

06.08.20181744Base systemFeature RequestVery LowMedium6rd - feature request - support subnetAllUnconfirmed Task Description

Depending on the providers deploying 6rd, there might be some subnet id bits available to the user if all of the first 64 bits of the IPv6 are not used.

In the example attached 64 - 28 - 32 = 4 bits are available to define subnets so the end user can use any network prefix from 2a02:1205:5050:7ab0:: to 2a02:1205:5050:7abf::

Currently the lowest prefix is chosen by default, without opportunity to specify the subnet.

The feature would add a new “subnet” field to 6rd, available through UCI and the UI. Appropriate checks are performed regarding the maximum value of the field given the constraints given by the ip6prefixlen and ip4prefixlen.

04.08.20181735Base systemFeature RequestVery LowLowdeprecate pages search optimalityTrunkUnconfirmed Task Description

Currently when searching for just about any technical question, the pages show up in google search before the newer pages that are on the main url. This is confusing and leads to out-of-date information. It should be possible to de-rank without delisting the wiki pages.

18.07.20181670Base systemFeature RequestVery LowLowconsistent naming convention for the imagebuilder.tar.x...AllUnconfirmed Task Description


i have a project/script that downloads imagebuilder and builds a custom OpenWRT firmware for any router. the resulting firmware automatically sets up extroot on any external storage.


the URL for the image builder archive is not easily derivable. see this snippet from my script:



it’s easy to calculate the URL for e.g. (ar71xx generic tl-wr1043nd-v2) because ${TARGET_VARIANT} (i.e. ‘generic’) is part of both the dir path and the filename, but not for e.g. (bcm53xx generic dlink-dir-885l), because in the latter case ${TARGET_VARIANT} is part of the directory structure, but not that of the filename itself.


please make sure that the imagebuilder URL can be consistently calculated from the (arch, variant, device) triplet, either by eliminating the variant also from the dir structure, or by consistently including it in the file name, too.

02.05.20181529Base systemFeature RequestVery LowLowPreserve oem firmware in spare partitionTrunkUnconfirmed Task Description

I’ve been having lots of problems with my WRT1200AC router. The 2.4GHz wifi and ethernet are not working, and no amount of reflashing or resetting seems to help. I’d like to try reverting to the Linksys firmware, but I’m finding that’s not working either (

On the DD-WRT forum I’ve learned that a common “trick” is to keep the official firmware on the spare partition permanently, so that it’s always possible to get back to a clean slate. I definitely regret not doing that. But OpenWRT automatically flashes to the opposite partition.

Could this be changed so that LuCI allows the option of choosing which partition gets written to? It could be an “advanced” option. Perhaps with language like:

* Flash to CURRENT partition (”linux2”), leaving existing alternate partition (”linux1”) as recovery partition
* Flash to ALTERNATE partition (”linux1”), and make current OpenWRT partition (”linux2”) the recovery partition

It would be extra nifty to display what’s on the partitions already as well.

27.04.20181520Base systemFeature RequestVery LowHighCOMFAST CF-E380AC Switch 'VLAN' FeaturesTrunkUnconfirmed Task Description

Currently on LEDE version: LEDE Reboot 17.01.4 r3560-79f57e422d / LuCI lede-17.01 branch (git-17.290.79498-d3f0685)

There is no Switch feature under LUCI menu Network. In other words, I’d like to create a VLAN tagging from the main router(which already has VLAN Switch capabilities) to be able to have VLAN capabilities for multiple WLAN Virtual Interfaces.

Is it possible to do this for this AP?

19.03.20181444KernelFeature RequestVery LowLowActivate CONFIG_ATH9K_HWRNG in Kernel 4.9TrunkUnconfirmed Task Description

Since Linux 4.5, ath9k can be used as a random number generator using ADC register as a source of entropy. It is well-known that insufficient entropy is often a problem on routers and weakens security, using ath9k as a random number generator can greatly boost the available entropy on the routers without the need of additional measures such as haveged.

07.03.20181415Base systemFeature RequestVery LowVery Low[Enhancement] Consider shorter interface-name prefixesTrunkUnconfirmed Task Description

Given that `IFNAMSIZ` is typically 16, there are 15 characters available for an interface name.

OpenWRT prepends a prefix that can be at least 6 characters `gre4t-` as an example.

If one then creates pseudo/virtual-interfaces using VLAN notation, there are only 4 characters available for configuration


As long as this limitation is known, there is no loss of functionality, only utility in the naming. I would have ideally been able to name my tunnels with a more readable indication of where the other endpoint was, for example `portal1` rather than `gt99`.

At some time in the future, shortening these generated prefixes would be welcome. I acknowledge that this likely impacts only a small fraction of advanced users and a change may impact scripts that rely on the generated name.


05.03.20181408Base systemFeature RequestVery LowMediumSeparate device-specific config files in base files & r...AllUnconfirmed Task Description

The redundant config files for other targets in the same arch (e.g. in /etc/, /lib/preinit/, /etc/board.d) can take quite a bit of space (a few of kB after sfs, especially for popular archs like ar71xx). Separating config files into board-specific base-files.ipk packages can be very useful for devices with limited flash space.

Also, it will be much helpful to include an option/script in the image builder for auto-removing comments and white-space in all bash and lua files since this will also be much useful for devices with 4MB flash.

02.03.20181404PackagesFeature RequestVery LowLowRFE : in package "gpsd" init / config : a way to bring ...TrunkUnconfirmed Task Description

FYI, I fixed a build bug in gpsd that allows using gpsd with CANbus / NMEA 2000 : FS#783

Now, it would nice to have a way to initialize the CANbus.

For example, the “8 devices USB2CAN” adapter ( ) needs :

ip link set can0 type can bitrate 250000

... and the CANable adapter ( ) needs :

slcan_attach -w -o -c -s5 /dev/ttyACM0 &

ip link set up slcan0

... after that gpsd can be configured with


... and it should work

27.02.20181394Base systemFeature RequestVery LowLowAdd support for OWE encryptionTrunkUnconfirmed Task Description

The WPA3 standard requires opportunistic wireless encryption (OWE) support (with optional OWE transition) for “open” APs. This is supported by hostapd trunk after enabling CONFIG_OWE and then setting OWE instead of WPA-PSK.

10.12.20171216Base systemFeature RequestVery LowLowkmod-mwlwifi: Driver update to support 802.11r FTTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: WRT1900AC + WRT1900ACS
- Software versions of LEDE release, packages, etc.: TRUNK

Commit 760f7bf1b8af6c899ccb14d47e8b987ed9a62adf on Nov 6th updated the mwlwifi driver to accept and MDIE Beacon parameter from hostapd. I have compiled this version in the 17.01.4 SDK and been running for roughly a month with no issues. Please update the firmware for the next release, if possible.

If there is anything I can provide to help out, please let know!

25.11.20171190Base systemFeature RequestVery LowLowNETGEAR WNDR3800 USB LED trigger not work properly!TrunkAssigned Task Description

When I plug USB device in USB port, USB is working。I can copy data to usb device. The USB LED show green。But when the data is copying to usb device, the usb led do not blink, just is always green. I select usb trigger and select usbport hub1 and port1. It does not blink too. It means trigger dont work.

model: NETGEAR WNDR3800
Firmware Version LEDE Reboot SNAPSHOT r5420-332438b / LuCI Master (git-17.328.04231-802d5b6)
Kernel Version 4.9.63

By the way, my device work properly in 15.05.1 and 14.07. When I flash LEGE, it have been found this problem.

22.11.20171183KernelFeature RequestVery LowLowAdd congestion control for low priority flowsAllUnconfirmed Task Description


It would be nice to include package for alternative congestion control mechanisms.

Especially some application can use tcp_lp (low priroriry) to optimise traffic.
Seems a start altought i need to document myself a bit more concerning ledbat state on linux.


06.11.20171153Base systemFeature RequestVery LowHighConsider security monitoring featuresTrunkUnconfirmed Task Description

I see it as email notification about security events.

Examples of security events:

  • Attempts to bruteforce SSH password.
  • Appear unknown MAC’s in network.
  • Deauthentication attacks on Wi-Fi.

Monitoring is very important part of security.

16.10.20171063ToolchainFeature RequestVery LowLowimagebuilder: show IMAGE_SIZE in `make info`TrunkUnconfirmed Task Description

It would be very handy to know the max image size possible for devices.

Instead of parsing e.g. manually it would be handy to add this capability to all imagebuilders itself.

A Value of 0 could be used as no limitation (as for x86/64).

Showing tasks 1351 - 1400 of 1419 Page 28 of 29<<First - 25 - 26 - 27 - 28 - 29 -

Available keyboard shortcuts


Task Details

Task Editing