OpenWrt/LEDE Project

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

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

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

OpenedIDCategory  descTask TypePrioritySeveritySummaryReported InStatus
16.08.20181785WebsiteBug ReportVery LowMediumarchive.openwrt.org not reachable on IPv6TrunkUnconfirmed Task Description

Hello,

Today I found that my LEDE 17.01.4 router can no longer download packages. The router is on an IPv6-only network, and 17.01.4 stuff seems to have been moved to archive.openwrt.org, which does not support IPv6:

archive.openwrt.org is an alias for archive-01.infra.openwrt.org.
archive-01.infra.openwrt.org has address 81.0.124.218

whereas the normal download servers do:

$ host downloads.lede-project.org
downloads.lede-project.org is an alias for downloads2.lede-project.org.
downloads2.lede-project.org has address 148.251.78.235
downloads2.lede-project.org has IPv6 address 2a01:4f8:202:43ea::3

$ host downloads.openwrt.org
downloads.openwrt.org is an alias for mirror-01.infra.openwrt.org.
mirror-01.infra.openwrt.org has address 148.251.78.235
mirror-01.infra.openwrt.org has IPv6 address 2a01:4f8:202:43ea::2

Can you please add IPv6 on the archive as well.

Thanks!

25.06.2017868WebsiteBug ReportVery LowLowSnapshot directory contains stray/obsolete directoriesTrunkUnconfirmed 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.2017997WebsiteFeature RequestVery LowLowImplement dark theme (or custom color controls)TrunkUnconfirmed 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)


04.05.20192267WebsiteFeature RequestVery LowLowdownloads.openwrt.org: Upgrade from Debian 8 to 9, offe...TrunkUnconfirmed Task Description

The webserver on downloads.openwrt.org currently only offers AES, Camellia and 3DES ciphersuites for HTTPS connections, since the server is running Debian 8, nginx 1.6.2 and OpenSSL 1.0.1t.

An upgrade to Debian 9 with nginx 1.10.3 and OpenSSL 1.1.0j would be appreciated since this would enable the webserver to offer ChaCha20 ciphersuites, which offer a huge performance increase for embedded devices without AES-NI or similar hardware acceleration for AES.

09.11.20192586WebsiteBug ReportVery LowLowgnutls_handshake() failedAllUnconfirmed 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

15.11.20192602WebsiteBug ReportVery LowLowOld Stable Release links to wrong release on the front ...AllUnconfirmed Task Description

The website says:
The most recent version is LEDE 17.01.6

This is not true. There is a LEDE 17.01.7 containing lots of security fixes:
https://openwrt.org/releases/17.01/changelog-17.01.7

18.01.20202749WebsiteBug ReportVery LowLowCannot find GPG key for 19.07 buildsTrunkUnconfirmed 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.20202768ToolchainBug ReportVery LowHighmake_ext4fs: Name-Based UUID leads to collisionTrunkUnconfirmed 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

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.
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.2017767ToolchainBug ReportVery LowMediumuml: Imagebuilder does not honor default packages for u...TrunkUnconfirmed 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
20.08.2017971ToolchainBug ReportVery LowMediummkhash on freebsdlede-17.01Unconfirmed Task Description

Path for build mkhash on freebsd.

07.08.20181748ToolchainBug ReportVery LowMediumlibgcc_pic.a not autoincluded when building c++ staticTrunkUnconfirmed 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.20181779ToolchainBug ReportVery LowMediumtools/include headers contain old, incomplete versions?AllUnconfirmed 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?

02.01.20192041ToolchainBug ReportVery LowMediumPre-compiled headers don't work at all when building on...lede-17.01Unconfirmed Task Description

To reproduce:
1) Make a file test.h:
#define test 1
2) Make a file test.c:
void main() { return; }
3) Try to create and use a precompiled header
mips-...g++ -c -x c++-header -o test.gch test.h
mips-...g++ -o prog -Winvalid-pch -include test test.c

I get:

cc1plus: warning: test.gch: had text segment at different address

So it appears that something Bionic/GCC7.3 is doing to gcc causes gcc 5.4.0 PCH to break completely. PCH works fine on GCC 7.3 on the host, so it’s likely something that was fixed upstream, but I’m having difficulty finding the fix in gcc’s git history.

31.01.20192094ToolchainBug ReportVery LowMediumimage builder has incorrect board name for wr842n-v1 ca...AllUnconfirmed Task Description

Boardname mismatch in imagebuilder (and suspected release builds) for tplink wr842n-v1
Doesn't appear to be an issue if upgrading to another ar71xxx image but sysupgrade fails when upgrading to ath79 image for wr842n-v1 due to board mismatch.

from existing ar71xxx wr842n-v1 system

