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

OpenedIDCategoryTask TypePrioritySeveritySummaryReported InStatus
18.01.20192062Base systemBug ReportVery LowHighMTU is not set to 1508/1500 when using PPPoEopenwrt-18.06Unconfirmed Task Description

TP-LINK Archer C7, OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152).

Use PPPoE for WAN. Set MTU to 1508.

Observe ifconfig result. MTU is set at 1492, it should be 1500.


config interface ‘eth0’

option ifname 'eth0'
option mtu '1508'

to /etc/config/network, ensure PPPoE MTU (as above) is set to 1508 and restart the network/reboot the router.

Observe ifconfig result. MTU is set at 1500 as expected.

17.01.20192061Base systemBug ReportVery LowLowDifferent names for the same targets, let's decide: ALF...lede-17.01Unconfirmed Task Description

I’m doing a tool that helps for compilation (I’m working based on lede 17.01.4). With these targets I had no problems, the name is the same everywhere. yay!, but with alfa-nx yes, this name is not clear, depends where you find it the name is different

here is ALFA-NX

# dmesg | grep -i board
[    0.000000] MyLoader: sysp=b9c9f1a8, boardp=9b949905, parts=b9c9f188
[    0.000000] Kernel command line:  board=ALFA-NX console=ttyS0,115200 mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6144k(rootfs),1600k(kernel),64k(nvram),64k(art)ro,7744k@0x50000(firmware) rootfstype=squashfs,jffs2 noinitrd

here is ALFANX

make info | grep 'ALFANX' -A2

    ALFA Network N2/N5 board

here is alfa-nx (the output target in compilation)


Do you agree that the same name should be everywhere? I think it should be alfa-nx (as the other profiles are 100% lowercase)

I can solve this locally putting an if statement (doing an exception), but I think it is better to have good universal names everywhere.

15.01.20192059Base systemBug ReportVery LowHighuclient-fetch not working at all on http (not https) co...TrunkUnconfirmed Task Description

I just tried today’s trunk snapshot on my Turris Omnia; everything’s working fine apart from uclient-fetch. I noticed the failure because the ddns updater stopped working. If I install wget, everything works, since wget replaces uclient-fetch. Sample output follows.


root@heimdall:/tmp# uclient-fetch Downloading ‘’ Failed to establish connection


root@heimdall:/tmp# wget –2019-01-15 14:31:09– Resolving
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 204 [text/html]
Saving to: ‘index.html’

index.html 100%[==================================================================================================================================================================>] 204 --.-KB/s in 0s 2019-01-15 14:31:10 (16.4 MB/s) - 'index.html' saved [204/204] root@heimdall:/tmp# Image builder command line: make image PROFILE=turris-omnia PACKAGES="-kmod-ath9k -dnsmasq -odhcpd -odhcpd-ipv6only -odhcp6c -ppp -ppp-mod-pppoe ddns-scripts dnsmasq-full ethtool haveged htop ipset kmod-ipt-raw kmod-ipt-raw6 kmod-nf-nathelper-extra kmod-wireguard nano sqm-scripts tcpdump tor wget wireguard-tools zram-swap"

13.01.20192058Base systemBug ReportVery LowLowath79: valgrind fails to build for mip32TrunkUnconfirmed Task Description

Building the core system (current master)

tip commit:

commit 0e8d5ff0fc1cd8eb5236e6e497c340ceb21340fe
Author: Felix Fietkau <>
Date:   Fri Jan 11 17:23:29 2019 +0100

    mt76: fix typo in version number

    Signed-off-by: Felix Fietkau <>

( only for mip32 (specifically ath79 for a variety of boards) with CONFIG_ALL=y fails on building valgrind with:

{standard input}:91723: Error: opcode not supported on this processor: mips32 (mips32) `floor.l.s $f24,$f24'                    
{standard input}:91740: Error: `fp=64' used with a 32-bit fpu
{standard input}:91744: Error: opcode not supported on this processor: mips32 (mips32) `floor.l.d $f24,$f24'                    
{standard input}:91761: Error: `fp=64' used with a 32-bit fpu
{standard input}:91765: Error: opcode not supported on this processor: mips32 (mips32) `round.l.s $f24,$f24'                    
{standard input}:91782: Error: `fp=64' used with a 32-bit fpu
{standard input}:91786: Error: opcode not supported on this processor: mips32 (mips32) `round.l.d $f24,$f24'                    
{standard input}:91803: Error: `fp=64' used with a 32-bit fpu
{standard input}:91807: Error: opcode not supported on this processor: mips32 (mips32) `trunc.l.s $f24,$f24'                    
{standard input}:91824: Error: `fp=64' used with a 32-bit fpu
{standard input}:91828: Error: opcode not supported on this processor: mips32 (mips32) `trunc.l.d $f24,$f24'                    
lto-wrapper: fatal error: mips-openwrt-linux-musl-gcc returned 1 exit status                                                    
compilation terminated.
/home/daniel/Build/openwrt-ath79/staging_dir/toolchain-mips_24kc_gcc-7.4.0_musl/lib/gcc/mips-openwrt-linux-musl/7.4.0/../../../../mips-openwrt-linux-musl/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
13.01.20192057Base systemBug ReportVery LowMedium/etc/init.d/umount runs after other block devices must ...TrunkUnconfirmed Task Description

Supply the following if possible:

- Device problem occurs on


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

18.06.01 & snapshots

- Steps to reproduce


Setup another block device that should be stopped after umount, e.g. cryptsetup, lvm2, or mdadm

Performing umount as K99umount allows very few things to run afterwards. Ideally, it would be K96umount or K97umount, which would allow for running multiple levels of stops afterwards. There should be at least two levels after umount.

For example, setting K98umount would still cause problems for K99cryptsetup & K99lvm2 because lvm2 must stop before cryptsetup and both must stop after mount.

Changing S99umount may also affect these other packages:

STOP=98 boot
STOP=98 kdump.init
STOP=98 mdadm.init
STOP=99 conserver.init
STOP=99 kismet_drone.init
STOP=99 kismet_server.init
STOP=99 socat.init

12.01.20192056Base systemBug ReportVery LowMediumodhcp misbehaves with multiple MACs for single host on ...TrunkUnconfirmed Task Description

According to the Static Leases section on DHCP's User Guide it should be possible to list several MAC addresses for the same host. Indeed everything works as expected with dnsmasq, and my host gets the expected IPv4 when using any of the listed MAC addresses.

However odhcp misbehaves when I list more than one MAC. With a single MAC on ‘option mac’, my host gets the expected IPv6, with the suffix defined under hostid. If I place two or more MACs on that option, odhcp fails to honor my rules and attributes a dynamic IPv6 with a random suffix.

Here is an example config that produces the erroneous behavior of odhcp.

config host
        option name 'host4'
        option ip ''
        option hostid '4'
        option duid '00112233445566778899'
        option mac '00:11:22:33:44:55, 66:77:88:99:aa:bb'

(Separating the MACs list with either commas and spaces yields the same result. The DHCP User’s Guide has contradictory info on how the list should be separated, but it seems that both work for dnsmasq.)

Showing tasks 1 - 6 of 6 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing