Flyspray:: https://bugs.openwrt.org/ Flyspray::OpenWrt/LEDE Project: Recently edited tasks 2019-01-18T00:36:09Z FS#2062: MTU is not set to 1508/1500 when using PPPoE https://bugs.openwrt.org/index.php?do=details&task_id=2062 2019-01-18T00:36:09Z Alec Robertson 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. Add 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. 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.

Add

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.

]]>
FS#2061: Different names for the same targets, let's decide: ALFA-NX, ALFANX or alfa-nx ? https://bugs.openwrt.org/index.php?do=details&task_id=2061 2019-01-17T14:08:56Z guifipedro 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 ALFANX: ALFA Network N2/N5 board Packages: here is alfa-nx (the output target in compilation) lede-imagebuilder-17.01.4-ar71xx-generic.Linux-x86_64/bin/targets/ar71xx/generic/lede-17.01.4-ar71xx-generic-alfa-nx-squashfs-sysupgrade.bin 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. 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

ALFANX:
    ALFA Network N2/N5 board
    Packages: 

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

lede-imagebuilder-17.01.4-ar71xx-generic.Linux-x86_64/bin/targets/ar71xx/generic/lede-17.01.4-ar71xx-generic-alfa-nx-squashfs-sysupgrade.bin

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 https://bugs.openwrt.org/index.php?do=details&task_id=2046 2019-01-16T20:28:57Z J. D. The last builds are a month old:https://downloads.openwrt.org/snapshots/targets/ramips/mt76x8/ Build failures:http://phase1.builds.lede-project.org/builders/ramips%2Fmt76x8 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. The last builds are a month old:
https://downloads.openwrt.org/snapshots/targets/ramips/mt76x8/

Build failures:
http://phase1.builds.lede-project.org/builders/ramips%2Fmt76x8

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.

]]>
FS#2060: Axis IP cameras do not get stateful IPv6 addresses anymore https://bugs.openwrt.org/index.php?do=details&task_id=2060 2019-01-16T12:33:27Z Adrian Same report as in the GitHub issue I created, just opening one here as well in case this tracker is preferred:https://github.com/openwrt/odhcpd/issues/121 — 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](http://git.savannah.nongnu.org/cgit/mdhcp6.git/tree/src/dhcpv6.c). 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](https://github.com/openwrt/odhcpd/files/2761312/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](https://github.com/openwrt/odhcpd/files/2761325/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. Same report as in the GitHub issue I created, just opening one here as well in case this tracker is preferred:
https://github.com/openwrt/odhcpd/issues/121

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](http://git.savannah.nongnu.org/cgit/mdhcp6.git/tree/src/dhcpv6.c). 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](https://github.com/openwrt/odhcpd/files/2761312/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](https://github.com/openwrt/odhcpd/files/2761325/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 https://bugs.openwrt.org/index.php?do=details&task_id=1973 2019-01-16T07:02:54Z tiagogaspar8 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 0Also, 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. 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. https://bugs.openwrt.org/index.php?do=details&task_id=2059 2019-01-15T14:34:32Z rsalvaterra 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. Bad: root@heimdall:/tmp# uclient-fetch http://perdu.com/ Downloading ‘http://perdu.com/’ Failed to establish connectionroot@heimdall:/tmp# Good: root@heimdall:/tmp# wget http://perdu.com/ –2019-01-15 14:31:09– http://perdu.com/ Resolving perdu.com... 208.97.177.124Connecting to perdu.com|208.97.177.124|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 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" 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.

Bad:

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

Good:

root@heimdall:/tmp# wget http://perdu.com/ –2019-01-15 14:31:09– http://perdu.com/ Resolving perdu.com... 208.97.177.124
Connecting to perdu.com|208.97.177.124|: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 https://bugs.openwrt.org/index.php?do=details&task_id=2058 2019-01-13T19:01:52Z Daniel Dickinson Building the core system (current master) tip commit: commit 0e8d5ff0fc1cd8eb5236e6e497c340ceb21340fe Author: Felix Fietkau <nbd@nbd.name> Date: Fri Jan 11 17:23:29 2019 +0100 mt76: fix typo in version number Signed-off-by: Felix Fietkau <nbd@nbd.name> ( 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 Building the core system (current master)

tip commit:

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

    mt76: fix typo in version number

    Signed-off-by: Felix Fietkau <nbd@nbd.name>

( 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
]]>
FS#2057: /etc/init.d/umount runs after other block devices must stop https://bugs.openwrt.org/index.php?do=details&task_id=2057 2019-01-13T18:38:36Z Joseph Tingiris Supply the following if possible: - Device problem occurs on All. - Software versions of OpenWrt/LEDE release, packages, etc. 18.06.01 &amp; 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 &amp; K99lvm2 because lvm2 must stop before cryptsetup and both must stop after mount. Changing S99umount may also affect these other packages: STOP=98 bootSTOP=98 kdump.initSTOP=98 mdadm.initSTOP=99 conserver.initSTOP=99 kismet_drone.initSTOP=99 kismet_server.initSTOP=99 socat.init Supply the following if possible:

- Device problem occurs on

All.

- 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

]]>
FS#2056: odhcp misbehaves with multiple MACs for single host on DHCP configuration https://bugs.openwrt.org/index.php?do=details&task_id=2056 2019-01-12T16:51:20Z dllud 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 &#8216;option mac&#8217;, 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 '192.168.1.4' 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&#8217;s Guide has contradictory info on how the list should be separated, but it seems that both work for dnsmasq.) 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 '192.168.1.4'
        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 https://bugs.openwrt.org/index.php?do=details&task_id=2055 2019-01-11T14:08:30Z Brian J. Murrell Supply the following if possible: - Device problem occurs onTP-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. 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.

]]>