head -n5 /etc/board.json
{
"model": {
"id": "tl-mr3420",
"name": "TP-Link TL-WR842N/ND v1"
},

in file openwrt-imagebuilder-18.06.1-ar71xx-generic.Linux-x86_64/target/linux/ar71xx/image/generic-tp-link.mk

define Device/tl-wr842n-v1
$(Device/tplink-8m)
DEVICE_TITLE := TP-LINK TL-WR842N/ND v1
DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
BOARDNAME := TL-MR3420 DEVICE_PROFILE := TLWR842
TPLINK_HWID := 0x08420001
endef
TARGET_DEVICES += tl-wr842n-v1
Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

Discussed in form thread


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:

./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.20202774ToolchainBug ReportVery LowMediumimagebuilder breaks in long pwdopenwrt-19.07Unconfirmed 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.20202957ToolchainBug ReportVery LowMediumopenwrt 19.07 x86_64 sdk toolchain segmentation fault i...openwrt-19.07Unconfirmed 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.

14.05.2017784ToolchainBug ReportVery LowLowar71xx: imagebuilder fails when BIN_DIR or EXTRA_IMAGE_...lede-17.01Unconfirmed Task Description

Supply the following if possible:

- Device problem occurs on

HORNETUBx2

HORNETUB

- Software versions of LEDE release, packages, etc.

lede-imagebuilder-17.01.1-ar71xx-generic.Linux-x86_64

- Steps to reproduce

make image PROFILE=HORNETUBx2 BIN_DIR=/tmp/bld/

... dies with :

“Warning: /home/kjh/toolroot.d/lede-imagebuilder-17.01.1-ar71xx-generic.Linux-x86_64/bin/targets/ar71xx/generic/lede-17.01.1-ar71xx-generic-hornet-ub-x2-squashfs-sysupgrade.bin is too big (> 16318464 bytes)”

... but it seems to work OK without BIN_DIR :

make image PROFILE=HORNETUBx2

EXTRA_IMAGE_NAME also seems to cause this problem


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. 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.20181886ToolchainBug ReportVery LowLowbuiltin_memcmp(a,b,c) != 0 not used on mips with -Os or...TrunkUnconfirmed 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.

21.03.20192198ToolchainBug ReportVery LowLowTow entangled problems involving boost and package inte...openwrt-18.06Unconfirmed Task Description

This involves an x86 generic full build of 18.02.
This seems less to be a problem directly involving packages, and more a
problem involving the integration of packages.

The builds were finishing up to this point.
In make menuconfig, I added in a few packages to replace the weaker
binutils version of these utilities, e.g., the less package, because I
wanted the search capability.
Apparently these additions got tangled up with boost, which was not at
this point selected:

cp -fpR -v /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.{a,so*} /home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/
‘/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/libboost_exception.a’ → ‘/home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/libboost_exception.a’ cp: cannot stat ‘/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.so*’: No such file or directory

I searched for the unusual string {a,so*} and found it in feeds/packages/libs/boost/Makefile
line 473.
Apparently boost was being pulled in, but not creating any .so* files, even though boost was not yet selected.

So I went into make menuconfig and selected boost. Same problem.

Then I split line 473 to this form:

$(CP) -v $(PKG_INSTALL_DIR)/lib/*.a $(1)/usr/lib/
-$(CP) -v $(PKG_INSTALL_DIR)/lib/*.so* $(1)/usr/lib/

(It had been {a,so*}).
This (I think) will execute the same if boost is creating any .so files,
but will otherwise get past this step if no .so files are being created.

It seemed to work at first. But then (using make -j1) I started getting
complaints about the newly selected packages overwriting busybox versions of
files.
If you look more closely you will see that these errors wrote in the middle
of the string “Configuring boost.”
CoCollected errors:
* check_data_file_clashes: Package logger wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/logger

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package logger.
* check_data_file_clashes: Package findutils-find wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/find

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package findutils-find.
* check_data_file_clashes: Package findutils-xargs wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/xargs

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package findutils-xargs.
* check_data_file_clashes: Package less-wide wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/bin/less

      But that file is already provided by package  * less

* opkg_install_cmd: Cannot install package less-wide.
nfiguring boost.

Note that busybox doesn’t like having logger, find, and xargs overwritten,
but I also selected find and less, which should have overwritten busybox
versions of the files. But that didn’t generate any complaints.

Here is where my memory gets a little hazy... I found out about this time that
menuconfig/boost was set to not install any libraries, so I selected ‘all
libraries’, and that may have gotten rid of the boost .so problem, because the
boost build was now creating .so files.

But I was still getting the file overwrite problem, so I yanked out the
offending package selections. At that point the make process completed.

Anyway, that’s what happened.

 


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

So I pulled the imagebuilder from here:

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

And tried to build with the following commandline:

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

However I got the following exception:

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

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

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

But I got the same exception for another package:

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

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

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

Got the same exception:

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

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

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

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

25.02.20202860ToolchainBug ReportVery LowLowtools/firmware-utils/mkcameofw not foundTrunkUnconfirmed 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.

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

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,
  • mbedtls.log: The pa[.config-diffconfig-seed.txt](https://github.com/openwrt/packages/files/1782373/default.config-diffconfig-rt 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.)

11.05.20181543PackagesBuild FailureVery LowCriticalMany packages in snapshot failing on one build, ok on n...TrunkUnconfirmed 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.

30.05.20181570PackagesBug ReportVery LowCriticalNeither wget, nor uclient-fetch can connect to www.duck...lede-17.01Unconfirmed Task Description

I’m running LEDE 17.01.4, r3560-79f57e422d.

Packages versions:

wget_1.19.2-2
libpcre_8.41-2
librt_1.1.16-1
libustream-openssl_2016-07-02-ec80adaa-4
ca-bundle_20170717_all
libopenssl_1.0.2o-1
uci_2018-01-01-141b64ef-1
uclient-fetch_2017-11-02-4b87d831-1

# cd /tmp
# /usr/bin/wget-ssl -d 'https://www.duckdns.org/update?domains=XXXXXXXXXXX&token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&ip='
DEBUG output created by Wget 1.19.2 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
Converted file name 'update?domains=XXXXXXXXXXX&token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&ip=' (UTF-8) -> 'domains=XXXXXXXXXXX&token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&ip=' (ASCII)
--2018-05-30 09:10:14--  https://www.duckdns.org/update?domains=XXXXXXXXXXX&token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&ip=
Resolving www.duckdns.org... 34.209.108.142, 54.187.208.74
Caching www.duckdns.org => 34.209.108.142 54.187.208.74
Connecting to www.duckdns.org|34.209.108.142|:443... connected.
Created socket 3.
Releasing 0x77bb5970 (new refcount 1).
Initiating SSL handshake.
SSL handshake failed.
Closed fd 3
Unable to establish SSL connection.

# uclient-fetch 'https://www.duckdns.org/update?domains=XXXXXXXXXXX&token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&ip='
Downloading 'https://www.duckdns.org/update?domains=XXXXXXXXXXX&token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&ip='
Connecting to 34.209.108.142:443
(null)                   0   - stalled -
Connection reset prematurely
or
Connecting to 34.209.108.142:443
Connection error: Connection failed
23.12.20182023PackagesBug ReportVery LowCriticalPPtP not connecting on Xiaomi Mi WiFi R3Gopenwrt-18.06Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on : Xiaomi Mi WiFi R3G (https://openwrt.org/toh/xiaomi/mir3g)
- OpenWrt 18.06.1

Steps to reproduce:

1.opkg update
2.opkg install ppp-mod-pptp
3.opkg install kmod-nf-nathelper-extra
4.opkg install kmod-ipt-raw
5.disabled rebind attack protection from DNS and DHCP
6.added below custom rule on /etc/firewall.user

iptables -t raw -A OUTPUT -p tcp -m tcp --dport 1723 -j CT --helper pptp

7.setup the PPTP in the LUCI
8.reboot

Relevant Logs appearing repetitively:

Sun Dec 23 17:48:01 2018 daemon.notice pppd[22738]: pppd 2.4.7 started by root, uid 0
Sun Dec 23 17:48:02 2018 kern.info kernel: [ 1551.622787] pptp-ISP: renamed from ppp0
Sun Dec 23 17:48:02 2018 daemon.info pppd[22738]: Using interface pptp-ISP Sun Dec 23 17:48:02 2018 daemon.notice pppd[22738]: Connect: pptp-ISP ←→ pptp (red.connect.net.pk)
Sun Dec 23 17:48:03 2018 daemon.notice pppd[22738]: CHAP authentication succeeded
Sun Dec 23 17:48:03 2018 daemon.notice pppd[22738]: Connection terminated.
Sun Dec 23 17:48:03 2018 daemon.warn pppd[22740]: read returned zero, peer has closed
Sun Dec 23 17:48:03 2018 daemon.warn pppd[22740]: read returned zero, peer has closed
Sun Dec 23 17:48:03 2018 daemon.info pppd[22738]: Exit.
Sun Dec 23 17:48:03 2018 daemon.notice netifd: Interface ‘ISP’ is now down
Sun Dec 23 17:48:03 2018 daemon.notice netifd: Interface ‘ISP’ is setting up now
Sun Dec 23 17:48:03 2018 daemon.info pppd[22998]: Plugin pptp.so loaded.
Sun Dec 23 17:48:03 2018 daemon.info pppd[22998]: PPTP plugin version 1.00
Sun Dec 23 17:48:03 2018 daemon.notice pppd[22998]: pppd 2.4.7 started by root, uid 0


21.01.20192070PackagesBug ReportVery LowCriticalbn_wexpand in bn_div.c are not checked for failure and ...openwrt-18.06Unconfirmed Task Description

Hi,
The code in the openwrt/package/network/services/ead/src/tinysrp/bn_div.c should be fixed to check the bn_wexpand return value. The problem exists in multiple other projects including openssl with CVE (CVE-2009-3245)(https://github.com/openssl/openssl/commit/2d9dcd4ff0923347fab727ac90e8526dd65e4e07).

21.01.20192071PackagesBug ReportVery LowCriticalbn_wexpand return value vulnerable to memory leakopenwrt-18.06Unconfirmed Task Description

Hi,
The code in the openwrt/package/network/services/ead/src/tinysrp/bn_div.c should be fixed to check the bn_wexpand return value. The problem exists in multiple other projects including openssl with CVE (CVE-2009-3245)(https://github.com/openssl/openssl/commit/2d9dcd4ff0923347fab727ac90e8526dd65e4e07).

21.01.20192072PackagesBug ReportVery LowCriticalbn_wexpand return value vulnerable to memory leakopenwrt-18.06Unconfirmed Task Description

Hi,
The code in the openwrt/package/network/services/ead/src/tinysrp/bn_div.c should be fixed to check the bn_wexpand return value. The problem exists in multiple other projects including openssl with CVE (CVE-2009-3245)(https://github.com/openssl/openssl/commit/2d9dcd4ff0923347fab727ac90e8526dd65e4e07).

23.01.20192080PackagesBug ReportVery LowCriticalWan IPV6 interface with 6rd protocol reports bad mac ad...openwrt-18.06Unconfirmed Task Description

Device used is BT Home Hub 5 v1.2.
Openwrt release is 18.06.1,
6rd package version is 9-4
ISP is Free (France)

“Wan” interface, IPV4, with Dchp client protocol is up and works fine on physical interface dsl0.836.
Mac address has to be overriden because ISP uses a fixed mac address, different for each Freebox, it’s own dsl modem/box.

“Wan6”, IPV6, interface with 6rd protocol is up but the mac reported in the not the same as those reported in “Wan” interface.

As you could see on the attached capture of the “Interfaces overview”, the mac address reported is the “Wan” IpV4 address !!!

Wan6 interface is up but frames are rejected by ISP because the mac address is not those one expected as for “Wan” interface. Mac address can’t be overriden on these interface.

network config is attached.



Cromagnon31

28.02.20202868PackagesBug ReportVery LowCriticalCLAT/464XLAT stopped working in 19.07.1openwrt-19.07Unconfirmed 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.20203067PackagesBug ReportVery LowCriticaldownload board.bin failureopenwrt-19.07Unconfirmed 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.

03.08.2017948PackagesBug ReportVery LowHighlua: on 64bit targets integer number truncation may occ...AllUnconfirmed 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.20171076PackagesBug ReportVery LowHighBugs about QCA9886AllWaiting 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.20181374PackagesBug ReportVery LowHighubox: logd memory leak AllUnconfirmed 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
```


14.06.20192319PackagesBug ReportVery LowHighusbmode bug which is fixed in usb-modeswitch...openwrt-18.06Unconfirmed Task Description

I wrote a bug report but then the bug report said wrong token and I lost the report... :(

Now again but shorter version. The usb-modeswitch (which seems to be an openwrt project, a rewrite of original usb_modeswitch https://git.openwrt.org/project/usbmode.git ) needs to set some devices to config 0 before switching to config 3.

BTW this is fixed in usb-modeswitch... Here is the link to discussion about this:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2710&start=22

Some devices need to be set to config 0 first to be able to switch to config 3. Otherwise they hang...

Here a working example:

root@OpenWrt:~# echo 0 > /sys/bus/usb/devices/1-2/bConfigurationValue
root@OpenWrt:~# echo 3 > /sys/bus/usb/devices/1-2/bConfigurationValue
root@OpenWrt:~# umbim -d /dev/cdc-wdm0 caps

devicetype: 0001 - embedded
cellularclass: 0001
voiceclass: 0001 - no-voice
simclass: 0002
dataclass: 8000003F
smscaps: 0003
controlcaps: 0001
maxsessions: 0003
deviceid: 867377023108313
firmwareinfo: 11.617.06.00.00
hardwareinfo: RM1ME909ASM

root@OpenWrt:~#

A non-working example (after reboot):

root@OpenWrt:~# echo 3 > /sys/bus/usb/devices/1-2/bConfigurationValue
root@OpenWrt:~# umbim -d /dev/cdc-wdm0 caps
ERROR: mbim message timeout
root@OpenWrt:~#

At least one other person in OpenWRT bug tracker confirms this:
https://bugs.openwrt.org/index.php?do=details&task_id=1424

Although he has another problem with looping messages (probably unrelated to this bug)
https://forum.openwrt.org/t/usbmode-sits-in-loop-after-install/12624

19.06.20192330PackagesBug ReportVery LowHighSamba - smb.conf templating allows arbitrary injections...AllUnconfirmed 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?

24.06.20192336PackagesBuild FailureVery LowHighBuild fail with php7openwrt-18.06Unconfirmed Task Description

Hi all,
When using openwrt builder and adding package in make command, build fails because PHP7 packages are missing in repository and packages lists.
could you take a look please ?
have a nice day

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

26.04.20203051PackagesBug ReportVery LowHighUPnP not workingAllUnconfirmed 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.05.20203107PackagesBug ReportVery LowHigh[netifd] wan Command failed: Permission denied | repeat...TrunkUnconfirmed Task Description

- Master 5.4.41
- mvebu → cortex-A9
- upstream connectivity VDSL2 dual-stack | PPPoE | IPv4 via PPPoE | IPv6 via DHCP (only after PPPoE is completed)
- SFP VDSL modem residing in router’s SFP cage


ifup wan

produces

40:49  netifd: Interface 'wan' is enabled
40:49  kernel: [ 4539.310854] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
40:49  kernel: [ 4539.629747] sfp sfp: module transmit fault indicated
40:51  netifd: Network device 'eth2' link is up
40:51  netifd: Interface 'wan' has link connectivity
40:51  netifd: Interface 'wan' is setting up now
40:51  kernel: [ 4541.699901] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
40:51  kernel: [ 4541.699917] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
40:51  insmod: module is already loaded - slhc
40:51  insmod: module is already loaded - ppp_generic
40:51  insmod: module is already loaded - pppox
40:51  insmod: module is already loaded - pppoe
40:51  pppd[29207]: Plugin rp-pppoe.so loaded.
40:51  pppd[29207]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
40:51  pppd[29207]: pppd 2.4.8 started by root, uid 0
41:06  pppd[29207]: Timeout waiting for PADO packets
41:06  pppd[29207]: Unable  complete PPPoE Discovery
41:06  pppd[29207]: Exit.
41:06  netifd: Interface 'wan' is now down
41:06  kernel: [ 4556.940117] mvneta f1034000.ethernet eth2: Link is Down
41:06  netifd: Interface 'wan' is disabled
41:06  netifd: Interface 'wan' is enabled
41:06  netifd: Interface 'wan' is setting up now
41:06  kernel: [ 4556.954502] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:06  netifd: Network device 'eth2' link is down
41:06  netifd: Interface 'wan' has link connectivity loss
41:06  insmod: module is already loaded - slhc
41:06  insmod: module is already loaded - ppp_generic
41:06  insmod: module is already loaded - pppox
41:06  insmod: module is already loaded - pppoe
41:07  netifd: wan (29306): Command failed: Permission denied
41:07  netifd: Interface 'wan' is now down
41:07  netifd: Interface 'wan' is disabled
41:07  netifd: Interface 'wan' is enabled
41:07  kernel: [ 4557.042474] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:07  netifd: Network device 'eth2' link is up
41:07  netifd: Interface 'wan' has link connectivity
41:07  netifd: Interface 'wan' is setting up now
41:07  kernel: [ 4557.209931] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
41:07  kernel: [ 4557.209948] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
41:07  insmod: module is already loaded - slhc
41:07  insmod: module is already loaded - ppp_generic
41:07  insmod: module is already loaded - pppox
41:07  insmod: module is already loaded - pppoe
41:07  pppd[29362]: Plugin rp-pppoe.so loaded.
41:07  pppd[29362]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
41:07  pppd[29362]: pppd 2.4.8 started by root, uid 0
41:22  pppd[29362]: Timeout waiting for PADO packets
41:22  pppd[29362]: Unable  complete PPPoE Discovery
41:22  pppd[29362]: Exit.
41:22  netifd: Interface 'wan' is now down
41:22  kernel: [ 4572.446438] mvneta f1034000.ethernet eth2: Link is Down
41:22  netifd: Interface 'wan' is disabled
41:22  netifd: Interface 'wan' is enabled
41:22  netifd: Interface 'wan' is setting up now
41:22  netifd: Network device 'eth2' link is down
41:22  netifd: Interface 'wan' has link connectivity loss
41:22  kernel: [ 4572.459786] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:22  insmod: module is already loaded - slhc
41:22  insmod: module is already loaded - ppp_generic
41:22  insmod: module is already loaded - pppox
41:22  insmod: module is already loaded - pppoe
41:22  netifd: wan (29492): Command failed: Permission denied
41:22  netifd: Interface 'wan' is now down
41:22  netifd: Interface 'wan' is disabled
41:22  netifd: Interface 'wan' is enabled
41:22  kernel: [ 4572.544765] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:22  netifd: Network device 'eth2' link is up
41:22  netifd: Interface 'wan' has link connectivity
41:22  netifd: Interface 'wan' is setting up now
41:22  kernel: [ 4572.712631] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
41:22  kernel: [ 4572.712647] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
41:22  insmod: module is already loaded - slhc
41:22  insmod: module is already loaded - ppp_generic
41:22  insmod: module is already loaded - pppox
41:22  insmod: module is already loaded - pppoe
41:22  pppd[29549]: Plugin rp-pppoe.so loaded.
41:22  pppd[29549]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
41:22  pppd[29549]: pppd 2.4.8 started by root, uid 0
41:29  pppd[29549]: PPP session is 31713
41:29  pppd[29549]: Connected  78:ba:f9:73:f5:74 via interface eth2
41:29  kernel: [ 4579.318874] pppoe-wan: renamed from ppp0
41:29  pppd[29549]: Renamed interface ppp0  pppoe-wan
41:29  pppd[29549]: Using interface pppoe-wan
41:29  pppd[29549]: Connect: pppoe-wan <--> eth2
41:35  pppd[29549]: PAP authentication succeeded
41:35  pppd[29549]: peer from calling number 78:BA:F9:73:F5:74 authorized
41:35  pppd[29549]: local  IP address 
41:35  pppd[29549]: remote IP address 
41:35  pppd[29549]: primary   DNS address 
41:35  pppd[29549]: secondary DNS address 
41:35  pppd[29549]: local  LL address fe80::b931:4e21:f7f2:a0ad
41:35  pppd[29549]: remote LL address fe80::7aba:f9ff:fe73:f574
41:35  netifd: Network device 'pppoe-wan' link is up
41:35  netifd: Interface 'wan' is now up
41:35  netifd: Network alias 'pppoe-wan' link is up
41:35  netifd: Interface 'wan_6' is enabled
41:35  netifd: Interface 'wan_6' has link connectivity
41:35  netifd: Interface 'wan_6' is setting up now

Unclear how this could be debugged. With the repeated loading of ppp modules it looks like a timing issue.

 


17.02.2017527PackagesBug ReportVery LowMediumQMI modem Olivetti Techcenter (0b3c:c00a) freezes on uq...lede-17.01Unconfirmed Task Description

Hello,

I used to use modem Olivetti Techcenter (0b3c:c00a) on OpenWRT CC.1 without problems.
However, testing on LEDE 17.01.0-rc2, I’m unable to connect.

I traced the problem to ‘uqmi -s -d “$device” –sync’ at https://github.com/lede-project/source/blob/master/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh#L101.

My config is simple as:

config interface 'wwan'
        option ifname 'wwan0'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'
        option apn 'gprs.oi.com.br'
        option auth 'none'

Using strace, it always stops at this point:

...
open("/dev/cdc-wdm0", O_RDWR|O_EXCL|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 6
fcntl64(6, F_GETFL)                     = 0x2082 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLRDHUP|EPOLLET, {u32=4305304, u64=18491139879337984}}) = 0
write(6, "\1\v\0\0\0\0\0\1'\0\0\0", 12) = 12
rt_sigaction(SIGINT, NULL, {sa_handler=0x401071, sa_mask=[RT_66 RT_67 RT_68 RT_69 RT_70 RT_71], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0}, 16) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=0x401071, sa_mask=[RT_66 RT_67 RT_68 RT_69 RT_70 RT_71], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0}, 16) = 0
rt_sigaction(SIGCHLD, NULL, {sa_handler=SIG_DFL, sa_mask=[RT_66 RT_67 RT_68 RT_69 RT_70 RT_71], sa_flags=0}, 16) = 0
rt_sigaction(SIGCHLD, {sa_handler=0x77d85541, sa_mask=[RT_68 RT_69 RT_73 RT_74 RT_75 RT_76 RT_78 RT_80 RT_82 RT_84 RT_85 RT_87 RT_88 RT_89 RT_90 RT_91 RT_93 RT_94 RT_95], sa_flags=SA_RESTORER, sa_restorer=0}, NULL, 16) = 0
rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_DFL, sa_mask=[RT_65 RT_68 RT_70], sa_flags=0}, 16) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[RT_68 RT_69 RT_73 RT_74 RT_75 RT_76 RT_78 RT_80 RT_82 RT_84 RT_85 RT_87 RT_88 RT_89 RT_90 RT_91 RT_93 RT_94 RT_95], sa_flags=SA_RESTORER, sa_restorer=0}, NULL, 16) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=7909, tv_nsec=543507701}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=7909, tv_nsec=544052152}) = 0
epoll_pwait(3, 

If I comment the “uqmi –sync” call, it simply works. “–sync” is a new action for uqmi since OpenWRT CC.1

My System is:



LEDE 17.01.0-rc2, r3131-42f3c1f
uqmi 2016-12-19-8ceeab69-1
machine: TP-LINK TL-WDR3600/4300/4310 (ar71xx) with QMI modem Olivetti Techcenter (0b3c:c00a)

13.03.2017625PackagesBug ReportVery LowMediumno default route written using proto=wwanlede-17.01Unconfirmed Task Description

LEDE_RELEASE=”LEDE Reboot 17.01-SNAPSHOT r6469+17-c114383”

Configure steps as follows:

Run ubus listen in backround
ubus -t 9999 listen &

uci del network.wwan
uci set network.wwan=interface
uci set network.wwan.proto=wwan
uci set network.wwan.defaultroute=’0’ uci set network.wwan.pincode= uci set network.wwan.apn= uci commit && /etc/init.d/network restart
...
{ “ubus.object.add”: {”id”:107055350,”path”:”network.interface.wwan_4”} }
{ “network.interface”: {”action”:”ifup”,”interface”:”wwan_4”} }
...

As you see default route should not be written immediately. You see default route in inactive section in ubus. So now lets set the default route for this interface

uci set network.wwan.defaultroute=’1’ uci commit && /etc/init.d/network reload

You see no ubus message as well no change of default route. Now lets use QMI proto directly

uci del network.wwan
uci set network.wwan=interface
uci set network.wwan.proto=qmi
uci set network.wwan.device=/dev/cdc-wdm0
uci set network.wwan.defaultroute=’0’ uci set network.wwan.pincode= uci set network.wwan.apn= uci commit && /etc/init.d/network restart
...
{ “ubus.object.add”: {”id”:107055350,”path”:”network.interface.wwan_4”} }
{ “network.interface”: {”action”:”ifup”,”interface”:”wwan_4”} }
...

So now lets set the default route for this interface and you see ubus messages comming up as well default route is set

uci set network.wwan.defaultroute=’1’ uci commit && /etc/init.d/network reload
{ “network.interface”: {”action”:”ifdown”,”interface”:”wwan”} }
{ “network.interface”: {”action”:”ifdown”,”interface”:”wwan_4”} }
root@RED50:/lib# { “ubus.object.remove”: {”id”:399408035,”path”:”network.interface.wwan_4”} }
{ “network.interface”: {”action”:”ifup”,”interface”:”wan2”} }
{ “network.interface”: {”action”:”ifup”,”interface”:”wwan”} }
{ “ubus.object.add”: {”id”:828745890,”path”:”network.interface.wwan_4”} }
{ “network.interface”: {”action”:”ifup”,”interface”:”wwan_4”} }


25.03.2017654PackagesBug ReportVery LowMediumdial on demand not workinglede-17.01Unconfirmed Task Description

Using LEDE Reboot 17.01.0 r3205-59508e3 on Lenovo Y1.
After setting the Inactivity timeout to something not 0 in luci (option demand ‘5’ in the config file),the dial procedure will be stopping at some stage,can’t establish a connect.
And the log will be like this:

May  7 08:48:52 OpenWrt daemon.info pppd[9714]: Plugin rp-pppoe.so loaded.
May  7 08:48:52 OpenWrt daemon.info pppd[9714]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
May  7 08:48:52 OpenWrt daemon.notice pppd[9714]: pppd 2.4.5 started by root, uid 0
May  7 08:48:52 OpenWrt daemon.info pppd[9714]: Using interface pppoe-wan
May  7 08:48:52 OpenWrt daemon.notice pppd[9714]: local  IP address 10.64.64.64
May  7 08:48:52 OpenWrt daemon.notice pppd[9714]: remote IP address 10.112.112.112

Without the demand option everything works fine:

May  7 09:08:43 OpenWrt daemon.info pppd[2712]: Plugin rp-pppoe.so loaded.
May  7 09:08:43 OpenWrt daemon.info pppd[2712]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5
May  7 09:08:43 OpenWrt daemon.notice pppd[2712]: pppd 2.4.5 started by root, uid 0
May  7 09:08:48 OpenWrt daemon.info pppd[2712]: PPP session is 9873
May  7 09:08:48 OpenWrt daemon.warn pppd[2712]: Connected to 00:30:88:1f:30:07 via interface eth2
May  7 09:08:48 OpenWrt daemon.info pppd[2712]: Using interface pppoe-wan
May  7 09:08:48 OpenWrt daemon.notice pppd[2712]: Connect: pppoe-wan <--> eth2
May  7 09:08:48 OpenWrt daemon.notice pppd[2712]: PAP authentication succeeded
May  7 09:08:48 OpenWrt daemon.notice pppd[2712]: peer from calling number 00:30:88:1F:30:07 authorized
May  7 09:08:49 OpenWrt daemon.notice pppd[2712]: local  IP address 93.232.124.118
May  7 09:08:49 OpenWrt daemon.notice pppd[2712]: remote IP address 217.0.119.51
May  7 09:08:49 OpenWrt daemon.notice pppd[2712]: primary   DNS address 217.0.43.17
May  7 09:08:49 OpenWrt daemon.notice pppd[2712]: secondary DNS address 217.0.43.49

(these logs is copy from the openwrt bug ticketExternal Link because my log for this part had be override by massive “ieee80211 phy1: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2”,sincere apology,smile)
It seems to be a historied legacy bug from Openwrt BB (or AA),and there is a solution by changing 2 files to make pppd disconnect when inactivity but can’t re-dial:
1./etc/config/network, disable IPv6

config interface 'wan'
        option ipv6 0

2./lib/netifd/proto/ppp.sh: change nodefaultroute to defaultroute in the function of ppp_generic_setup()

	proto_run_command "$config" /usr/sbin/pppd \
		nodetach ipparam "$config" \
		ifname "$pppname" \
		${keepalive:+lcp-echo-interval $interval lcp-echo-failure ${keepalive%%[, ]*}} \
		${ipv6:++ipv6} \
		defaultroute \

Hope this stinking bug can be terminated in LEDE

14.05.2017783PackagesBug ReportVery LowMediumgpsd doesn't work with "Garmin USB binary" (nor NMEA200...TrunkUnconfirmed 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.2017803PackagesBug ReportVery LowMediumNL80211_STA_INFO_INACTIVE_TIME incorrect value for IB...TrunkUnconfirmed 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.20171238PackagesBug ReportVery LowMediumcurl: https request returns 'Illegal instruction'TrunkUnconfirmed 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`?

22.02.20181383PackagesBug ReportVery LowMedium[kmod-b43]Crashes after 5GHz Scanlede-17.01Unconfirmed Task Description

Supply the following if possible:
- Device: Linksys E3000
- LEDE version: LEDE Reboot 17.01.4 r3560-79f57e422d, kmod-b43 - 4.4.92+2017-01-31-3
- Steps to reproduce
Open LuCI page, Network-Wireless, press Scan for “Generic MAC80211 802.11a (radio1)”, then LEDE crashes, and router reboots itself.
dmesg output:
[ 77.097162] random: nonblocking pool is initialized
[ 364.790599] b43-phy1: Loading firmware version 666.2 (2011-02-23 01:15:07)
[ 364.846607] Data bus error, epc == 8016dd88, ra == 801df05c
[ 364.852277] Oops[#1]:
[ 364.854607] CPU: 0 PID: 1370 Comm: luci Not tainted 4.4.92 #0
[ 364.860446] task: 8399ed48 ti: 83938000 task.ti: 83938000
[ 364.865928] $ 0 : 00000000 1100bc00 00000002 1100bc03
[ 364.871269] $ 4 : a80003fa 838fc058 00000108 00007000
[ 364.876610] $ 8 : 00000023 00000000 00000001 00000006
[ 364.881952] $12 : 00000000 000002a0 00000000 00000000
[ 364.887293] $16 : 838fc000 838fc058 000003fa 838fc328
[ 364.892634] $20 : 838fc034 0000029a 00000002 00000001
[ 364.897977] $24 : 00000001 801df014
[ 364.903318] $28 : 83938000 83939b38 00000001 801df05c
[ 364.908660] Hi : 00000000
[ 364.911592] Lo : 0f5c28f6
[ 364.914528] epc : 8016dd88 0x8016dd88
[ 364.918425] ra : 801df05c 0x801df05c
[ 364.922317] Status: 1100bc03 KERNEL EXL IE
[ 364.926597] Cause : c080801c (ExcCode 07)
[ 364.930671] PrId : 00019740 (MIPS 74Kc)
[ 364.934654] Modules linked in: pppoe ppp_async iptable_nat b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 bgmac_bcma 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_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc8 crc_ccitt cordic compat bgmac_bcma_mdio bgmac ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables leds_gpio ohci_platform ohci_hcd ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common ssb_hcd bcma_hcd
[ 365.003649] Process luci (pid: 1370, threadinfo=83938000, task=8399ed48, tls=776aad48)
[ 365.011680] Stack : 0000016c 000c1047 00000000 800489fc 0000016c 611fc6ba 803b6b60 8036c254
[ 365.011680] 00000000 803b436c 00000000 00000001 803d0000 803b0000 00000000 00000080
[ 365.011680] 00000004 838fc000 838fc058 801dee98 838fc058 801defb8 00000001 801ebce8
[ 365.011680] 00000000 838fc000 838fc058 801dee98 00000000 83213a94 1100bc00 803b22ec
[ 365.011680] 00000080 83248ee0 00000074 838fc000 838fc058 83939bf0 838fc058 801df03c
[ 365.011680] ...
[ 365.048015] Call Trace:[<800489fc>] 0x800489fc
[ 365.052577] [<801dee98>] 0x801dee98
[ 365.056131] [<801defb8>] 0x801defb8
[ 365.059682] [<801ebce8>] 0x801ebce8
[ 365.063236] [<801dee98>] 0x801dee98
[ 365.066791] [<83213a94>] 0x83213a94 [b43@83200000+0×55470]
[ 365.072378] [<801df03c>] 0x801df03c
[ 365.075943] [<801df03c>] 0x801df03c
[ 365.079501] [<83213a30>] 0x83213a30 [b43@83200000+0×55470]
[ 365.085077] [<83212284>] 0×83212284 [b43@83200000+0×55470]
[ 365.090661] [<83212948>] 0×83212948 [b43@83200000+0×55470]
[ 365.096252] [<83216f5c>] 0x83216f5c [b43@83200000+0×55470]
[ 365.101838] [<801dee98>] 0x801dee98
[ 365.105394] [<801dea54>] 0x801dea54
[ 365.108951] [<801dee98>] 0x801dee98
[ 365.112521] [<832131b8>] 0x832131b8 [b43@83200000+0×55470]
[ 365.118114] [<83213230>] 0×83213230 [b43@83200000+0×55470]
[ 365.123710] [<83206be0>] 0x83206be0 [b43@83200000+0×55470]
[ 365.129317] [<83207560>] 0×83207560 [b43@83200000+0×55470]
[ 365.134907] [<83182ff8>] 0x83182ff8 [mac80211@83180000+0×60860]
[ 365.140941] [<831960f8>] 0x831960f8 [mac80211@83180000+0×60860]
[ 365.146965] [<8020b664>] 0x8020b664
[ 365.150524] [<8020b96c>] 0x8020b96c
[ 365.154074] [<801f0534>] 0x801f0534
[ 365.157633] [<8020ba50>] 0x8020ba50
[ 365.161181] [<80220ab8>] 0x80220ab8
[ 365.164736] [<8027449c>] 0x8027449c
[ 365.168282] [<8029bfb4>] 0x8029bfb4
[ 365.171841] [<801effb4>] 0x801effb4
[ 365.175408] [<800bb3cc>] 0x800bb3cc
[ 365.178960] [<800ac178>] 0x800ac178
[ 365.182512] [<800bdea0>] 0x800bdea0
[ 365.186063] [<801eea94>] 0x801eea94
[ 365.189614] [<800c469c>] 0x800c469c
[ 365.193175] [<800bb4d4>] 0x800bb4d4
[ 365.196730] [<80003398>] 0×80003398 [ 365.200296]
[ 365.201814]
[ 365.201814] Code: 03e00008 304200ff 94820000 <03e00008> 3042ffff 8c820000 03e00008 00000000 308400ff
[ 365.212331] —[ end trace f01c15e372c1be21 ]—

Showing tasks 1 - 50 of 1140 Page 1 of 231 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing