TRENDnet AC2600 (TEW-827DRU v1.0R)

I created a new "freespace" partition in this DTS file for this latest release (OpenWRT v18.06.01/LEDE v17.01.06).

This device uses a raw 256MB SLC NAND flash chip for storage. Each UBI is 64MB in size, plus another 20MB in uboot partitions and other stuff, and finally 108MB of completely unused space on the end of the chip. This previously unused space is the new freespace partition.

This partition will probably show up as mtd 15.

Feel free to do whatever you want with this partition. The OEM system doesn't use it, and uboot doesn't know about it.

Since this partition is on raw SLC NAND, we need to use a filesystem which specifically supports it. In my case I wanted to do this with UBIFS, which is unfortunately much more complicated and troublesome than it should be. Alternatively, you could use jffs2, but that has it's own issues which I don't address here.

Here's instructions for how I did it:

opkg update
opkg install ubi-utils

cat /proc/mtd
ubiformat /dev/mtd15
ubiattach -p /dev/mtd15 -d 1
ubimkvol /dev/ubi1 -N freespace -m
ubinfo -a -d 1

# NOTE: OpenWRT/LEDE doesn't distribute mkfs.ubifs.
# The mount command will automatically format the new filesystem with a new blank fs.

mkdir /mnt/freespace
mount -t ubifs ubi1:freespace /mnt/freespace

Automatically mounting this new filesystem at boot is unfortunately not so simple. The problem is that we need to run the ubiattach command before filesystems get mounted. This is similar to the way LVM needs to run lvscan.

Thus, we need to create an init script that will start the UBI at boot:

echo "#!/bin/sh /etc/rc.common

