Gluon (Lede) ipq806x and Archer C2600

[seligenthaler]

@NeoRaider At your request

Hardware: TP-Link ARCHER C2600 v1.1 Gluon: v2016.2-244-g13c61d9

If you reboot the router there is a shutdown with all LED going off. You must use the power switch to bring it back.

Error in config- mode wifi:

500 Interner Serverfehler Entschuldigung, auf dem Server ist ein unerwarteter Fehler aufgetreten. Failed to execute dispatcher target for entry '/admin/wifi-config'. The called action terminated with an exception: /lib/gluon/web/model/admin/wifi-config.lua:19: bad argument #1 to 'txpwrlist' (string expected, got nil)

After the config is done and after rebooting (manualy s.a.) the router comes up and is accessible by SSH. Alfred and batman did not work. (lack of bat0)

The client0 (5GHz) is on purpose manualy disabled. In (/sys/class/net) the virtual bat0-device and primary0-device are missing. The bat0-device section in /etc/config/network is available.

Just for testing and information: You can use the command "batctl if add client1" (does this make sense?) This will create a temporary virtual device bat0 Then you can start alfred /etc/init.d/alfred start

/etc/init.d/alfred: waiting 30 secs for br-client address... /etc/init.d/alfred: starting alfred /etc/init.d/alfred: starting batadv-vis

any suggestions?

documents attached: network wireless logdata (UPDATE v2016.2-244-g13c61d9) c2600.zip

[rotanid]

let's reopen until there's non-BROKEN support. at the moment, @kpanic23 is testing the device with a serial console attached

[kpanic23]

Okay, I have now tested multiple firmwares. Here are my discoveries:

I started with a 2017.1.5 build. Device is booting, crashes on reboot. Client wifi seems to be working, 802.11s mesh isn't. On the status page there's not even mesh listed, only the VPN uplink. 2017.1.5.log

Then I tried building a gluon-next image. Device seemed to lock up after reboot in config mode. After a power cycle the device was bricked. Strangely, using the FFDA firmware seemed to boot, albeit mesh not working, as in above. After connecting the serial console, I noticed that the device is spending about 5 minutes "erasing all blocks after the end marker" on the first boot using my firmware, thus delaying everything, the device seems to be locked up. When powercycling in that stage, flash seems to get corrupted, hence the device gets stuck in bootloop. next.log

After that, @rotanid suggested trying to flash the latest OpenWrt Snapshot, which I did: snapshot.log

Then he told me of his branch (https://github.com/freifunk-gluon/gluon/tree/c2600) using alternative firmware for the ath10k driver (ath10k-firmware-qca99x0-ct), and I cherrypicked his changes onto the latest gluon-next, which seems to run flawlessly, even reboots are working: next-alt-fw.log

Then @rotanid suggested applying the patch to gluon master, which seems to run great, albeit suffering from the crash on reboot issue: master-alt-fw.log

[rotanid]

to summarize: first boot after flashing takes a very long time and only the gluon next branch, based on openwrt snapshots, is working without problems so far. if someone wants support for this device in Gluon 2018.1 he/she would have to fix this reboot issue that @kpanic23 observed. EDIT: updated to what kpanic wrote as an answer

[kpanic23]

Don't get me wrong, flashing works normally. But on the first boot, it takes quite some time, about 300sec or 5min, to erase the unused flash portion behind the image: [ 19.117808] jffs2_scan_eraseblock(): End of filesystem marker found at 0x10000 [ 19.117925] jffs2_build_filesystem(): unlocking the mtd device... [ 19.124022] done. [ 19.131040] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 323.758488] done.

If you configure the node via the config mode web interface and hit "Save and reboot", the reboot does not occur until that process has finished. If you impatiently cycle the power in that state, the flash seems to get corrupted, resulting in a boot loop.

[Casey1979]

I upgraded from the c2600 branch to the latest gluon master from 05.05.2018 (with manual patch to ath10k-ct firmware), the C2600 V1.0 needed its 5 to 6 minutes for the sysupgrade and worked flawless afterwards. Tried a reboot and it came back online as expected.

Then i tried release 10 of the ath10k-ct firmware and at first the router came back online but couldnt start the wifimodules, after a hardreboot it came back without problems and wifi modules online, probably some incompatibility between the old and new wifi firmware on softreboots. Just wanted to confirm that release 10 of the at10k-ct firmware is usuable again if needed.

[rotanid]

i'm not sure if i understood correctly. with Gluon master branch, you don't have any issues at all, even with wifi and 11s meshing? so we don't need to switch to "ath10k-firmware-qca99x0-ct" as i have done in my c2600 branch?

[Casey1979]

No, the ath10k-ct firmware is still a prerequisite in every case as the Qualcomm Firmware hasn't been changed for the last 3 years. Maybe i should have mentioned that manual change again.

[rotanid]

@Casey1979 but the ath10k-firmware-qca99x0-ct included in Gluons master branch is sufficient, you did not need to update it manually from an external source?

[Casey1979]

@rotanid Yes i had no issues with the gluon master and the compiled in ct-firmware (like in the c2600branch). It worked out of the box with the only thing a little bit unpleasant being the long time it needs to reboot after upgrading probably because of the jffs erasing. If there are still issues for others they might be caused by v1.1 hardware then.

[rotanid]

@Casey1979 thanks for your work, i have merged the c2600 branch to include the target/device by default for builds with 11s meshing enabled. 1531571a7e03c505035f4c0b1e7cdb5a5f623d9b

[cfstras]

So... does this mean I should try master with my v1.1 again? Maybe if I show enough patience, it's going to fix itself. Is the "hangs on reboot" issue still present?

[kpanic23]

Well, with serial console attached it seems the device is not hanging on reboot, but rather taking 5 minutes (!) on the first boot to erase the empty blocks