LEDE v17.01.4 service release

The LEDE Community is proud to announce the fourth service release of stable LEDE 17.01 series.

LEDE 17.01.4 “Reboot” incorporates a fair number of fixes back ported from the development branch during the last two weeks.

Some selected highlights of the service release are:

Linux kernel updated to version 4.4.92 (from 4.4.89 in v17.01.3)
Security fixes to brcmfmac, hostapd, mac80211, toolchain/gdb and the Linux kernel
Assorted platform fixes for ar71xx, bcm53xx, ramips and x86

While this release includes fixes for the bugs in the WPA Protocol disclosed earlier this week, these fixes do not fix the problem on the client-side. You still need to update all your client devices. As some client devices might never receive an update, an optional AP-side workaround was introduced in hostapd to complicate these attacks, slowing them down. Please note that this does not fully protect you from them, especially when running older versions of wpa_supplicant vulnerable to CVE-2017-13086, which the workaround does not address. As this workaround can cause interoperability issues and reduced robustness of key negotiation, this workaround is disabled by default.

Due to the version bump of toolchain/gdb to 8.0.1, at least GCC 4.8 is now required to build LEDE.

For a detailed list of changes since 17.01.3 refer to https://lede-project.org/releases/17.01/changelog-17.01.4

For latest information about the 17.01 series, refer to the wiki at:

To download the v17.01.4 images, navigate to:

As always, a big thank you goes to all our active package maintainers,
testers, documenters and supporters.

Have fun!

The LEDE Community


You can easily find the direct link to the download for your device by searching https://lede-project.org/toh/views/toh_fwdownload

Use the white fields on top of the columns to filter for your model.


is there a way to subscribe only to release topics and not everything in the forum ?

Maybe it should be noted, too, that the PeerKey vulnerability (CVE-2017-13086) has little practical impact, because most devices do not support this feature [1], as those who discovered those vulnerabilities note in their research paper [2]:

However, we did not find other devices that support PeerKey. As a result, the impact of our attack against the PeerKey handshake is rather low.

Are there any other specific attack vectors that this AP-side workaround does not address?

[1] http://lists.shmoo.com/pipermail/hostap/2015-June/032952.html
[2] https://papers.mathyvanhoef.com/ccs2017.pdf

EDIT: My comments about the PeerKey vulnerability don't apply here! CVE-2017-13086 is actually about TDLS. Sorry for the mixup.

I subscribed to be notified of changes to the releases wiki page, so far it worked fine.

On a related note -- kudos to devs for releasing .3 and .4 with major security fixes so quickly, job well done on the infrastructure so that you could turn on a dime.

Best to ask the author of the workaround, (or) on the hostap mailing list. I only backported it to LEDE. Additionally it was suggested on IRC to mention that it does not fully protect against all KRACK vulnerabilities.

Thank you LEDE developers and community for a quick rollout of WPA patches to 17.01.X and release of 17.01.4. I've installed 17.01.4 on WRT1900ACv1, WRT1900ACSv1, and WRT3200ACM and all have been working. My network has been more reliable since moving away from DDWRT a few months ago.


I have a number of embedded clients which WPA patches are still in progress, so I enabled wpa_disable_eapol_key_retries on all SSIDs. I have an app on several wireless tablets which maintain a persistent connection to a wired home automation controller. I noticed the connection would break and had to refresh the client app. Since most of my wireless clients (tablets and laptops) have the WPA patches (iOS 11.1b3, macOS 10.13.1b3), I disabled wpa_disable_eapol_key_retries on that particular SSID and all my other wireless clients are on a different SSID. I have not observed the client app persistent connection loss on my wireless tablets since. Based on comments on this forum and in the source code itself, I assume this behavior is a possible side effect of enabling wpa_disable_eapol_key_retries. Precisely why it is disabled by default.

For those wishing to set wpa_disable_epol_key_retiries I found this page helpful: https://lwn.net/Articles/736950/rss

Will the f2fs still produce oopses, or has this been fixed also?

