OpenWrt/LEDE Project

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!

Please remove obsolete directories in the snapshot directory (packages)

aarch64_armv8-a/
arm_cortex-a53_neon-vfpv4/
arm_cortex-a7/
i386_geode/
powerpc_440/

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)

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.

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

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

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

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

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

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

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?

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

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

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.

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.

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

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.

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.

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.

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]$ 

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

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.

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

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

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

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

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

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.

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.

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.
 

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

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

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?

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

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:

• https://forum.openwrt.org/t/is-it-possible-to-compile-miniupnpd-v18-06-7-with-openwrt-v19-0-7-1-firmware/54953
• https://forum.openwrt.org/t/upnp-not-working-on-19-07-0-rc2/51621
• https://forum.openwrt.org/t/compile-different-package-versions-into-firmware/59125

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.

- Device problem occurs on

Tested on both

TP-Link TL-WDR3600 v1 ath79
MikroTik RB750r2 ar71xx

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

Tried to install the following packages;

kmod-l2tp
kmod-l2tp-eth
kmod-l2tp-ip
kmod-pppol2tp
xl2tpd
luci-proto-ppp

- Steps to reproduce

when trying to add a new interface is not there nor dos it not show.

Im not trying to setup a VPN as my ISP UK AAISP is offering this service https://www.aa.net.uk/broadband/l2tp-service

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

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 !

- 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

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`?

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.

The ‘Supplementary Files’ section of lantiq/xrx200 contains only a u-boot-p2812hnufx_ram.

To install OpenWRT on an OEM box a u-boot-nand, uImage and initramfs are needed according to the install instructions.

https://openwrt.org/toh/zyxel/p2812hnu-f1

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.

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?

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

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

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

TLDR:
option encryption ‘none’ works perfectly

option encryption ‘# literally anything else’ wpad assumes encryption = none and everything works
OR
breaks config, mesh interface never comes up
(more than just the UI, also tested with iw)

Router A: ENS202EXT (Atheros/mac80211)
Router B: ENS202EXT (Atheros/mac80211)

Openwrt 18.06.1

wpad 2018-05-21-62566bc2-5 (current as of post)
also tried other versions of wpad (mesh, mesh-openssl)

I have tried both Mesh only and Mesh + AP.
I have not tried wpa_supplicant.

Currently have a mesh point that is working, but unencrypted. Along with an AP

LuCI does not allow the option to add encryption
If I force encryption in the configuration, mesh does not start up.
the package authSAE doesn’t exist anymore...so I assume that I am not missing requirements...

With Unencrypted mesh, LuCI shows association between the routers
Routers show up on each other’s Associated Stations list
everything seems to be working, with manual range testing since I can’t ping between routers, I guess because of firewall.

the most closely related issue I could find is this

another relevant links:
https://forum.openwrt.org/t/setting-up-authenticated-mesh-with-wpad-mesh/12399/49

they claim it’s good but it isn’t
Not sure if this is by design or never resolved.
Please advise how to better show the problem, what to post, etc...
I will be testing this on other routers as well

Working mesh config in wireless:

config wifi-iface

      option device 'radio0'
      option encryption 'none'
      option mode 'mesh'
      option mesh_id '$ID'
      option mesh_fwding '1'
      option network 'WLAN'

Mesh Config that fails:

config wifi-iface ‘SDMesh’

      option network 'WLAN'
      option device 'radio0'
      option mode 'mesh'
      option mesh_fwding '1'
      option mesh_id '$ID'
      option encryption 'psk2+ccmp'
      option key '$KEY'

When running vdsl_fw_install.sh from the ltq-vdsl-vr9-vectoring-fw-installer package, it tries to download https://www.telekom.de/hilfe/downloads/firmware-speedport-w921v-1.44.000.bin which does not exist anymore on the server.

There is a new version (1.45) out though.

Also, I had to install this package (ltq-vdsl-vr9-vectoring-fw-installer) manually, as it is not available in the repos of 18.06.

Warm regards and thanks for the good work!

Tom

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