Confirmed, this device has currently only snapshot support.
This means, you either have to make a local copy of the snapshots packages for later installation, or you have to compile the snapshot image yourself and install the packages from your own compilation.
In any way, working with snapshots means a bit more work than working with releases.
The lede-17.01 release branch was split of the master branch in january, since then predominantly bug- and security fixes are backported into it. The device support patches for the TL-WR902AC however are a new feature, requiring new mach files and changes to the existing tplink-safeloader, these are a bit invasive for a backport.
It will be in the next major release (probably 18.x.y), most likely not in future bugfix/ maintenance releases (17.01.x); the next major release shouldn't be that far away though (more than a few weeks, less than a few months | few := 2 < few >=6 /guesswork).
For anyone that wants to open the router case to get at the serial pads take a look at the picture on the FCC website. There are two latches to open (top and bottom edge) and the case itself is partially glued shut, fun...
Until a solution has been found and implemented, that might take a week, a month or eventually even 'never'. A hardcoded size limit for the kernel partition (1344 KB) is pretty limiting (even more stupid from the vendor that it mostly seems to affect rather recent devices), so the underlying issue (the limited mtd size) needs fixing (as the kernel size won't shrink in the future, even if you might still be able to disable some less important features today, the problem would re-occur with the next kernel bump).
I agree this is frustrating -- I was really happy to have the WR902AC running on a snapshot and was looking forward to it being supported in a future stable release. I honestly would like to say a big "thank you!" to the developer(s) who made this possible initially, and I am hoping that there is a not-too-painful way to re-add support for this device.
I'll admit that I am coming from a tech-savvy but non-developer perspective, but I am really curious about something... The TL-MR3020 (4MB flash + 32MB RAM) is still supported in the snapshot and latest stable release (17.01.4), while the TL-WR902AC (8MB flash + 64MB RAM) is suddenly not supported anymore based on the kernel being too large. Why is this? If a standard image including LuCI can fit on the MR3020, why is there an issue with the WR902AC which has twice the memory?
Also, if it turns out that there are problems resolving the memory constraints for the standard support model, can the WR902AC at least be supported in the image builder -- this would allow customized images like what I've been doing for the MR3020 which also fits within the 4MB limit (standard image, less LuCI, and added support for USB and storage/file system stuff such that the extroot process can be done).
It's the partition that holds the kernel that is too small since they
updated to a new kernel, not the entire flash size. From what I can work
out from what's been said, this partition can't be resized easily either
(yet?)
@g0wfv - thanks. That makes sense in terms of the partition. But it raises another question -- is the partition (where the kernel is located) smaller on the WR902AC as compared to the MR3020, or is the size of the 'bundle' (forgive my terminology - I'm referring to the kernel and/or any other files that need to be co-located with the kernel on the partition) larger for the 902AC?
yes, these are nice devices!
the current problem is also effecting other TPLINK devices (CPE510, RE450,...) and caused by TPLINK Bootloader "Safeloader" and Flash Layout.
cite openwrt commit 43384:
The new TP-LINK Pharos series uses a new bootloader, the "TP-LINK Safeloader". It uses an advanced firmware image format, containing an image partition table and a flash partition table
until that problem might be solved long-winded, you may use these devices with an older lede-trunk (before kernel-changes to 4.9) or lede-trunk with disabled CONFIG_KERNEL_KALLSYMS (mentioned above).