OpenWrt/LEDE v17.01.5 service release

Installing and Using OpenWrt
1

The OpenWrt Community is proud to announce the Fifth service release of
stable OpenWrt/LEDE 17.01 series, which is the first service release
after the remerger of the LEDE and OpenWrt projects.

OpenWrt/LEDE 17.01.5 “Reboot” incorporates a fair number of fixes back
ported from the development branch during the last 9 months.

Some selected highlights of the service release are:

  • Linux kernel updated to version 4.4.140 (from 4.4.92 in v17.01.4)
  • Security fixes to openssl, mbedtls, wolfssl, samba, dnsmasq, openvpn,
    libunwind and the Linux kernel
  • Update cake scheduler to version from 7. January 2018
  • Update Wireguard VPN software to 0.0.20180519
  • Enable SSL cache in ustream-ssl to improve TLS performance
  • Fixes for building with host glibc 2.27 (Used in Ubuntu 18.04)
  • lantiq: Make ADSL and VDSL SNR configurable
  • x86: Added Spectre and Meltdown mitigations as well as microcode
    loading support
  • Assorted platform fixes for apm821xx, ar71xx, bcm53xx, brcm47xx,
    ipq806x, lantiq, mvebu, ramips, rb532, sunxi, x86 and xburst

For a detailed list of changes since 17.01.4 refer to
https://openwrt.org/releases/17.01/changelog-17.01.5

For latest information about the 17.01 series, refer to the wiki at:
https://openwrt.org/releases/17.01/

To download the v17.01.5 images, navigate to:
https://downloads.lede-project.org/releases/17.01.5/

Have fun!

The OpenWrt Community

11 Likes
3

imagebuilder 17.01.5 return error on Manjaro 17.1.11.
imagebuilder 17.01.4 works fine.

Cleaning up

Activating init scripts

Building images...
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on /home/cy/workspace/lede/imagebuilder/lede-imagebuilder-17.01.5-x86-64.Linux-x86_64/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/root.squashfs, block size 262144.
Pseudo file "/dev" exists in source filesystem "/home/cy/workspace/lede/imagebuilder/lede-imagebuilder-17.01.5-x86-64.Linux-x86_64/build_dir/target-x86_64_musl-1.1.16/root-x86/dev".
Ignoring, exclude it (-e/-ef) to override.
[===============================================================================================================================================================================================================\] 570/570 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
	compressed data, compressed metadata, compressed fragments, no xattrs
	duplicates are removed
Filesystem size 1999.98 Kbytes (1.95 Mbytes)
	35.32% of uncompressed filesystem size (5661.80 Kbytes)
Inode table size 6248 bytes (6.10 Kbytes)
	22.63% of uncompressed inode table size (27613 bytes)
Directory table size 7906 bytes (7.72 Kbytes)
	47.37% of uncompressed directory table size (16689 bytes)
Number of duplicate files found 81
Number of inodes 828
Number of files 571
Number of fragments 21
Number of symbolic links  197
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 59
Number of ids (unique uids + gids) 1
Number of uids 1
Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!
make[3]: *** [/home/cy/workspace/lede/imagebuilder/lede-imagebuilder-17.01.5-x86-64.Linux-x86_64/include/image.mk:310: /home/cy/workspace/lede/imagebuilder/lede-imagebuilder-17.01.5-x86-64.Linux-x86_64/build_dir/target-x86_64_musl-1.1.16/linux-x86_64/root.squashfs] Error 127
make[2]: *** [Makefile:178: build_image] Error 2
make[1]: *** [Makefile:118: _call_image] Error 2
make: *** [Makefile:203: image] Error 2
4

I just updated my TP-Link WDR4300 to 17.01.5 and SQM QoS with cake is broken. I'm using the same configuration I used in 17.01.4 but it does nothing, selecting cake as qdisc is the same as having SQM QoS completely disabled. If I switch to fq_codel, however, SQM works fine. I've set the logs to trace level but there's nothing wrong with SQM, the required modules are properly loaded and the SQM instance is successfully started without any error, but if cake is selected as the qdisc I'll get the same bufferbloat as I would get with SQM disabled...

