[Testing] lede-17.01 security backports for 4/32 devices

Noticed the 432 devices support is near the end so I've decided to give it a try backporting security related patches to LEDE-17.01 abandoned branch https://github.com/maurerr/openwrt
I've generated TEST images for ar71xx and rt305x architectures for now:
https://maurerr.github.io/lede-17.01.ng-ar71xx/
https://maurerr.github.io/lede-17.01.ng-rt3050/

Before testing make sure you back up your config as described here or better test it on a spare 432 device.

I need your feedback before adding more security related patches (mostly kernel and CVEs)


LE - last update 25.11.2020 (images built on 19.11.2020)

6 Likes

Glad to see people aren't forgetting our loved cheap routers! Thanks for the time you put into this.

1 Like

I've tried the version but it doesn't pass any traffic from the WAN to LAN network. I don't know why. I have normal internal LAN traffic. I didn't see any error messages in system log. I can ping the WAN from the router but not from any other LAN client.
I had to revert to 18.06.8 in order to recover the internet connection for LAN clients.

I've only tested the code on a tl-wr842v1 but didn't had any of those problems.
thanks for the feedback though !

Don't like replying to myself but just finished building and uploading ramips/mt7628 4/32 devices to https://maurerr.github.io/lede-17.01.ng-mt7628/ (also available via plain http for easier download on device's /tmp via curl/wget)
tested only on tp-link tl-wr841n-v14 and tl-wr840n-v6
waiting for testers for Asus rt-n10p-v3/rt-n11p-b1/rt-n12-vp-b1

1 Like

"...It is better to have an old version on Openwrt, than a stock oem insecure oem version..." :+1: :+1: :+1:

Really thanks for the support @maurer

Will test on a WR841N v14.

1 Like

I tried https://maurerr.github.io/lede-17.01.ng-mt7628/lede-ramips-mt7628-tplink_tl-wr841n-v14-squashfs-tftp-recovery.bin on a tl-wr841n-v14 and, unless I'm doing something wrong, I don't see it coming back. (I see the tp_recovery.bin being transferred on the wire, but no link appears up after reboot).

let me know if I can provide further debug information.

edit: for the record, your 18.06 build from here Support for TL-WR841N v14 works like a charm.

thanks for the test - yes a serial console log output would be most useful in this case

❯ sha1sum tp_recovery.bin
e0dc3c9a8b9ccec05b222bde30e1ecd2c2a73fa9  tp_recovery.bin

the following loops after the flashing is complete:

[04080C0C][04080C0F][8B8A0000][28273D3C][0028273A]
DU Setting Cal Done


U-Boot 1.1.3 (Mar 19 2018 - 15:36:42)

Board: Ralink APSoC DRAM:  32 MB
relocate_code Pointer at: 81fc0000
******************************
Software System Reset Occurred
******************************
flash manufacture id: ef, device id 40 16
find flash: W25Q32BV
============================================ 
Ralink UBoot Version: 4.3.0.0
-------------------------------------------- 
ASIC 7628_MP (Port5<->None)
DRAM component: 256 Mbits DDR, width 16
DRAM bus: 16 bittal memory: 32 MBytes
Flash component: SPI Flash
Date:Mar 19 2018  Time:15:36:42
======================================== 
icache: sets:512, ways:4, linesz:32 ,total:65536
dcache: sets:256, ways:4, line2 ,total:32768 

 ##### The CPU freq = 580 MHZ #### 
 estimate memory size =32 Mbytes
RESET MT7628!!!!!
continue to starting system.
 0 
disable switch phyport...
   
3: System Boot system code via Flash.(0xbc010000)
do_bootm:argc=2, addr=0xbc010000
## Booting image at bc010000 ...
   Uncompressing KerImage ... LZMA ERROR 1 - must RESET board to recover

let me know if you upload something new

2 Likes

Hi, thanks for your efforts on this, any developments with regards to the boot loop issue?
I'm tempted to try out the firmware and if stable go for a RAM mod...

Maybe you should consider to sending it to OpenWrt develoeprs to see what they will say about it.

I've rebuilt ar71xx and rt305x images with latest CVE and kernel updates but on mt7628 I get the same reboot loop now (I test on TP-link tl-wr840n v6.2)
My usb serial console broke so I'll need some time to repair my test setup to debug this reboot loop.

hmm do you think it makes sense to help you bisect the changes applied in your branch? if you have some notes about the last working commit it can help reducing the number of steps.

Thanks for the offer but I cannot pinpoint a specific git tag as current release in https://maurerr.github.io/lede-17.01.ng-mt7628/ works for my tl-wr840n v6.2 (I don't own a tl-wr841n v14.1 anymore) so the "heavy lifting" still needs to be done by me