start () {
        ubiattach -p /dev/mtd15 -d 1 || return 2

stop () {
        ubidetach -p /dev/mtd15 || return 2
}" > /etc/init.d/ubi_local

# Set file exec perms
chmod ugo+rx /etc/init.d/ubi_local

# Create the /etc/rc.d entries
/etc/init.d/ubi_local enable

START at 15 should be okay. That's what LVM uses. But if you need it mounted earlier, try 9. Also note that we don't seem to need a STOP, as the kernel seems to automatically run ubidettach on reboots.

If you don't already have the "block-mount" package installed, you will need to do that. See the fstab wiki doc for more info:

Additionally, if you want to mount via UUIDs like I do here, you will need to install the "mount-utils" package. And, though not required, installing the "blkid" package might be a good idea.

Then add your new filesystem to the /etc/config/fstab file with something like this:

# freespace UBI
config mount
	option target		/mnt/freespace
	option uuid			45dc0c61-4dd4-4b8d-92da-246a35be8c8e
	option fstype		ubifs
	# option options	rw,sync
	option enabled		1

One problem I have with this method is that the init script needs to be re-enabled after each sysupgrade because the /etc/rc.d/ links are wiped on sysupgrade. Normally a package will have an entry in "/etc/uci-defaults/" to do this automatically during the sysupgrade run-once, but we don't have that. I guess we could add "/etc/rc.d/S15ubi_local" to our "/etc/sysupgrade.conf" file, but that feels pretty hacky.

This freespace partition should survive all factory reinstall/flash-overwrites and sysupgrades, including OEM factory image restore.

Also don't be like me and freak out when you manage to copy 200MB of log files into your new 86MB partition. UBIFS includes automatic transparent compression, which makes estimating usage difficult/interesting.

1 Like

This has been fixed for most affected devices (e.g. nbg6817 and r7800) with these patches:

Those three patches should do the right thing for you by default as well, if the necessary GPIOs are indeed controlled by ath10k. Before the third patch you'd need to manually define the trigger in target/linux/ipq806x/base-files/etc/board.d/01_leds, e.g. by something like:

ucidef_set_led_wlan "wlan2g" "WLAN2G" "ath10k-phy1" "phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "ath10k-phy0" "phy0tpt"

With the third patch applied, it should work by default, without a need for manual configuration.

Either way, the necessary LEDs should be exposed via /sys/class/leds/:

# ls -1 /sys/class/leds/

Hey, thanks slh! I'll give those a try here sometime soon. I knew I had seen those somewhere but I've been too busy to watch all of the progress and stuff going on with the other ipq806x devices lately.

I also want to see about getting some of those thermal sensors working.

Thermal should have been functional for a long time, way before 18.06.x, cat /sys/class/thermal/thermal_zone*/temp (in millidegree Celsius).

Be wary that TRENDnet has decided to release a v2.0R of the TEW-827DRU. All of my work and the information here centers around the TEW-827DRU v1.0R.

I don't know anything about the v2.0R yet, but I suspect it has completely different hardware inside and you should not try to install any of these images on the v2.0R.

The TRENDnet website says the v1.0R was discontinued on "11/2/2017", and I noticed the Amazon USA product page was changed to the v2.0R in April/May 2018.

While the chassis looks similar between the v1 and v2, an easy way to tell the difference between them is the number of USB ports. The v1.0R has two USB3 ports while the v2.0R only has one.

TRENDnet OEM images

OEM Product Page =

I've documented the OEM releases here:

Archive file: fw_tew-827dru_v1(1.00b11).zip
Firmware file: TEW827DRU_FW100B11.bin
Firmware Version: 1.00b11
Release Date: 11/2015
Download URL:
sha256sum: 751e8d997230bc14baf9bd7c85e9e8cd7e2646d0948964707f30fda8b336f8dc

Archive file: fw_tew-827dru_v1(1.02b02).zip
Firmware file: TEW827DRU_FW102B02.bin
Firmware Version: 1.02b02
Release Date: 11/2016
Download URL:
sha256sum: fd70b23a27bf85d3ce0295bcc4a90eebe521c089efcbcf8ef1e00187bf6b609e

Archive file: fw_tew-827dru_v1(1.03b02).zip
Firmware file: TEW827DRU_FW103B02.bin
Firmware Version: 1.03b02
Release Date: 1/2018
Download URL:
sha256sum: 8fb5912754d6927f4172f6377ddadc8214cf1e7937502c3f383dfc053f6eb05d

Archive file: fw_tew-827dru_v1(1.04b01).zip
Firmware file: TEW827DRU_FW104B01.bin
Firmware Version: 1.04b01
Release Date: 9/2018
Download URL:
sha256sum: 22ad93ba1dd0e364f9052aea41917919ea031be7949192897196139312d20332


The first/original release (1.00b11) has a full firmware image set in it's FIT file, which includes all 13 of the NAND partitions except for the uboot environment part. The newer update releases only have a UBI image within them.

This means that if you want to restore the OEM image to your device, you must first flash the original release image (1.00b11) and then flash the latest updated image. This is necessary to restore a valid bootconfig before updating to the latest release.

Fortunately it looks like you can still download previous image files from TRENDnet's web page, even though they don't have direct links to them published.

1 Like

A very quick and casual look at the TRENDnet OEM firmware (kernel 3.10.14) for the v2.0R suggests a Mediatek mt7621 SOC with mt7615 wlan (not supported by mt76) and much smaller spi-nor flash (probably 16 MB).

I made new builds based on LEDE v17.01.6, which was released recently.

The patch set used for this build was v8. No changes were needed.

Minimal factory image is here:

Minimal sysupgrade is here:

Minimal+luci factory image is here:

Minimal+luci sysupgrade is here:

I just relized that somehow I missed adding the "append-metadata" make target for IMAGE/sysupgrade.tar. The result was the following error when trying to use sysupgrade to upgrade a device:

root@openwrt:/tmp# sysupgrade openwrt-ipq806x-trendnet_tew827dru-squashfs-sysupgrade.bin
Image metadata not found
Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware
Image check 'fwtool_check_image' failed.

I will produce some new builds and patches which corrects the issue soon.

If you run into this issue, it's safe to use -F with sysupgrade.

Here are new builds which fix the missing metadata problem on sysupgrade files.

Patch set v12 is for LEDE v17.01.06:

Patch set v13 is for OpenWRT v18.06.01:

It looks like TRENDnet published a new OEM firmware update version 1.04b01 last week on the 20th. I have updated the OEM info post. It doesn't sound very interesting. Just a single security update in dnsmasq.

I just published some new builds which fixes issues related to installing packages with opkg. Previously there were problems with the opkg feeds and my public package repos. These issues should now be fixed.

There was no changes to my patch sets. These issues were related to my build system and the package feeds listed in "/etc/opkg/".

I made a test build of the current master branch and 802.11/wifi LEDs do indeed work automatically.

There is a minor error with my patch set v13, just do a "git am --3way" to clear it up automatically. I'll fix it on the next release.

Be warned that I saw several errors and firmware crashes related to the ath10k driver on this build. All I had to do was "wifi down" / "wifi up" a few times to get it to crash.

Master recently moved to a 4.19~ based backports package - and at the same time also switched from ath10k to ath10k-ct, there are still some rough edges about that.

Testing ath10k instead of ath10k-ct is relatively easy, reverting to the older backports a little more involved.

Thanks for the info. I am somewhat aware of the history of the -ct driver/firmware and the current move to make it the default but I wasn't aware that had already happened. Unfortunately I don't have the time to follow everything on the mailing lists or what goes on here on the forums regarding all the other ipq806x devices, but I go and read up every once in awhile.

I recently got another tew827dru that I can use for testing, so that helps. I just wish I had the time to play with it more.

I have had three system crashes in the last two months on OpenWRT v18.06.1. If stability is a requirement, you might want to stick with the LEDE v17.01.06 release.

With flow-offloading enabled or disabled?

I've seen issues (as in spontaneous reboots, not just on ipq806x but also on lantiq) with flow-offloading enabled, while my nbg6817 is stable with it disabled (default).

Interesting. Thanks for the tip!

I was going to tell you I had it disabled, but I looked and sure enough the kernel module is loaded and I must have included it in my image or something at some point. I don't actually have it configured though, so it's not even doing me any good.

I'll blacklist them and reboot.

Was thinking of buying this router but looks like you have stopped supporting it.

I support it now as much as I ever did.

There hasn't been a new OpenWRT release in several months now so there isn't anything to work on in regards to updates. You can use the opkg system to get the newest packages, and unlike many other devices this one has plenty of local storage space for the updates.

The last time I was playing around with the current master branch things were not stable due to some major changes so I don't recommend it.