I mean this:
[   15.831399] WARNING: CPU: 0 PID: 433 at fs/f2fs/segment.h:609 build_segment_manager+0x878/0xe44 [f2fs]()
[   15.841045] Modules linked in: usb_storage sd_mod scsi_mod f2fs ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common cryptomgr aead crypto_null crypto_hash
[   15.856890] CPU: 0 PID: 433 Comm: block Not tainted 4.4.71 #0
[   15.862729] Stack : 803ece5c 00000000 00000001 80440000 87d70284 80436e43 803ce0a4 000001b1
[   15.862729] 	  804a378c 0000039f 0000001e 874fb400 874fb400 800a7844 803d37a0 80430000
[   15.862729] 	  00000003 0000039f 803d1bac 87493bec 874fb400 800a57c0 803d5f40 00000000
[   15.862729] 	  00000001 80201100 00000000 00000000 00000000 00000000 00000000 00000000
[   15.862729] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   15.862729] 	  ...
[   15.899131] Call Trace:
[   15.901640] [<800a7844>] vprintk_default+0x24/0x30
[   15.906504] [<800a57c0>] printk+0x2c/0x38
[   15.910593] [<80201100>] serial8250_get_mctrl+0x3c/0x54
[   15.915898] [<80081c60>] warn_slowpath_common+0xa0/0xd0
[   15.921214] [<801b2dfc>] dump_stack+0x14/0x28
[   15.925639] [<80071ea8>] show_stack+0x50/0x84
[   15.930070] [<80081c60>] warn_slowpath_common+0xa0/0xd0
[   15.935407] [<8751ec88>] build_segment_manager+0x878/0xe44 [f2fs]
[   15.941605] [<80081d18>] warn_slowpath_null+0x18/0x24
[   15.946738] [<8751ec88>] build_segment_manager+0x878/0xe44 [f2fs]
[   15.952932] [<8750c6f0>] get_meta_page+0x100/0x300 [f2fs]
[   15.958433] [<87509d74>] f2fs_commit_super+0xa90/0xf34 [f2fs]
[   15.964267] [<801091e8>] sget+0x31c/0x358
[   15.968353] [<87509390>] f2fs_commit_super+0xac/0xf34 [f2fs]
[   15.974098] [<80109500>] mount_bdev+0x164/0x204
[   15.978710] [<801b43ac>] ida_get_new_above+0x5c/0x1e4
[   15.983837] [<801041e0>] __kmalloc_track_caller+0xb0/0x1b0
[   15.989421] [<87508258>] f2fs_sync_fs+0xf0/0xb58 [f2fs]
[   15.994731] [<87509390>] f2fs_commit_super+0xac/0xf34 [f2fs]
[   16.000490] [<801222ac>] alloc_vfsmnt+0x164/0x1ac
[   16.005268] [<8010a2c4>] mount_fs+0x20/0xb8
[   16.009520] [<8012235c>] vfs_kern_mount+0x68/0x114
[   16.014383] [<80125014>] do_mount+0x9d0/0xb38
[   16.018814] [<8012453c>] copy_mount_options+0x3c/0x12c
[   16.024038] [<8036b884>] sha_init+0xa14/0x1294
[   16.028552] [<80125410>] SyS_mount+0x94/0xd8
[   16.032881] [<80072b50>] do_ri+0x8c/0x2bc
[   16.036954] [<80062c2c>] syscall_common+0x30/0x54
[   16.041734]
[   16.043242] ---[ end trace 2b1d1cdb0fcbd097 ]---

Or you can simply update LUCI admin interface to reveal a check box under Wireless Security

Use the command line to upgrade.
opkg update
opkg list-upgradable
opkg upgrade luci-mod-admin-full

I only want to say
for your superb work.

Just sys-upgraded with "keep settings"
WRT1200-AC from 17.01.3
C7-v2 from 17.01.3
WNDR3700v2 from CC15..

After installing the missing packages everything worked fine.

1 Like

hello all

its posible install on tp-link TD-W8970, via web upgrated?
or necesary over serial cable? where can buy this cable without having to weld?

thanks team

See the LEDE page for the TD-W8970...


You might consider using TFTP rather than the web GUI.

TFTP tutorials…


thanks, it only posible by serial cable?

TFTP doesn't require a serial cable.

ok but, im conect to telnet is not posible execute coman, only a basic internal command.

You might want to open a new topic for your question regarding installation of LEDE on TD-W8970.

I created a login here with a single purpose - to say thank you guys :heart: You rock! :rocket:

1 Like

So, I took the question to the hostap mailing list and there were two issues mentioned the workaround doesn't cover so far, TDLS and WNM Sleep Mode handshakes [1] [2]. Jouni Malinen made suggestions how these two attack scenarios could be further complicated, so I posted patches on the lede-dev mailing list, to incorporate those suggestions into LEDE [3].

Btw, it turned out that I confused two CVEs before, so the aforementioned CVE-2017-13086 isn't about the PeerKey handshake but really about TDLS.

[1] http://lists.infradead.org/pipermail/hostap/2017-October/038005.html
[2] http://lists.infradead.org/pipermail/hostap/2017-October/038007.html
[3] http://lists.infradead.org/pipermail/lede-dev/2017-October/009521.html