Flyspray:: Flyspray::OpenWrt/LEDE Project: Recently edited tasks 2019-01-18T00:36:09Z FS#2062: MTU is not set to 1508/1500 when using PPPoE 2019-01-18T00:36:09Z 2019-01-18T00:36:09Z

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.

Alec Robertson
FS#2061: Different names for the same targets, let's decide: ALFA-NX, ALFANX or alfa-nx ? 2019-01-17T14:08:56Z 2019-01-17T14:08:56Z

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.

FS#2046: No snapshot builds have been uploaded for ramips/mt76x8 in the past month 2019-01-16T20:28:57Z 2019-01-04T02:15:34Z

The last builds are a month old:

Build failures:

There are mentions of the lack of new mt76x8 builds on the forum and interest in testing the latest mt76 drivers, but no one has filed a bug report yet.

J. D.
FS#2060: Axis IP cameras do not get stateful IPv6 addresses anymore 2019-01-16T12:33:27Z 2019-01-15T20:43:55Z

Same report as in the GitHub issue I created, just opening one here as well in case this tracker is preferred:

Since updating to the latest OpenWRT a few weeks ago, I noticed that my Axis IP cameras do not get a stateful IPv6 anymore, which worked fine before.

Since they receive NOTONLINK responses, I have the feeling that the issue got introduced with commit a2ffc5986cd35bea983b81b28b8a656e3b81fdf1. Might be a shitty dhcpv6 implementation on the camera, I don’t know and I’m not familiar enough with DHCPv6 to see a bad implementation just from looking at the code.

The code of the “mdhcp6” client the camera uses is available in [this git repo]( Not sure if it’s 100% up to date though, but I can reproduce the issue reliably.

Here’s a pcap on my older router running LEDE 17.01.3: [mdhcp6-lede-17.01.3.pcap.gz](
The advertise/request messages don’t contain anything related to the configured IP (via the ‘hostid’ option), but the final reply contains the correct IP.

And here’s a pcap on another router running the latest OpenWRT 18.06.1, coming from the exact same mdhcp6 client (just running on a different machine since they are different networks, hence the different DUID): [mdhcp6-openwrt-18.06.1.pcap.gz](

I’m not sure where the problem is - in the server or the client (more likely, since all other dhcpv6 clients work perfectly fine). But I’d appreciate some help - if it’s a bug in the client (not sending any IA_NA requests in the solicit seems strange to me), I’d like to forward details to the camera vendor. They release firmware updates quite often so I think the chance that they actually fix their dhcpv6 client if it’s broken is quite high.

FS#1973: odhcp6c Isn't able to request a DHCPv6 Prefix from WAN on Linksys WRT3200ACM 2019-01-16T07:02:54Z 2018-11-27T23:47:02Z

Supply the following if possible:
- Device problem occurs on:

Linksys WRT3200ACM

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

All versions were tested and report the same problem

- Steps to reproduce

Flash any version of OpenWRT and watch the log for a message saying:

Thu Jan  1 00:37:11 1970 daemon.err odhcp6c[1573]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)

I’ve searched all over but found no solution.

One thing that I noticed, I configured the device to use vlan 12 as WAN (in switch), but when I type

swconfig dev switch0 show

in the command-line the cpu wan and actual wan port have

Port 4:
        mask: 0x0000: (4)
        qmode: 3
        pvid: 0
        link: port:4 link:up speed:1000baseT full-duplex
Port 5:
        mask: 0x0000: (5)
        qmode: 3
        pvid: 0
        link: port:5 link:up speed:1000baseT full-duplex
Port 6:
        mask: 0x0000: (6)
        qmode: 3
        pvid: 0
        link: port:6 link:up speed:1000baseT full-duplex

As you can see the pvid is 0
Also, the WAN6 interface receives a global ip from the untagged interface, even when asked to be tagged as vlan 12.

PS: once, I got a error saying permission denied instead of address not available.

FS#2059: uclient-fetch not working at all on http (not https) connections. 2019-01-15T14:34:32Z 2019-01-15T14:34:32Z

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"

FS#2058: ath79: valgrind fails to build for mip32 2019-01-13T19:01:52Z 2019-01-13T19:01:52Z

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
Daniel Dickinson
FS#2057: /etc/init.d/umount runs after other block devices must stop 2019-01-13T18:38:36Z 2019-01-13T18:38:36Z

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

Joseph Tingiris
FS#2056: odhcp misbehaves with multiple MACs for single host on DHCP configuration 2019-01-12T16:51:20Z 2019-01-12T16:51:20Z

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

FS#2055: conntrack -f ipv6 -L dumps IPv4 table, not IPv6 2019-01-11T14:08:30Z 2019-01-11T14:08:30Z

Supply the following if possible:
- Device problem occurs on
TP-LINK wdr4300

- Software versions of OpenWrt/LEDE release, packages, etc.
18.06.1 fully up-to-date as of writing

- Steps to reproduce

# conntrack -f ipv6 -L -nv

This produces the IPv4 table, as if

-f ipv6

was not even specified.

Brian J. Murrell