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

Last updated: 2019-07-05T21:14:07-07:00

Device Support Status

This device is end-user ready. Wired and wireless works, LEDs work, buttons work, and factory image installation works. Testing has shown the system to be stable under load.

Note that this page only applies to the 1.0R version of hardware. Later hardware revisions are not compatible or supported. See below for more info.

LEDE Project leaders previously rejected all of my patches and I don't see any situation where it's possible to get them merged so I gave up trying. If someone else wants to take my work and move on with it, you are welcome to do so.

I try to update my patches and pre-built images within a week or two of new releases. Watch this thread for future updates and releases.

Currently Known Issues

There are no significant issues for this device.

We can't install OpenWRT/LEDE via the OEM web interface yet because the install will revert after next reboot due to the Safe Upgrade/redundant partition system. However, there is a recovery loader in u-boot which is easier to use anyway, so we can and should install our image that way instead.

The "LED on/off" button can't be made to work because we currently can't shut off the ethernet switch port LEDs. This may be fixed in the future if I am able to support it. The button currently does nothing, but it is configured in the DTS so you can write a script to use it if you want to. This button doesn't work under the OEM image either, so nothing lost.


The latest builds are based off the OpenWRT v18.06.4 release. The patch set for this build is v14.

Minimal image files are here:

Minimal+luci image files are here:

You can download older builds and patches here:

The minimal builds have a basic bare-bone package set. You have roughly 45MB of free space on the overlay to work with. No LuCi web interface or anything else. Install the packages you want with opkg.

Luci builds are like the minimal builds, but with luci-ssl added to provide a web interface.

Recovery and Installation Instructions

Installing OpenWRT/LEDE on this device is very safe, relatively speaking, and it's easy to restore the OEM image if you want to go back.

This device offers three methods for installing images: The uboot http Recovery Loader, the OEM http upgrade tool, and console uboot tftp.

Most users should use the uboot http Recovery Loader because it's easy and safe to use.

DO NOT use the OEM web/http upgrade page at this time. While the OEM upgrade tool will accept and install the OpenWRT/LEDE image, we don't yet support TRENDnet's "Fail Safe"/safeupgrade dual boot system, which means that the device will revert to the old OEM image on the next reboot.

Finally, you can install images via serial console uboot and tftp.

Be sure to download a copy of the OEM installation images in case you want to go back. See my post below for more details.

uboot http Recovery Loader

Connect an ethernet cable from your PC/switch/whatever to any one of the ethernet jacks on the router.

Manually configure your computer with an IP on the network. The router does not offer DHCP services in this mode.

Press and HOLD down the RESET button on power-up for four seconds. Then release the reset button. NOTE: My testing shows the recovery system will not load if one of the ethernet ports doesn't go active/up. Make sure you have a cable plugged into an active port on other side before starting the reboot process.

The recovery page is at

The page should say "TRENDnet Recovery Mode" in blue text at the top and there is a "Choose File" button and "Upload" button.

If installing OpenWRT/LEDE, then upload the factory image file.

If you want to go back to the OEM image, use an OEM firmware file, such as "TEW827DRU_FW100B11.bin".

While the file is uploading, the Internet LED will blink. You can watch progress on the serial console too. Beware the progress/percent animation on the https loader page is fake/placebo.

That's it. OpenWRT/LEDE should be up and running within 30 seconds of uploading the file. The OEM image takes about two minutes and boots very slowly.

OEM http upgrade tool

DO NOT use the OEM http upgrade tool at this time. While our factory image file conforms to the OEM requirements to be accepted and installed, we don't yet support TRENDnet's "Fail Safe"/safeupgrade redundant partition boot loader scheme. The result is that the device will successfully boot into OpenWRT/LEDE after the first reboot, but upon the second reboot it will revert to the old OEM system.

I plan to work on supporting the OEM http upgrade tool and the redundant partition system in the future, but I have not gotten around to it yet.

Console uboot tftp

The serial console on this device is fairly easy to access. A 3.3v/TTL serial port can be found in the corner next to the USB ports. You will need to soldier in header pins. Disassembling the chassis is not difficult.

JP1 = Rx
JP2 = Tx
JP3 = Ground
baud = 115200

uboot gives a 2-second "Hit any key to stop autoboot" prompt, so that's easy to break. No special key combo required.

