|
13.10.2020 | 3383 | Website | Bug Report | Very Low | Medium | luci management webside - network - interface proto MAP... | openwrt-19.07 | Unconfirmed |
Task Description
Supply the following if possible: - Device problem occurs on mt7621 - Software versions of OpenWrt 19.07.03 19.07.04 - Steps to reproduce first: select map-e support on menuconfig Network→map select luci support on menuconfig Luci second: update firmware, and then loggin to 192.168.1.1, network - interface - proto MAP/LW4over6 and error occur when click config apply
|
|
25.06.2017 | 868 | Website | Bug Report | Very Low | Low | Snapshot directory contains stray/obsolete directories | Trunk | Unconfirmed |
Task Description
Please remove obsolete directories in the snapshot directory (packages)
aarch64_armv8-a/ arm_cortex-a53_neon-vfpv4/ arm_cortex-a7/ i386_geode/ powerpc_440/
|
|
02.09.2017 | 997 | Website | Feature Request | Very Low | Low | Implement dark theme (or custom color controls) | Trunk | Unconfirmed |
Task Description
regarding website design: grey text on white background / light blue text on white background
this is a problem in bright viewing environments & LCD panels with poor contrast ratio
Please consider a dark theme option (or custom color controls)
|
|
09.11.2019 | 2586 | Website | Bug Report | Very Low | Low | gnutls_handshake() failed | All | Unconfirmed |
Task Description
i use the openwrt sdk with Ubuntu 18.04.3 LTS to building
When executing “./scripts/feeds update -a && ./scripts/feeds install -a” in that sdk directory
There are some errors:
fatal: unable to access ‘https://git.openwrt.org/openwrt.git/‘: gnutls_handshake() failed: The TLS connection was non-properly terminated. failed.
fatal: unable to access ‘https://git.openwrt.org/feed/packages.git/‘: gnutls_handshake() failed: The TLS connection was non-properly terminated. failed.
fatal: unable to access ‘https://git.openwrt.org/project/luci.git/‘: gnutls_handshake() failed: The TLS connection was non-properly terminated. failed.
fatal: unable to access ‘https://git.openwrt.org/feed/routing.git/‘: gnutls_handshake() failed: The TLS connection was non-properly terminated. failed.
fatal: unable to access ‘https://git.openwrt.org/feed/telephony.git/‘: gnutls_handshake() failed: The TLS connection was non-properly terminated. failed.
but i can git other project in github,so i am sure my git is working
|
|
18.01.2020 | 2749 | Website | Bug Report | Very Low | Low | Cannot find GPG key for 19.07 builds | Trunk | Unconfirmed |
Task Description
I cannot find the GPG used to generate https://downloads.openwrt.org/releases/19.07.0/targets/ath79/generic/sha256sums.asc on a keyserver. Previous releases (such as 18.06.6) are signed with key AD0507363D2BCE9C9E36CEC4FBCB78F015807931, but the key for the 19.07 release is D9C6901F45C9B86858687DFF28A39BC32074BE7A
|
|
24.01.2020 | 2768 | Toolchain | Bug Report | Very Low | High | make_ext4fs: Name-Based UUID leads to collision | Trunk | Unconfirmed |
Task Description
make_ext4fs uses name-based uuid generation (see https://tools.ietf.org/html/rfc4122#section-4.3).
Therefore, as the uuid generation does only depend on the Filesystem Label and an hardcoded namespace, the UUID is exactly identical for multiple different filesystems with the same label (see https://git.openwrt.org/?p=project/make_ext4fs.git;a=blob;f=ext4_utils.c;h=1a886d7e86262d35e30d894f821ca91d32384e96;hb=HEAD#l224).
This can lead to problems like the inability to mount an filesystem by UUID. In my constellation, I have an MMC Storage and an external SD-Card, both flashed with filesystems generated by make_ext4fs. They both have the same UUID, therefore it’s impossible to distinguish/mount them by UUID.
My suggestion would be to replace “info.label” as parameter for “generate_uuid” trough another, better suited value, e.g. an hash of the make_ext4fs directory content. Maybe it should be considered to switch to an Random Number-based UUID (https://tools.ietf.org/html/rfc4122#section-4.4)?
Affected Devices/Targets: All toolchains that use make_ext4fs Revision: make-ext4fs-2020-01-05-5c201be7
|
|
02.11.2020 | 3427 | Toolchain | Bug Report | Very Low | High | ImageBuilder images break Xiaomi Redmi 2100 | Trunk | Unconfirmed |
Task Description
Hi,
I’m building image for my Xiaomi Redmi 2100 using the imagebuilder, but when I flash my router it never comes back and the amber LED is on. I’m building my image this way: make image PROFILE=xiaomi_redmi-router-ac2100 PACKAGES=”luci -luci-proto-ppp wpad-wolfssl iperf3 ethtool mtr iwinfo kmod-tcp-bbr kmod-mtd-rw libustream-wolfssl ca-bundle -ppp -ppp-mod-pppoe -kmod-pppox -kmod-pppoe -kmod-ppp -wpad-basic-wolfssl” I’m using GitHub actions to automate it, you can check the workflow here: https://github.com/amaumene/xiaomi_redmi-router-ac2100_openwrt_mesh/blob/master/.github/workflows/build-openwrt.yml I’ve restored the original firmware and flashed with the latest snapshot from openwrt.org without any issue. The only error that I can see is this “/home/alex/openwrt-imagebuilder-ramips-mt7621.Linux-x86_64/build_dir/target-mipsel_24kc_musl/root-ramips/lib/functions/procd.sh: line 43: /home/alex/openwrt-imagebuilder-ramips-mt7621.Linux-x86_64/build_dir/target-mipsel_24kc_musl/root-ramips/usr/share/libubox/jshn.sh: No such file or directory”
|
|
08.01.2017 | 375 | Toolchain | Build Failure | Very Low | Medium | Bulidbots should have multilib support installed to pre... | Trunk | Unconfirmed |
Task Description
I’ve run into this earlier myself and now we are seeing at least one package failing because of it. https://github.com/openwrt/packages/pull/2823
People seem to have run into this issue before since it’s listed as a requirement for Ubuntu 64-bit as an example. https://wiki.openwrt.org/doc/howto/buildroot.exigence#examples_of_package_installations
|
|
08.05.2017 | 767 | Toolchain | Bug Report | Very Low | Medium | uml: Imagebuilder does not honor default packages for u... | Trunk | Unconfirmed |
Task Description
Stock LEDE - r4099-4c3953b
Plain UML images are fine and work. If you want to build images with the imagebuilder the default package list is not honored and modules are missing - like kmod-80211-hwsim and all related packages.
The squashfs image also does not work:
[ 0.270000] squashfs: SQUASHFS error: Filesystem uses "zlib" compression. This is not supported
profiles.mk in Imagebuilder dir seems wonky:
$ cat .profiles.mk
PROFILE_NAMES = Default
Default_NAME:=Default
Default_PACKAGES:=
.targetinfo looks okay, but I don’t know:
Source-Makefile: target/linux/uml/Makefile
Target: uml
Target-Board: uml
Target-Name: User Mode Linux
Target-Arch: x86_64
Target-Arch-Packages: x86_64
Target-Features: audio ext4 source-only squashfs
Target-Depends:
Target-Optimization: -Os -pipe
CPU-Type:
Linux-Version: 4.4.61
Linux-Release: 1
Linux-Kernel-Arch: um
Target-Description:
@@
Default-Packages: base-files libc libgcc busybox dropbear mtd uci opkg netifd fstools uclient-fetch logd dnsmasq iptables ip6tables ppp ppp-mod-pppoe firewall odhcpd odhcp6c wpad-mini kmod-mac80211-hwsim mkf2fs e2fsprogs iwinfo
|
|
07.08.2018 | 1748 | Toolchain | Bug Report | Very Low | Medium | libgcc_pic.a not autoincluded when building c++ static | Trunk | Unconfirmed |
Task Description
I’m trying to build static C++ code using openwrt toolchain with gcc compiler 7.3.0 for x64 arch. It works fine without “-static” , links against “libgcc_s.so.1” But with “-static” compiler does not link against libgcc_pic.a.
#include <stdio.h>
class CTest
{
public:
CTest()
{
printf("Test\n");
}
~CTest()
{
printf("unTest\n");
}
};
void Test()
{
CTest c;
throw (int)1;
}
int main()
{
try
{
Test();
}
catch(int Test)
{
}
return 0;
}
/lib/../lib64/libstdc++.a(eh_alloc.o): In function `__gnu_cxx::__scoped_lock::~__scoped_lock()':
eh_alloc.cc:(.text._ZN9__gnu_cxx13__scoped_lockD2Ev[_ZN9__gnu_cxx13__scoped_lockD5Ev]+0x4b): undefined reference to `_Unwind_Resume'
/tmp/ccedkPfo.o: In function `Test()':
unwind.cpp:(.text+0x4d): undefined reference to `_Unwind_Resume'
/tmp/ccedkPfo.o: In function `main':
unwind.cpp:(.text+0x6f): undefined reference to `_Unwind_Resume'
/lib/../lib64/libstdc++.a(eh_personality.o): In function `base_of_encoded_value(unsigned char, _Unwind_Context*) [clone .part.3]':
eh_personality.cc:(.text._ZL21base_of_encoded_valuehP15_Unwind_Context.part.3+0x26): undefined reference to `_Unwind_GetDataRelBase'
eh_personality.cc:(.text._ZL21base_of_encoded_valuehP15_Unwind_Context.part.3+0x2c): undefined reference to `_Unwind_GetTextRelBase'
eh_personality.cc:(.text._ZL21base_of_encoded_valuehP15_Unwind_Context.part.3+0x32): undefined reference to `_Unwind_GetRegionStart'
If I include “-lgcc_pic” it compiles OK I think compiler should autoinclude gcc_pic as it does in dynamic build
|
|
14.08.2018 | 1779 | Toolchain | Bug Report | Very Low | Medium | tools/include headers contain old, incomplete versions? | All | Unconfirmed |
Task Description
I tried to add a package that includes <elf.h> on host and this comes from the tools/include files. The build failed because “AT_HWCAP2” was undefined.
After comparing the host distro against tools/include its clear that those files are quite old “1995-2012” vs “1995-2018”. So why do we keep those few headers around in a old version anyway and not use the host headers?
If they are just some old copy’s, than maybe they should at least be updated?
|
|
12.09.2019 | 2492 | Toolchain | Build Failure | Very Low | Medium | When building an image from an imagebuilder the build f... | Trunk | Unconfirmed |
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:
./staging_dir/toolchain-mips_24kc_gcc-8.3.0_musl/mips-openwrt-linux-musl
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
|
|
24.01.2020 | 2774 | Toolchain | Bug Report | Very Low | Medium | imagebuilder breaks in long pwd | openwrt-19.07 | Unconfirmed |
Task Description
I have a directory where I keep imagebuilder. I can sucessfully build custom images there for d-link/dir-825, xiaomi/mini, tp-link/wr842nd_v1 and linksys/wrt1900ac. But trying to create default image for ar71xx/mikrotik gives error:
...
Successfully writed 13 blocks and 1757184 bytes
Each block contain 64 chanks + 0 bytes tail hole.
Each chunk(2112 bytes) consists: data part(2048 bytes) + oob part(64 bytes).
mv: cannot stat '/mydir/openwrt/imagebuilder/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin.new': No such file or directory
make[3]: *** [Makefile:71: /mydir/openwrt/imagebuilder/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 1
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2
It can be reproduced:
% mkdir /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% cd /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% wget https://downloads.openwrt.org/releases/19.07.0/targets/ar71xx/mikrotik/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% tar xf openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% cd openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64
% make image PROFILE=nand-large
...
1671656 bytes (1.7 MB, 1.6 MiB) copied, 0.00693055 s, 241 MB/s
Can't get lstat from kernel file!: No such file or directory
make[3]: *** [Makefile:71: /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 255
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2
zsh: exit 2 make image PROFILE=nand-large
|
|
03.04.2020 | 2957 | Toolchain | Bug Report | Very Low | Medium | openwrt 19.07 x86_64 sdk toolchain segmentation fault i... | openwrt-19.07 | Unconfirmed |
Task Description
Hi guys:
I found that the toolchain of openwrt 19.07 has some issues on x86_64 platform.
For example: 1. I use this sdk to build openwrt-shadowsocks 2. Install the compiled ipk, run the command `ss-local`, will report a `segmentation fault` error.
This error only occurs on openwrt 19.07 x86_64 platform. 19.07 toolchain on other platforms does not have this error, and the 18.06 version of the toolchain on the x86_64 platform also has no such errors.
|
|
13.07.2020 | 3232 | Toolchain | Bug Report | Very Low | Medium | numpy: build error with ar770 compiler | Trunk | Unconfirmed |
Task Description
Recently, numpy was added to the packages feed. https://github.com/openwrt/packages/pull/12404 https://github.com/openwrt/packages/pull/12590
Some builds needed to be disabled like for MIPS, because it doesn’t compile well with musl-libc and soft-float. With MIPS hard-float numpy builds.
In any case, there’s a recent build failure with arc770: https://github.com/openwrt/packages/issues/12774
This looks like a compiler bug.
|
|
23.12.2020 | 3529 | Toolchain | Build Failure | Very Low | Medium | OpenWRT 19.07 don't build on Linux Mint 20 | openwrt-19.07 | Unconfirmed |
Task Description
- Device problem occurs on ath79(tiny) architecture - Software versions of OpenWrt/LEDE release, packages, etc. 19.07.5 - Steps to reproduce: ./scripts/feeds update -a && ./scripts/feeds install -a make defconfig make menuconfig make download make -j9 V=s Attached Files on links: 1) Full build log on compile; 2) My system configuration.
What should I do to overcome this problem?
|
|
16.10.2017 | 1063 | Toolchain | Feature Request | Very Low | Low | imagebuilder: show IMAGE_SIZE in `make info` | Trunk | Unconfirmed |
Task Description
It would be very handy to know the max image size possible for devices.
Instead of parsing e.g. https://lede-project.org/toh/start 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).
|
|
08.10.2018 | 1886 | Toolchain | Bug Report | Very Low | Low | builtin_memcmp(a,b,c) != 0 not used on mips with -Os or... | Trunk | Unconfirmed |
Task Description
Supply the following if possible: - Device problem occurs on
mips, probably everything except x86_64.
- Software versions of OpenWrt/LEDE release, packages, etc.
18.06.1
- Steps to reproduce
Well, the simple way is to cross compile anything that uses a pattern like memcmp(a,b,c) != 0 // (or = and count up the memcmps via objdump.
The != or == pattern gets substituted for a string of xors and a final or, which is way faster than memcmp can ever be. It was added to gcc 7.
I was building the babel daemon and wondering why my x86_64 compiler was doing the right thing but not the mips compiler of the same era.
memcmp is pretty expensive for 16 byte (ipv6 prefixes) compares especially when you only care about equal or not equal. Code’s usually smaller too. Nothing faster than xor exists.
|
|
25.02.2020 | 2860 | Toolchain | Bug Report | Very Low | Low | tools/firmware-utils/mkcameofw not found | Trunk | Unconfirmed |
Task Description
Attempting to produce a factory.bin for the hardware identical devices D-Link DIR-810L and Trendnet TEW-810DR. In order to flash over the factory image, a short tag needs to be appended to firmware image. See the device pages: ]https://openwrt.org/toh/d-link/dir-810l?s[]=810l]
[[https://openwrt.org/toh/trendnet/trendnet_tew-810dr_1.0_1.1?s[]=tew&s[]=810dr
Both pages use a tool that is provided in both the D-Link and Trendnet GPL source download for the respective device. I can confirm that one cannot flash over the factory image on the Trendnet without appended tag.
I found a prior mailing of someone needing to accomplish the same task and the respondent complained about the lack of documentation. The submitter wrote his own. https://jmomo.net/files/lede/patch_sets/v16-0002-ipq806x-Add-support-for-new-device-tew827dru.patch
I attempted to use mkcameofw/cameofw in a git pull versioned to 19.07.1 and the build error out, unable to find tool mkcameofw/cameofw.
A couple of points:
1. mkcameofw seems to be broken and unused. Both the device pages describe the use of GPL‘d ncc_att_hwid after the build for the initial install.
2. I’ve searched for the documentation for ncc_att_hwid and cameo signature and only came up with it being applied in OpenWRT/DD-wrt.
3. Users are working around the broken code manually.
4. ncc_att_hwid is GPL‘d and could be included in the build tree.
5. The respective cameo signatures can be seen in the hex output of the D-Link and Trendnet firmware.
6. If the project could either adapt ncc_att_hwid or the previously submitted tool, factory flash bins could be produced for several devices.
|
|
16.07.2020 | 3234 | Toolchain | Bug Report | Very Low | Low | 19.07.2 imagebuilder does not work with (detect) gcc 10... | openwrt-19.07 | Unconfirmed |
Task Description
Imagebuilder is unable to detect gcc/g++ on my system running gcc 10.1 FORCE=1 makes no difference, and seems to be ignored.
[naguz@blaptop openwrt-imagebuilder-19.07.2]$ make image FORCE=1 PROFILE=tplink_archer-c7-v2 FILES=files/
Checking 'working-make'... ok.
Checking 'case-sensitive-fs'... ok.
Checking 'proper-umask'... ok.
Checking 'gcc'... failed.
Checking 'working-gcc'... ok.
Checking 'g++'... failed.
Checking 'working-g++'... ok.
Checking 'ncurses'... ok.
Checking 'perl-thread-queue'... ok.
Checking 'tar'... ok.
Checking 'find'... ok.
Checking 'bash'... ok.
Checking 'patch'... ok.
Checking 'diff'... ok.
Checking 'cp'... ok.
Checking 'seq'... ok.
Checking 'awk'... ok.
Checking 'grep'... ok.
Checking 'getopt'... ok.
Checking 'stat'... ok.
Checking 'unzip'... ok.
Checking 'bzip2'... ok.
Checking 'wget'... ok.
Checking 'perl'... ok.
Checking 'python3-cleanup'... ok.
Checking 'python'... ok.
Checking 'git'... ok.
Checking 'file'... ok.
Checking 'ldconfig-stub'... ok.
Build dependency: Please install the GNU C Compiler (gcc) 4.8 or later
Build dependency: Please install the GNU C++ Compiler (g++) 4.8 or later
Prerequisite check failed. Use FORCE=1 to override.
make[1]: *** [Makefile:87: staging_dir/host/.prereq-build] Error 1
make: *** [Makefile:197: image] Error 2
[gert@blad openwrt-imagebuilder-19.07.2]$
|
|
03.11.2020 | 3432 | Toolchain | Bug Report | Very Low | Low | fakeroot: segmentation fault | Trunk | Unconfirmed |
Task Description
Try to compile the vim package using the current snapshot SDK openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64. The compilation fails with a segmentation fault within fakeroot.
Steps to reproduce:
-
./scripts/feeds install -a
./scripts/feeds update -a
make menuconfig # disable building ALL packages
make -j1 V=s package/vim/download
make -j1 V=s package/vim/compile
make -j1 V=s package/vim/prepare
Output:
make[1]: Entering directory '/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64'
make[2]: Entering directory '/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/feeds/base/package/libs/ncurses'
find /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/hostpkg/ncurses-6.2 -mindepth 1 -maxdepth 1 -not '(' -type f -and -name '.*' -and -size 0 ')' | xargs -r rm -rf
make[2]: Leaving directory '/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/feeds/base/package/libs/ncurses'
time: package/feeds/base/ncurses/host-compile#0.14#0.14#0.24
make[2]: Entering directory '/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/package/toolchain'
Makefile:762: WARNING: skipping libgomp -- package has no install section
mkdir -p /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/bin/targets/mxs/generic/packages /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc/CONTROL /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/target-arm_arm926ej-s_musl_eabi/pkginfo
install -d -m0755 /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc/lib
cp -fpR /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/toolchain-arm_arm926ej-s_gcc-8.4.0_musl_eabi/lib/libgcc_s.so.* /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc/lib/
find /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf
export CROSS="arm-openwrt-linux-muslgnueabi-" NO_RENAME=1 ; NM="arm-openwrt-linux-muslgnueabi-nm" STRIP="/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/host/bin/sstrip" STRIP_KMOD="/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/scripts/strip-kmod.sh" PATCHELF="/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/host/bin/patchelf" /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/scripts/rstrip.sh /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc
rstrip.sh: /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc/lib/libgcc_s.so.1: shared object
(cd /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc/CONTROL; ( echo "$CONTROL"; printf "Description: "; echo "$DESCRIPTION" | sed -e 's,^[[:space:]]*, ,g'; ) > control; chmod 644 control; ( echo "#!/bin/sh"; echo "[ \"\${IPKG_NO_SCRIPT}\" = \"1\" ] && exit 0"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_postinst \$0 \$@"; ) > postinst; ( echo "#!/bin/sh"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_prerm \$0 \$@"; ) > prerm; chmod 0755 postinst prerm; )
install -d -m0755 /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/bin/targets/mxs/generic/packages
/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/host/bin/fakeroot /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/scripts/ipkg-build -m "" /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/build_dir/target-arm_arm926ej-s_musl_eabi/toolchain/ipkg-arm_arm926ej-s/libgcc /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/bin/targets/mxs/generic/packages
/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/staging_dir/host/bin/fakeroot: line 185: 66480 Segmentation fault (core dumped) FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"
make[2]: *** [Makefile:764: /home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/bin/targets/mxs/generic/packages/libgcc1_8.4.0-2_arm_arm926ej-s.ipk] Error 139
make[2]: Leaving directory '/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/package/toolchain'
time: package/toolchain/compile#0.18#0.13#0.34
make[1]: *** [package/Makefile:114: package/toolchain/compile] Error 2
make[1]: Leaving directory '/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64'
make: *** [/home/mpranj/Downloads/openwrt-sdk-mxs_gcc-8.4.0_musl_eabi.Linux-x86_64/include/toplevel.mk:229: package/vim/compile] Error 2
|
|
06.03.2018 | 1414 | Toolchain | Build Failure | Very Low | Very Low | mbedtls: building with ccache: /staging_dir/host/bin/cc... | Trunk | Unconfirmed |
Task Description
I am currently trying to compile OpenWRT for
CONFIG_TARGET_LANTIQ=Y
CONFIG_TARGET_LANTIQ_XWAY=Y
CONFIG_TARGET_lantiq_xway_DEVICE_arcadyan_arv752dpw22=y
I am using
CONFIG_DEVEL=y
CONFIG_CCACHE=y
I am building in the following way:
The build was carried out on a git clone git://github.com/openwrt/openwrt.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/diffconfig.sh , 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'
Usage:
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,
-
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.)
|
|
11.05.2018 | 1543 | Packages | Build Failure | Very Low | Critical | Many packages in snapshot failing on one build, ok on n... | Trunk | Unconfirmed |
Task Description
Snapshot/Packages 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 https://github.com/openwrt/packages 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.
|
|
28.02.2020 | 2868 | Packages | Bug Report | Very Low | Critical | CLAT/464XLAT stopped working in 19.07.1 | openwrt-19.07 | Unconfirmed |
Task Description
I was using CLAT in an Archer C7 v5 for some testing. Everything worked fine.
I decided then to upgrade to 19.07.1 and everything works fine from the backup that I did from the config, but not the CLAT (464XLAT).
I decided to reflash the unit from scratch and configure everything manually. Same problem, CLAT is not working. I tried even setting the tunnel link to the WAN interface manually in the CLAT interface (advanced settings), instead of the default “unspecified”, played with the firewall settings as well, etc. Nothing resulted.
By the way, even in 18.06.7, which I’m using right now with the CLAT, the CLAT interface doesn’t report any RX/TX or packets. In the same router I’ve installed Collectd and I can see there the traffic being graphed correctly.
So I’m guessing there is some bug there. I’m going to report it as a bug, but just in case someone discovered an easy solution.
I’ve observed that at some point, across numerous tests, a Virtual dynamic interface 464XLAT was created, but it doesn’t allow to edit it, so not sure if this is related. I believe this interface is only created when I’m using PPPoE for the WAN link (I’ve tested 2 scenarios, PPPoE done in the OpenWRT box and PPPoE done in the GPON ONT).
|
|
06.05.2020 | 3067 | Packages | Bug Report | Very Low | Critical | download board.bin failure | openwrt-19.07 | Unconfirmed |
Task Description
make[3]: Entering directory '/home/leo/openwrt/package/firmware/ath10k-ct-firmware'
mkdir -p /home/leo/openwrt/dl
SHELL= flock /home/leo/openwrt/tmp/.ath10k-firmware-d622d160e9f552ead68d9ae81b715422892dc2ef-qca9887-board.bin.flock -c ' /home/leo/openwrt/scripts/download.pl "/home/leo/openwrt/dl" "ath10k-firmware-d622d160e9f552ead68d9ae81b715422892dc2ef-qca9887-board.bin" "cf4df099f6ee05c181f55ce17297a1d32c61d725eb96246fd315ad5587c42426" "board.bin" "@GITHUB/kvalo/ath10k-firmware/d622d160e9f552ead68d9ae81b715422892dc2ef/QCA9887/hw1.0" '
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://sources.cdn.openwrt.org/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0
curl: (22) The requested URL returned error: 404
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://raw.githubusercontent.com/kvalo/ath10k-firmware/d622d160e9f552ead68d9ae81b715422892dc2ef/QCA9887/hw1.0/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://raw.githubusercontent.com/kvalo/ath10k-firmware/d622d160e9f552ead68d9ae81b715422892dc2ef/QCA9887/hw1.0/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://raw.githubusercontent.com/kvalo/ath10k-firmware/d622d160e9f552ead68d9ae81b715422892dc2ef/QCA9887/hw1.0/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://raw.githubusercontent.com/kvalo/ath10k-firmware/d622d160e9f552ead68d9ae81b715422892dc2ef/QCA9887/hw1.0/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://raw.githubusercontent.com/kvalo/ath10k-firmware/d622d160e9f552ead68d9ae81b715422892dc2ef/QCA9887/hw1.0/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://sources.openwrt.org/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location --insecure https://mirror2.openwrt.org/sources/board.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found
Download failed.
|
|
11.01.2021 | 3570 | Packages | Bug Report | Very Low | Critical | mac80211/ath9k crash | Trunk | Unconfirmed |
Task Description
- Device problem occurs on mac80211/ath9k - Software versions: OpenWrt SNAPSHOT, r15475-c625c821d1 - Steps to reproduce install kmod-ath9k. Oops occurs after association with AP
this is on my alix/x86 board with an Qualcomm Atheros AR922X Wireless Network Adapter
this is possibly related to commit mac80211: replace legacy minstrel with minstrel_ht, improve rate selection
sometimes the device reboots. if the device doesn’t boot, the wifi link is still functional and ping works
|
|
03.08.2017 | 948 | Packages | Bug Report | Very Low | High | lua: on 64bit targets integer number truncation may occ... | All | Unconfirmed |
Task Description
On 64bit target implementations (eg x86_64) and with LNUM on int32 mode (default), assignation of an integer number greater than UINT_MAX (ie 4294967295), but lesser or equal than UINT_MAX + 0x7FFFFFFF + 1 (ie 6442450943) to a variable does result in truncation of the final value stored in memory.
E.g.:
> n=4294967296; print(n)
0
> n=6442450943; print(n)
2147483647
Cause: LNUM does perform a C-Style cast in the intermediate function wrapper used to check for the fitness of numbers. This cast is not only unnecessary but also brings on undefined behaviour on 64bit target implementations where INT’s and LONG’s are of size 32 and 64bit respectively.
Fix: Removal of the unnecessary cast in wrapper does bring back the ‘overflow detection’.
Regards, Víctor Calvís.
|
|
19.10.2017 | 1076 | Packages | Bug Report | Very Low | High | Bugs about QCA9886 | All | Waiting on reporter |
Task Description
Supply the following if possible: - Device problem occurs on archer-c58-v1 - Software versions of LEDE release is the latest master version, and other versions have same bug.
I noticed the memory is leaking after connected serveral devices with QCA9886,
that will cause system crash in the end. Before leaking, WIFI can work fine, but when memory is leaking, WIFI can not work anymore.
My OS is latest lede(mac80211 version is backports-2017-10-06),
and the board can work with QSDK.
If you need more detail information, please let me know.
|
|
19.02.2018 | 1374 | Packages | Bug Report | Very Low | High | ubox: logd memory leak | All | Unconfirmed |
Task Description
I checked the use of memory with `top` command and saw that the logd was consuming memory disproportionately (around 60MB).
``` PID PPID USER STAT VSZ VSZ %CPU COMMAND 971 1 root S 59768 48% 0% /sbin/logd -S 64 ```
- There was no remote log configured. - I was using logread -f for a long time. - When doing an /etc/init.d/log restart the consumed memory returned to normality. - ubox version:
``` PKG_SOURCE_DATE:=2017-09-01 PKG_SOURCE_VERSION:=b1bc8d5fb874cdd22701a08d0fb0de4330f86814 PKG_MIRROR_HASH:=b07e750d941d691e2745aa3a058e504966b15d1db5636162dc686bad275eb296 ```
|
|
19.06.2019 | 2330 | Packages | Bug Report | Very Low | High | Samba - smb.conf templating allows arbitrary injections... | All | Unconfirmed |
Task Description
First, I have to say I’m not 100% sure it is something to be addressed within samba package itself, so forgive me if this is something you have already evaluated as not being an issue.
In short, something like that works:
[…]
option workgroup 'WORKGROUP\
security = share\
guest account = root\
interfaces = lo br-lan\
\
[ohnonotagain]'
I’m not sure this works in plain openwrt images, but there exists a widely deployed commercial fork of openwrt which is definitely vulnerable to some exploit chain involving this one in the middle. You could argue that the right of modifying uci config already gives an equivalent authorization level, or this should have been sanitized at user interface. So, is this something you consider safe?
|
|
09.01.2020 | 2720 | Packages | Build Failure | Very Low | High | libcap compile failure at tests step | Trunk | Unconfirmed |
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
|
|
26.04.2020 | 3051 | Packages | Bug Report | Very Low | High | UPnP not working | All | Unconfirmed |
Task Description
Device: Linksys WRT1900ACSv2 Software versions: v19.07.9 and v19.07.2 Current Openwrt firmware: OpenWrt SNAPSHOT r13046-df27e949fb / LuCI Master git-20.113.57176-dc1d2ce Affected Packages: miniupnpd, luci-app-upnp
I have flashed two versions of OpenWrt v19.07.2, one compiled by myself and the other using the official stable release from the website. On both versions I have then installed the latest version of the LuCI-app-UPnP which includes the miniupnpd daemon.
The problem is UPnP seems to very intermittent of how it picks up the ports from the devices. Some devices and applications show up under the `Active UPnP Redirects` and some don’t at all. My primary testing device is my Sony PS3 and PS4 which requires UPnP to open up ports for an optimal online gaming experience. A common port that I reply on is UDP 3074 that is used by Call of Duty games to achieve open NAT type.
When I was running OpenWrt v18.06.5 at the time in 2019 everything worked perfectly including UPnP. When v19.07.0 was officially released for stable use, I noticed I was getting moderate NAT type within my games. With this in mind I checked the luci-upnp app and noticed that my PS4’s IP address/hostname and the corresponding UDP 3074 was not listed. Sometimes I could get the PS4 to be picked up via the Sony PlayStation network test which would open up UDP port 9308 on LuCI-app-UPnP.
I have opened a couple of OpenWrt forum threads discussing UPnP not working:
The only working version of miniupnpd/luci-app-upnp seems to be miniupnpd 2.1-1 which I have had working on all the v19.07.* firmwares. OpenWrt v19.07.0 shipped with miniupnpd 2.1.20190408-2 and this was the point where it broke. Recently testing with the newer v19.07.2 firmware the miniupnpd has been updated to version 2.1.20191006 and this is the same story whereby the PS3/PS4 can’t be picked up.
Interestingly I did some experimenting and took the files, patches and makefile from the master trunk, replaced `PKG_VERSION:-2.1.20191006` with `PKG_VERSION:-2.1.20200329` in the `makefile` (which is the very latest version of the MiniUPnP daemon source code found at https://miniupnp.tuxfamily.org/files), compiled v19.07.2 and flashed it to my router. I then did a Sony PlayStation network test on my PS4 and UDP port 9308 was listed under `Active UPnP Redirects`. I then proceeded onto Call of Duty Modern Warfare (2019) and UDP port 3074 also appeared! However, I still had moderate NAT type which meant the firewall wasn’t opening up somewhere. After clicking the `Delete` button on the LuCI UPnP page and opening the port manually on the firewall the game did give me open NAT type as expected. Weirdly though, the UPnP listing came back which has never happened any time I’ve used OpenWrt with manual port forwards. In other words if I open a port manually in the firewall UPnP will never list same port and destination device in the `Active UPnP Redirects` list.
|
|
18.07.2020 | 3237 | Packages | Build Failure | Very Low | High | umdns: fails to compile with gcc10 | Trunk | Unconfirmed |
Task Description
Try to compile umdns with gcc10 and it will break with following error:
service.c:240:10: error: ‘strcpy’ offset 6 from the object at ‘b’ is out of the bounds of referenced subobject ‘name’ with type ‘uint8_t[]’ {aka ‘unsigned char[]’} at offset 6 [-Werror=array-bounds]
More detailed error: https://github.com/berlin-open-wireless-lab/DAWN/issues/109#issuecomment-657483908
|
|
11.08.2020 | 3281 | Packages | Bug Report | Very Low | High | dnsmasq: option nonwildcard=0 and localservice=1 can no... | Trunk | Unconfirmed |
Task Description
Latest snapshot OpenWrt
It can be reproduced on many platform, you can just verify with Virtualbox and x86 images.
First restore to factory, then set ‘option nonwildcard=0’, reboot, ssh to OpenWrt, run ‘nslookup he.net’, you will get ‘;; connection timed out; no servers could be reached’ error, manually restarting dnsmasq service or setting ‘option localservice=0’ could fix it.
|
|
31.08.2020 | 3313 | Packages | Build Failure | Very Low | High | ath79/mikrotik: initramfs image is missing the nand-uti... | Trunk | Unconfirmed |
Task Description
The initramfs-kernel.bin image for the ath79/mikrotik mikrotik,routerboard-sxt-5nd-r2 device (SXT Lite 5) is missing the nand-utils package. Therefore, when booting via TFTP (e.g., to install OpenWrt for the first time), the sysupgrade image can not be flashed:
[...] successful boot from TFTP, sysupgrade image uploaded via SCP
root@OpenWrt:/# cat /tmp/sysinfo/board_name
mikrotik,routerboard-sxt-5nd-r2
root@OpenWrt:/# ls -la /usr/sbin/nand*
ls: /usr/sbin/nand*: No such file or directory
root@OpenWrt:/# sysupgrade -v -n /tmp/openwrt-ath79-mikrotik-mikrotik_routerboar
d-sxt-5nd-r2-squashfs-sysupgrade.bin
Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=3
- watchdog -
killall: telnetd: no process killed
Sending TERM to remaining processes ... hostapd wpa_supplicant netifd odhcpd ntpd dnsmasq ubusd urngd logd
Sending KILL to remaining processes ...
Performing system upgrade...
Unlocking kernel ...
Erasing kernel ...
/lib/upgrade/do_stage2: line 25: nandwrite: not found
tar: write error: Broken pipe
removing ubiblock0_1
[ 301.377800] block ubiblock0_1: released
Volume ID 0, size 19 LEBs (2451456 bytes, 2.3 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "none", alignment 1
Volume ID 1, size 21 LEBs (2709504 bytes, 2.5 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1
Set volume size to 119734272
Volume ID 2, size 928 LEBs (119734272 bytes, 114.1 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs_data", alignment 1
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 303.837785] reboot: Restarting systemt
�
so the device can’t boot, as nothing has been written to NAND.
|
|
23.09.2020 | 3358 | Packages | Bug Report | Very Low | High | iwinfo.scan ubus call failed with latest uhttpd | Trunk | Unconfirmed |
Task Description
With latest uhttpd package (2020-09-18), the wireless scan failed in our MT7688 devices (ramps mt76x8). The original uhttpd (2020-08-05-212f8364) version works before.
The iwinfo.scan is using the nobatch=true flag when calling rpc.declare (luci/modules/luci-base/htdocs/luci-static/resources/network.js:83)
|
|
14.05.2017 | 783 | Packages | Bug Report | Very Low | Medium | gpsd doesn't work with "Garmin USB binary" (nor NMEA200... | Trunk | Unconfirmed |
Task Description
Supply the following if possible:
- Device problem occurs on
I tried it on GL-AR150, but it should reproduce on any device w/ USB
- Software versions of LEDE release, packages, etc.
LEDE 17.01.1 gpsd 3.16-1
- Steps to reproduce
If you have a device with “Garmin USB binary” (eg : eTrex), then
gpsd -n -N -G -D 4 /dev/ttyUSB0
... should show data once a second.
From my reading of the code, even without a Garmin device, “-D 4” debug level should show a message of “Probing Garmin USB binary driver...\n”
From my reading of the code, it looks a a build problem. 2 “defines” need to be made :
NON_NMEA0183_ENABLE
HAVE_LIBUSB
FYI, there is a similiar bug for “NMEA2000” : If you do “gpsd -h”, you should see “NMEA2000” on the list of “drivers”. I can file a separate bug for this if you want.
Thanks !
|
|
25.05.2017 | 803 | Packages | Bug Report | Very Low | Medium | NL80211_STA_INFO_INACTIVE_TIME incorrect value for IB... | Trunk | Unconfirmed |
Task Description
- ar71xx affected - latest LEDE trunk affected and may be older versions - Steps to reproduce
Buid current LEDE trunk with a10k-ct driver and CT firmware for QCA988x. Flash devices with firmware. Create IBSS interface for 2 or more ath10k devices and connect them.
iwinfo shows negative value for last activity. Value is rising. TX traffic can’t pass through interface. All incoming packets come with “unknown” bitrate.
root@LEDE:~# iwinfo mesh5_0 assoclist 84:16:F9:B1:A0:3E -39 dBm / -103 dBm (SNR 64) -230820 ms ago
RX: unknown 794 Pkts.
TX: 6.0 MBit/s 0 Pkts.
root@LEDE:~# iwinfo mesh5_0 assoclist 84:16:F9:B1:A0:3E -39 dBm / -103 dBm (SNR 64) -127810 ms ago
RX: unknown 2828 Pkts.
TX: 6.0 MBit/s
0 Pkts.
root@LEDE:~# iwinfo mesh5_0 assoclist 84:16:F9:B1:A0:3E -40 dBm / -103 dBm (SNR 63) -117860 ms ago
RX: unknown 3022 Pkts.
TX: 6.0 MBit/s 0 Pkts.
According to iw output this value is close to th “unsigned long” value limit root@LEDE:~# iw mesh5_0 station dump Station 18:a6:f7:3e:b4:de (on mesh5_0)
inactive time: 4294805756 ms
rx bytes: 152352
rx packets: 2208
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
rx drop misc: 0
signal: -39 dBm
signal avg: -37 dBm
tx bitrate: 6.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
short slot time:yes
connected time: 113 seconds
root@LEDE:~# iw mesh5_0 station dump Station 18:a6:f7:3e:b4:de (on mesh5_0)
inactive time: 4294878176 ms
rx bytes: 250056
rx packets: 3624
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
rx drop misc: 0
signal: -40 dBm
signal avg: -39 dBm
tx bitrate: 6.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
short slot time:yes
connected time: 185 seconds
After some time (3-5 minutes) the value overflows and starting from zero with normal values.
root@LEDE:~# iwinfo mesh5_0 assoclist 84:16:F9:B1:A0:3E -38 dBm / -103 dBm (SNR 65) 80 ms ago
RX: unknown 5732 Pkts.
TX: 6.0 MBit/s 0 Pkts.
root@LEDE:~# iw mesh5_0 station dump Station 18:a6:f7:3e:b4:de (on mesh5_0)
inactive time: 50 ms
rx bytes: 399372
rx packets: 5788
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
rx drop misc: 0
signal: -41 dBm
signal avg: -39 dBm
tx bitrate: 6.0 MBit/s
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 0
beacon interval:100
short slot time:yes
connected time: 296 seconds
|
|
22.12.2017 | 1238 | Packages | Bug Report | Very Low | Medium | curl: https request returns 'Illegal instruction' | Trunk | Unconfirmed |
Task Description
Environment:
root@LEDE:~# cat /etc/os-release
NAME="LEDE"
VERSION="17.01.4, Reboot"
ID="lede"
ID_LIKE="lede openwrt"
PRETTY_NAME="LEDE Reboot 17.01.4"
VERSION_ID="17.01.4"
HOME_URL="http://lede-project.org/"
BUG_URL="http://bugs.lede-project.org/"
SUPPORT_URL="http://forum.lede-project.org/"
BUILD_ID="r3560-79f57e422d"
LEDE_BOARD="mpc85xx/generic"
LEDE_ARCH="powerpc_8540"
LEDE_TAINTS="no-all"
LEDE_DEVICE_MANUFACTURER="LEDE"
LEDE_DEVICE_MANUFACTURER_URL="http://lede-project.org/"
LEDE_DEVICE_PRODUCT="Generic"
LEDE_DEVICE_REVISION="v0"
LEDE_RELEASE="LEDE Reboot 17.01.4 r3560-79f57e422d"
Description:
I’m using oficial stable release for TP-Link TL-WDR4900 v1 and when I try to use curl I give the following error:
root@LEDE:~# curl https://google.com
Illegal instruction
I have installed all curl dependencies and ca-certificates:
root@LEDE:~# opkg list-installed | egrep "ssl|curl|mbed|ddns"
curl - 7.52.1-6
ddns-scripts - 2.7.6-13
ddns-scripts_cloudflare.com-v4 - 2.7.6-13
libcurl - 7.52.1-6
libmbedtls - 2.6.0-1
libopenssl - 1.0.2n-1
luci-app-ddns - 2.4.8-2
openvpn-openssl - 2.4.4-2
And wget works well:
root@LEDE:~# wget https://google.com
--2017-12-18 13:25:10-- https://google.com/
Resolving google.com... 178.60.128.37, 178.60.128.42, 178.60.128.20, ...
Connecting to google.com|178.60.128.37|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.google.es/?gfe_rd=cr&dcr=0&ei=prM3Wp3qOeGs8wfNpI_gDg [following]
--2017-12-18 13:25:10-- https://www.google.es/?gfe_rd=cr&dcr=0&ei=prM3Wp3qOeGs8wfNpI_gDg
Resolving www.google.es... 172.217.21.67, 2a00:1450:4006:807::2003
Connecting to www.google.es|172.217.21.67|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html'
index.html [ <=> ] 12.82K 81.4KB/s in 0.2s
2017-12-18 13:25:11 (81.4 KB/s) - 'index.html' saved [13132]
There is an issue with `curl - 7.52.1-6`?
|
|
30.03.2018 | 1463 | Packages | Bug Report | Very Low | Medium | netifd disagrees with static route documentation | Trunk | Unconfirmed |
Task Description
https://openwrt.org/docs/guide-user/network/routes_configuration says, of the static route “gateway” configuration variable, “If omitted, the gateway from the parent interface is taken; if set to 0.0.0.0 no gateway will be specified for the route”. However, netifd HEAD does not distinguish all zeros from unset. In particular, https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-ip.c;h=1c84d4f8afed8bbe8af9fcc868fb1472b048019d;hb=HEAD#l343 is the only place where ROUTE_GATEWAY is decoded from a blob message and will leave route→nexthop all zeros if none is provided:
343 if ((cur = tb[ROUTE_GATEWAY]) != NULL) {
344 if (!inet_pton(af, blobmsg_data(cur), &route->nexthop)) {
345 DPRINTF("Failed to parse route gateway: %s\n", (char *) blobmsg_data(cur));
346 goto error;
347 }
348 }
When it comes time to actually use the resulting route→nexthop value, https://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c;h=0ca525602d9ea63ac5b845b2be9c6c7bdec7c26c;hb=HEAD#l1851 just checks for all-zeros and, if so, declares it to be a link-local route:
1851 if (alen == 4)
1852 have_gw = !!route->nexthop.in.s_addr;
1853 else
1854 have_gw = route->nexthop.in6.s6_addr32[0] ||
1855 route->nexthop.in6.s6_addr32[1] ||
1856 route->nexthop.in6.s6_addr32[2] ||
1857 route->nexthop.in6.s6_addr32[3];
...
1882 rtm.rtm_scope = (have_gw) ? RT_SCOPE_UNIVERSE : RT_SCOPE_LINK;
...
1925 if (have_gw)
1926 nla_put(msg, RTA_GATEWAY, alen, &route->nexthop);
I believe that struct device_route needs a flag to indicate whether the incoming blobmsg had a ROUTE_GATEWAY or not, and that system_rt should use the device’s configured default gateway if not. There is, at present, no workaround except to hard-code the next hop in the configuration, which is gross.
|
|
25.07.2018 | 1692 | Packages | Bug Report | Very Low | Medium | DDNS seems to not use ca-certificates | Trunk | Waiting on reporter |
Task Description
On 18.06 rc2 I have to type “IGNORE” in the “Path to ca-file” field. Otherwise I always get this error:
Wed Jul 25 23:31:21 2018 user.err ddns-scripts[1745]: myddns_ipv4: cURL Error: ‘77’ Wed Jul 25 23:31:22 2018 user.warn ddns-scripts[1745]: myddns_ipv4: Transfer failed - retry 1/0 in 60 seconds
The ca-certificates package is installed. On 18.06 rc1 I got not this error.
|
|
30.07.2018 | 1713 | Packages | Bug Report | Very Low | Medium | level of deamon log messages | All | Unconfirmed |
Task Description
during some driver tests noticed these:
Sat Jul 7 13:41:52 2018 daemon.err hostapd: Using interface wlan0-2 with hwaddr <mac_addr> and ssid "9531_3"
Sat Jul 7 13:41:52 2018 daemon.err hostapd: Using interface wlan1-2 with hwaddr <mac_addr> and ssid "OpenWrt3"
this was not an error but rather notice.
Sat Jul 7 13:10:06 2018 daemon.notice hostapd: nl80211: Failed to remove interface wlan1-1 from bridge br-lan: No such device
Sat Jul 7 13:11:01 2018 daemon.notice hostapd: wlan1: STA <mac_addr> IEEE 802.11: Could not set STA to kernel driver
Sat Jul 7 13:11:28 2018 daemon.notice hostapd: wlan1: STA <mac_addr> IEEE 802.11: did not acknowledge authentication response
this is most likely an error isn't it rather than just notice?
|
|
12.08.2018 | 1769 | Packages | Feature Request | Very Low | Medium | Enable built-in RADIUS support for full version of host... | Trunk | Unconfirmed |
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
|
|
01.10.2018 | 1876 | Packages | Bug Report | Very Low | Medium | ar71xx: btrfs (RAID1) broken on the TL-WDR3600 | Trunk | Unconfirmed |
Task Description
Hi,
I updated my TP-LINK TL-WDR3600 to OpenWrt 18.06.1 to attach 2 Harddisks in RAID1. The disks were attached to a Linux PC before and they work there without any problems. They are also working with gexxbox (cubibox hardware).
uname -a Linux Grisu-AP 4.9.120 #0 Thu Aug 16 07:51:15 2018 mips GNU/Linux
root@Grisu-AP:/mnt# block info label buffer too small 256 > 63 label buffer too small 256 > 63 /dev/mtdblock2: UUID=”d74faf39-3bf99749-7ff34679-ea820947” VERSION=”4.0” MOUNT=”/rom” TYPE=”squashfs” /dev/mtdblock3: MOUNT=”/overlay” TYPE=”jffs2” /dev/sda: UUID=”72a8abd2-1880-47d5-a91b-836c2bd0e6ae” TYPE=”btrfs” /dev/sdb: UUID=”72a8abd2-1880-47d5-a91b-836c2bd0e6ae” TYPE=”btrfs”
If I try to mount the RAID as sda I get the following: mount /dev/sda /mnt/share mount: mounting /dev/sda on /mnt/share failed: Invalid argument
If I try to mount the RAID as sdb it seems to work. I can browse through the directories for some seconds. Then nothing is listed anymore and I found the following in the log.
[ 206.334816] BTRFS: device label BTRFS_RAID1 devid 1 transid 21115 /dev/sda [ 206.344960] BTRFS info (device sda): disk space caching is enabled [ 206.353718] BTRFS error (device sda): failed to read the system array: -5 [ 206.362914] BTRFS error (device sda): open_ctree failed [ 227.727463] BTRFS info (device sda): disk space caching is enabled [ 227.735960] BTRFS error (device sda): failed to read the system array: -5 [ 227.745478] BTRFS error (device sda): open_ctree failed [ 237.303189] BTRFS: device label BTRFS_RAID1 devid 2 transid 21115 /dev/sdb [ 237.313585] BTRFS info (device sdb): disk space caching is enabled [ 292.959623] ————[ cut here ]———— [ 292.964449] WARNING: CPU: 0 PID: 2010 at fs/btrfs/extent-tree.c:2967 0x8771f3e8 [btrfs@87700000+0xd74a0] [ 292.974243] BTRFS: Transaction aborted (error -17) [ 292.979183] Modules linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw 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_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack lzo libcrc32c iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables nfsd nfs lockd sunrpc grace dns_resolver uas usb_storage sd_mod scsi_mod btrfs zlib_inflate zlib_deflate xor raid6_pq lzo_decompress lzo_compress [ 293.051845] exportfs crc32c_generic crypto_hash ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common [ 293.061554] CPU: 0 PID: 2010 Comm: btrfs-transacti Not tainted 4.9.120 #0 [ 293.068477] Stack : 80497672 0000003d 00000000 00000001 00000000 00000000 00000000 00000000 [ 293.077154] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 293.085741] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 293.094322] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 293.102919] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 293.111499] ... [ 293.114007] Call Trace: [ 293.116327] [<8006ad5c>] 0x8006ad5c [ 293.119889] [<8006ad5c>] 0x8006ad5c [ 293.123427] [<8007fd44>] 0x8007fd44 [ 293.127028] [<8771f3e8>] 0x8771f3e8 [btrfs@87700000+0xd74a0] [ 293.132814] [<8007fd7c>] 0x8007fd7c [ 293.136393] [<8771f3e8>] 0x8771f3e8 [btrfs@87700000+0xd74a0] [ 293.142249] [<87737e5c>] 0x87737e5c [btrfs@87700000+0xd74a0] [ 293.148041] [<877385ec>] 0x877385ec [btrfs@87700000+0xd74a0] [ 293.153811] [<803a79d8>] 0x803a79d8 [ 293.157380] [<87732d94>] 0x87732d94 [btrfs@87700000+0xd74a0] [ 293.163158] [<87732c10>] 0x87732c10 [btrfs@87700000+0xd74a0] [ 293.168960] [<87732c10>] 0x87732c10 [btrfs@87700000+0xd74a0] [ 293.174786] [<80098150>] 0×80098150 [ 293.178399] [<80098074>] 0×80098074 [ 293.181992] [<80065ef8>] 0x80065ef8 [ 293.185533] [ 293.187041] —[ end trace 467c7995bdeef333 ]— [ 293.191792] BTRFS: error (device sdb) in btrfs_run_delayed_refs:2967: errno=-17 Object already exists [ 293.201178] BTRFS info (device sdb): forced readonly [ 293.206265] BTRFS warning (device sdb): Skipping commit of aborted transaction. [ 293.213736] BTRFS: error (device sdb) in cleanup_transaction:1850: errno=-17 Object already exists
If you need more information please let me know. Best regards, grisu
|
|
08.12.2018 | 1989 | Packages | Bug Report | Very Low | Medium | wpa_supplicant disablind timestamp check does not work | All | Unconfirmed |
Task Description
Hi!
As far as I can tell, the option to disable timestamp checks in wpa_supplicant does not work, it can be enabled via CONFIG_WPA_SUPPLICANT_NO_TIMESTAMP_CHECK=y
As a result, certificates are rejected if the system time does not match the expected range of valid dates for the certificate. Manual user action is required in my case, where internet acces via ethernet is governed via 802.1x and wpa_supplicant.
I studied the hostapd package for some time, but as I am no programmer is was not able to tell much, but for me it seems the option is not properly integrated.
My build options are:
CONFIG_PACKAGE_wpad=y # CONFIG_PACKAGE_wpad-mini is not set CONFIG_WPA_SUPPLICANT_INTERNAL=y CONFIG_WPA_SUPPLICANT_NO_TIMESTAMP_CHECK=y
|
|
30.01.2019 | 2093 | Packages | Feature Request | Very Low | Medium | There is 'dslite' but not 'ipip6'? | All | Unconfirmed |
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 'dslite.sh ' 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
|
|
14.08.2019 | 2443 | Packages | Bug Report | Very Low | Medium | qos-scripts: pktsize field does not take effect | Trunk | Unconfirmed |
Task Description
When I modify the “pkgsize” field in /etc/config/qos, the output of
/usr/lib/qos/generate.sh all
does not contain content for matching packet size. For example,add “option pktsize ‘1024’” in rule “download”. But the “packetsize” field works. Device:Phicomm K2P Version:OpenWrt R9.8.5 / LuCI Master (git-19.146.62144-fd6fdb2) luci-app-qos git-19.146.62144-fd6fdb2-1 luci-i18n-qos-zh-cn git-19.146.62144-fd6fdb2-1 qos-scripts 1.3.1-1
|
|
16.09.2019 | 2499 | Packages | Bug Report | Very Low | Medium | Gammu : USSD not showing anything | Trunk | Unconfirmed |
Task Description
On trunk openwrt, on ath79 comfast e5 (supported), gammu package no longer respond on getussd command
Steps to reproduce: gammu getussd “*143#” (replace *143# by your usual USSD service on mobile network)
|
|
25.10.2019 | 2568 | Packages | Bug Report | Very Low | Medium | ct-bugcheck packages breaks uci | Trunk | Unconfirmed |
Task Description
Hi,
I think, that the script bugchecker.sh should get updatet, so that it dont want a script in /etc/config, which triggers a error message on package upgrades:
https://forum.openwrt.org/t/issue-with-installing-several-packages/3443/4
Right now, it want that we create /etc/config/bugcheck with this content:
DO_BUGCHECK=1 export DO_BUGCHECK
There a two options:
Change the check in the script to the uci system or change the file path to a other folder.
|
|
21.01.2020 | 2759 | Packages | Bug Report | Very Low | Medium | odhcpd IPv6 NDP + macOS don't play together | openwrt-19.07 | Unconfirmed |
Task Description
My device: TP-Link Archer C7 v2.0 (JP) My software stack: OpenWrt 19.07
My router uses odhcpd’s relay mode to relay IPv6 neighbor discovery protocol and router advertisements from the uplink router.
My linux-based system connected to the router is able to get IPv6 connectivity through the router without problems.
However, my macOS-based system doesn’t get IPv6 connectivity. It gets a global IPv6 prefix, which suggests that it’s able to receive RA packets, but my router is also unable to ping6 the macOS system by it’s globally unique address, and doing ip -6 neigh on the router makes it clear that the router doesn’t know the MAC address of the macOS system, and all of it’s probes to find it, end up failing.
Inspecting the ICMPv6 traffic in the LAN shows that my macOS system doesn’t respond to the neighbor solicitation packets send by the router. Here’s an example of such a packet:
02:28:50.006540 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fd26:e9f1:e833::1 > ff02::1:ff65:88f8: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2404:7a80:9621:7100:404:978a:5765:88f8
source link-address option (1), length 8 (1): 18:a6:f7:8d:c0:d3
Here, fd26:e9f1:e833::1 is the ULA of the LAN interface of the router.
According to Apple discussion board ( https://discussions.apple.com/thread/8620806 ) macOS seems to have a behaviour such that it ignores neighbor solicitation packets unless the source address of the packet is a link-local address.
Indeed, commenting out option ula_prefix in /etc/config/network makes odhcpd to use link-local addresses, and that makes macOS to respond to neighbor solicitation queries, and in my system, demonstrably restores IPv6 connectivity.
Since macOS is a very common operating system, it would be benefical if odhcpd’s default behaviour were to use LLA in NDP packets. The current situation of not being able to set ULA prefix without losing connectivity is unfortunate. (And I think that ULA prefix is set by default in OpenWRT, which makes macOS not play together with it by default.)
For reference, here’s a forum thread I documented my forays into inspecting this problem: https://forum.openwrt.org/t/how-to-send-icmp6-neighbor-solicitation-with-a-link-local-source-address/53220
Could the default source address of odhcpd’s NDP/RA packets be changed to LLA?
|