Yes, but you might just wait until the true stable release comes out (currently release candidate 1, hopefully full stable release in the next week).
I haven't tried, but in theory, yes, it should be possible to flash back
Yes, you can have client (sta) mode and AP mode simultaneously running on the same radio. Also, there are 2 radios (2.4GHz and 5GHz), so you could use 1 each, if you wanted.
The caveat to 3 is that the chipset (at least when using OpenWRT) doesn't support bridging the client mode radio for a wireless-to-wired/wireless bridge (bridging eth0 and radio is fine when using AP mode; don't know if it will work for client bridged to AP if you don't bridge against ethernet). You can use relayd to effectively bridge the networks if you need to have a seemingly transparent repeater. However, this is technically a routed mode so there is a performance penalty. If you use the client mode as a WAN or any normal routed mode, everything should work as desired.
18.06 RC1 has LuCI installed already so I didn't have any hassles at all, I just installed it, logged in with my Web Browser and configured the Wireless Interfaces.
This is 10 times better than how it was with the TP-Link firmware. Amazing.
I promise this is the last reply to myself, but just for anyone else thinking of doing this
a) It works perfectly
b) You can install upnp, openvpn and the CAKE SQM. This gives you a truely powerful, portable router in your pocket. This device is now worth twice as much with LEDE on it.
Thanks again to all the devs who made this happen, I am going to buy another one it's that good.
It seems wr902ac-v1 is broken now kernel 4.14 is default and 4.9 support has been removed. I get an 'os-image partition too big' error. Is there an easy work around for this?
I have a unit working with 18.06.1 -- I don't recall off hand what kernel that build uses, but I have had success and therefore would recommend using the stable release build unless you need snapshots for a specific reason (and/or if you're helping with the development -- in which case, thank you for your efforts!).
I was thinking more like a way to resize the kernel partition without a custom uboot. Or just how to revert that commit locally or something.
I'm not really sure why 4.9 support had to be removed entirely anyway. Are devices like this going to be dropped for 19.01? I assume so if 4.14 is going to be a requirement for the next release.
If you know how to poll the slider status on that model, I can add support for it to Slider-support package
I originally saw this when you posted it and meant to reply then, but forgot ....!!
Scroll back far enough in this thread, and you'll see something a couple of us worked on back in July 2017! it was a bit of a hack, but I assume the info you'd need would be in among this lot....
Share ETH:
root@lede:~# grep 'sw[12]' /sys/kernel/debug/gpio gpio-14 ( |sw2 ) in lo gpio-17 ( |sw1 ) in hi
Share Hotspot:
root@lede:~# grep 'sw[12]' /sys/kernel/debug/gpio gpio-14 ( |sw2 ) in hi gpio-17 ( |sw1 ) in lo
AP/Rng Ext/Client
root@lede:~# grep 'sw[12]' /sys/kernel/debug/gpio gpio-14 ( |sw2 ) in hi gpio-17 ( |sw1 ) in hi
Hopefully, you'll include support for this router; I just had a good read up on your package (and travelmate) and think it would solve a couple of issues I'm experiencing!
I ended up using git checkout to go back to the commit before 4.9 support was removed. Reverting a commit was a bit over my head so guess it'll stay there for now.
Kernel 4.14 support is mandatory for all targets in 19.01 (and yes, that is difficult for many ar71xx devices and may be fatal for most 4 MB flash ones), with a little luck you may be able to resize the split between kernel and rootfs partitions - and ideally make it dynamic.
I was small enough when I first tried it in the days after 4.14 support was added so it's probably only slightly too big. I went back to 4.9 because the 5GHz interface wouldn't show up at the time (tried qca and ct).
Fingers crossed there will be a solution eventually. It works for now though so I'm not too fussed really. I was only trying 4.14 to see how much of a difference offloading made, I can only get about 15Mpbs through it as is.
Dynamic sounds like it would be handy, has that been implemented elsewhere in OpenWrt?
It's used by several ar71xx devices, those that only use a "firmware" partition instead of dedicated "kernel" and "rootfs" ones. You will also find a couple of devices migrating to that in the git commit history, but it depends on the hardware in question, kernel&rootfs need to be behind each other, in this order, without gaps inbetween - and the OEM bootloader mustn't puke when confronted with that. While the change itself is simple, it needs to be tested on the actual hardware, by someone who can recover it when it bricks.
I'll have to check but won't be home for another few days. Off the top of my head probably just luci-app-sqm and luci-app-wireguard so whatever kmods depend on them (sched, cake and wireguard?).
Does that answer the question? I can post my config when I get back if you need more
Edit: By the way, it appears the buildbot failed again after the fix
One thing realised I should have clarified. When it fails it doesn't actually fail and stop. It just says 'os-image partition too big' during the image creation stage and that it is ignoring it. The end result is that it just doesn't create the sysupgrade and factory image. Without 'make V=s' and the lack of images you wouldn't notice.
@xback I tested an image built from your staging tree but it wouldn't boot. I used the sysupgrade image, should I have used factory?
I would have tried to get logs but the board doesn't have headers on serial (just pads). I've recovered it now so if I should have used factory let me know and I'll try again.