root@LEDE:/tmp# sysupgrade -n -v --force lede-ar71xx-generic-cpe210v2-squashfs-sysupgrade.bin
Image metadata not found
Unsupported image (model not in support-list)
Image check 'platform_check_image' failed but --force given - will update anyway!
killall: watchdog: no process killed
Commencing upgrade. All shell sessions will be closed now.
Connection to 192.168.1.1 closed by remote host.
I got fresh imaged with kernel update and all patches refreshed.
This one should properly fix reference clock detection.
I have not yet tested them and will be unable for a day or two.
So if anybody wants to test,just PM me
First of all, thanks for wrestling this problem to the ground for all that contributed. I have a cpe210 v2.0 device with this productInfo string, not yet accounted for in tplink-safeloader.c . I had to add this "US" flavor to load the image built from the cpe210-v2-unified branch:
CPE210(TP-LINK|US|N300-2|55530000):2.0
I was able to ssh in to the device and appears usable, but this was a limited not-dead-on-arrival test. I'm working to backport to OpenWRT CC release used by the http://aredn.org project.
Also, I noticed the generated image did not have a copyright or signature from a binwalk like v1 images, has only kernel and filesystem.
Yes, would love to put CC behind us. We're a small team, if anyone is interested in moving to 2Ghz ch -2 outside the part 15 noise and would like to help us upgrade, please contact me. We go up to channel 184 in 5Ghz too and wide open 3Ghz channels. I have live links up to 60km and 65Mbps in 10Mhz channel. Our dilemma is many ubnt supported AirMax devices on limited 32M RAM that aren't going to be stable in an upgrade. We may end up with minimal support effort and keeping these devices on CC until they aren't used anymore -- the price is compelling to keep using.
I'm referring to this statement at https://lede-project.org/supported_devices :
"Devices with ≤4MB flash and/or ≤32MB ram suffer from limitations in extensibility and stability of operation." We need to transition to a packaged LUCI UI to lower our memory footprint too, currently based on perl and targeted to end users that have minimal or no network skillsets.
XW boards are all functional in nightly builds. Thanks, glad to hear there is hope that we may be able to upgrade past CC on these devices. Any overhead increase in the footprint would push the device into the instability zone.
We have a perl UI consuming a lot of RAM that desperately needs replaced with LUCI. We've consumed more RAM adding LUA to transition. We extend ath9k to move the devices into FCC part 95 (ham radio) frequencies. The config settings are highly controlled in the UI so that anyone can trust and bring the device live anywhere in the world and using OLSR the device just works on the network--one doesn't have to know anything about networking, OLSR, etc. Type in your FCC callsign and point the antenna, you're functional on a weekend created mesh network in, e.g. Puerto Rico, and can advertise your services. See http://ocmesh.org for examples here in SoCal.
Well,that PERL UI seems to be biggest custom change.
It would be better to move it into separate Luci package which you can simply install.
That would really ease development,ath9k is already separate in backports