This device uses a FIT archive file, which includes an installer script, a bootconfig image, and the UBI (kernel+rootfs). All we really need to do is tftp the factory image into memory and execute the script embedded within it.

setenv ipaddr
setenv serverip
setenv netmask
tftpboot 0x42000000 openwrt-ipq806x-trendnet_tew827dru-squashfs-factory.bin
setenv imgaddr 0x42000000
source 0x42000000:script

Future Plans

JTAG recovery is something I want to do some day. It may be possible to recover from JTAG by booting from RAM or programming the NAND flash on this device. I've already experimented with this but I've not yet figured everything out.

Expand the NAND partitions, or otherwise fully use the NAND flash space. The default "rootfs" partition is 64MB in size, but there is 108MB of completely-unused space on the NAND flash, outside of smem/mtd partitions. There is also an additional 64MB of space used by the redundant rootfs_1 partition. It may eventually be possible to have a rootfs file-system of 228MB in size.

Custom u-boot. This depends upon being able to safely recover. We would need either TRENDnet's broken "Fail Safe" system to be fixed, or JTAG recovery. Otherwise the risk of permanently breaking the device is too great.

Boot from USB. This is not possible right now because the OEM u-boot wasn't built with the right modules, but it is possible. This depends upon building a custom u-boot.

Old Development Forum Thread

In May of 2018 the old OpenWRT forum died due to negligent administration. Previously, this is where I had kept a running log of changes and updates for this device, but I am no longer able to update anything on the old forum thread.

This new thread replaces and supersedes any information on the old forum, but you can still read the old thread for background information for how I ported the device, previous issues, and additional technical information.

The old forum thread can be read here:

The original (now potentially invalid) URL to the old forum was:


Today I created this new thread and will try to keep it updated. I finished the work and builds for OpenWRT v18.06.1 and everything looks good.

Recently it had been difficult to test because I didn't have a real test device to work with, but now I do. This should make turnaround time on new builds and testing faster. I may even get back to working on the JTAG and a custom uboot image, which would be pretty cool.


Prior to the OpenWRT v18.06.1 release, there were problems with USB3 flash drives causing problems at boot. This problem seems to be resolved with the introduction of the 4.14 linux kernel in the OpenWRT v18.06.1 release.

This issue had gotten better in later LEDE v17.0 releases, but I was still having some issues with some of my USB3 flash drives. Now the issue seems to be completely resolved. Hopefully maybe.


Below are some interesting commits I noted and some comments regarding them.

commit c52cd4d8c3ab1fd0db8806a5e37158e7022c1c40
ipq806x: fix EA8500 switch control
This doesn't apply to us because our switch control is on gpio6. Unfortunately I accidentally set gpio6 low when making the new DTS, causing myself a lot of unnecessary confusion.

commit e22cc57593127bc888c6b04587a3a2e8e43abe66
ipq806x: dts: Remove device_type = "ethernet-phy"
Get rid of all "device_type = "ethernet-phy";" lines in the DTS

commit 83499bef73cc67b9290360cf76c345a7b3c29f08
ipq806x: force 2nd pci slot into gen1 mode
Apparently pcie1 (the 2.4GHz wifi card) should be in PCIE gen1 mode.
Confirmed in OEM file board-ipq806x.c

commit 16f2befc3cae3b541682644f53f5a81b2aaa9150
ipq806x: drop ubifs support
This patch had me very concerned, but the rootfs UBI mounts fine anyway. Not a problem I guess.
Having "KERNEL_IN_UBI" set or using append-ubi probably signals the need for UBI related config/packages.
I am uncertain about the background on this issue and the patchnotes are nonsensical since the FritzBox is an ipq40xx.

1 Like

If you are upgrading from LEDE v17 to OpenWRT v18, you will probably need to give the sysupgrade command the -F option because of the "Image metadata not found""Image check 'fwtool_check_image' failed." error messages. Be sure to backup your config before doing this, just to be safe. I tested a few forced upgrades on my devices and they worked for me.

Also I noticed that my build system was incorrectly replacing the /etc/opkg/distfeeds.conf file with my own repo, which would prevent downloading of normal packages from the OpenWRT/LEDE repos. You might want to check and replace it with the default repo info.

1 Like

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 10 should be okay. Make sure this runs before fstab and anything related to mounting block devices. 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).