Has anyone else experienced this issue? SQM QoS with cake is a must for me and I'm seriously considering downgrading back to 17.01.4 where it worked flawlessly if there's no solution for this...

5

As a workaround, run the following command once within the IB/SDK directory:
sed -i -e 's,/\(usr\|lib\|etc\)/,/###/,g' ./staging_dir/host/lib/libc.so.6

6

I can confirm Cake discipline in SQM doesn't work too on Home Hub 5A for 17.01.5.

fq_codel works fine.

Is this similar to the issue that afflicted 18.06.0-rc1 for MIPS platforms?
https://forum.openwrt.org/t/sqm-doesnt-seem-to-be-working-in-18-06-0-rc1/16915/23

Update: Following @hnyman post further down this page, I installed 17.01 r3925 snapshot, and can confirm 'cake' appears to be working.

1 Like
7

Thanks, works now!

8

@ldir has pushed cake fixes to 17.01 branch after the 17.01.5 release tag, so it is possible that there has been an issue with cake on 17.01.5, but that it would have been fixed for subsequent 17.01 builds.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/lede-17.01

9

PLease post the output of:
tc -s qdisc
with cake/piece_of_cake, I assume you hit an already fixed bug, but we might find a way to work around this (IIRC the bug is depending on the number of keywords passed to cake, or rather the aligmnent of Netlink attributes that can be affected by the number of keywords).

10

It's a 'kernel version v kmod version v userspace tc util' API mismatch issue caused by just missing the 17.01.5 tag (I think) So userspace is speaking 'newer cake' (actually upstreamed-cake API) whilst kmod is speaking 'older style'. As I understand the openwrt release/build mechanism, the kernel & hence kmods (think cake) stay at the tagged release point, but userspace utilities (think tc) follow package bumps. So even if kmod & userspace are bumped, unless a new release is made the kmods will still be at the old version.

People who build their own will of course be happy because they get latest kernel (&kmod) and latest userspace packages too.

This sadly is unavoidable API hell due to the upstreaming requirements...namely passing of nested netlink attributes, which itself exposed a kernel 64 bit attribute data alignment bug in k4.9> for MIPS. That bug doesn't exist for k4.4 'cos netlink at that point didn't worry about trying to align 64 bit data values to 8 byte offsets.

For the moment I have reverted both kmod & tc bumps. This means the userspace packages should sort themselves out in a day or so. @jow and I are trying to come up with a cunning plan for 17.01.6

1 Like
11

@ldir thanks for clearing this up, so ATM the recommendation is simply do not use cake on 17.01.5 then?

Update, ATM meaning the next 24 hours only :wink:
@ldir, @jow thanks for the quick reaction!

12

The recommendation is to wait for 24 hours, then opkg install the up- (downgraded) tc package.

3 Likes
13

My mistake in this is that I shouldn't have felt pressured into committing the tc & cake bumps. Just after release tag was the worst time to do it. Lesson learned (hopefully)

2 Likes
14

Upgraded my TP-Link WDR4300 to this release, from v17.01.4, no problems.
Just had to reinstall my custom packages (upnp, ddns and sqm), and good to go!

(Update: I couldn't wait and updated the TP-Link WDR 4300 to 18.06 rc2 - which went smooth as well.)

15

Upgraded WRT3200ACMv1 from .4 without issue. Kept settings.

P.S. Anyone tried 18.06.00 RC2? I might give it a go on a backup WRT1900ACSv1

16

No idea about WRT1900, but I've been running rc1 and rc2 on WRT32000 (with eduperez'es updated WiFi drivers) and both release candidates have been great for me.

1 Like
17

thanks for fixing it :slight_smile:

18

@stangri Thanks. Loaded 18.06.00 RC2 on WRT1900ACSv1. Kept settings. So far so good.

19

17.01.05 is installed and working without problems on these TP-LINK access points:

TL-WR741ND version 4
TL-WDR3600
TL-WDR4300

No problems observed.

Thanks everyone for the excellent work!

20

sit (6in4 kernel driver) is broken in 17.04.5, because an upstream commit.
It should be fixed in 4.4.143. The patch is pending now.