Gluon: Add Support for TP-Link TL-WR841N (v13)

[christf]

841 v13 have 8MB flash and 64 MB RAM and are sporting an mt76x8 chip. nbd just mentioned that support is in recent openwrt and mesh + AP should be working however testing is required. Let's add it as broken until we know what works and what doesn't.

[NeoRaider]

We should do so after the v2018.1 release.

We are already backporting too many devices when it would be much easier to wait for the switch to the OpenWrt master. While a backport may be justified for the most promising devices, adding a known BROKEN device (AFAIK, there is no sane way to flash the 841v13 yet) only adds to the maintenance burden.

[rotanid]

in Gluon master (future v2018.1.x) it would be rather broken, as we gave up on backporting the mt76 wifi driver updates.

regarding flashing, it has to be done via TFTP which is not worse than the SSH-way for the already supported devices like UAP AC Lite, Pro, Mesh, ... - i don't think this would need to be marked as broken.

[christf]

@rotanid I agree that just for the flashing method the broken flag is not justified. The suggestion for BROKEN stems from the fact that we don't know yet how these devices work in typical freifunk situations yet. In any case, this is a minor detail.

[Adorfer]

if flashing would require RS232 console access (and making contact on the main PCB) prior to TFTP download the image: In this case i would agree as well to status "broken".
a procedure requiring the removal of screws/breaking seals/placing needles/soldering: not good.

But as long as it can be done from the outside and proven working (even with some known glitches): Not BROKEN for me.

[kpanic23]

Well, technically it is possible to flash the device via the stock web interface. The only problem is, that the stock firmware overwrites part of the image. This could theoretically be mitigated by adding 128k of padding to the image before the kernel. I have no idea if that would be possible...

Tests showed that the GUI upgrade routine copies value of "Additional
Hardware Version" from existing firmware into offset "0x2023c" in
provided file, _before_ storing it in flash. In case of vendor firmware
upgrade files (which all include U-Boot image and two headers), this
offset points to the matching field in kernel+rootfs firmware part
header. Unfortunately, in case of LEDE factory image file which contains
only one header, it points to the offset "0x2023c" in kernel image. This
leads to a corrupted kernel and ends up with a "soft-bricked" device.

see Piotr Dymacz's commit

[Adorfer]

Is it perhaps possible to make it a "2-step" flash

• Step1: Flashing a minimal Openwrt with at least a web UI for the next flash step
• Step2: Flashing of final Gluon-Image (probably the "upgrade"-Image)

(Yes, i myself i have no problem with tftp, or rs232, or even with an SPI clamp or unsoldering the SPI... but we want to make things as convenient for users as possible)

[kpanic23]

It is, that's how I'm doing it:
You can download the OpenWrt "-tftp" image and flash it via tftp.
Then I "scp" the gluon sysupgrade image to the device's /tmp, ssh to it and run sysupgrade -n.

Admittedly, that's not quite as easy as flashing via webgui, but for example flashing the newer UBNT devices is in no way easier...

[rotanid]

FYI, there's also a v14 of this device which will have only 32MB RAM again - really bad, so bad, very bad.
https://md.darmstadt.ccc.de/gluon-device-wishlist#Rejected

[blocktrron]

Does anybody have this device running on Gluon Next? I'm currently testing a Archer C50 v3, which uses the similar MT7628A SoC and my experience so far is far from great.

I'm not judging mesh performance for now, as i only own this device for a few day now. As soon as i start a fastd connection, the load of the device jumps so a steadily >1 and the WiFi in fact becomes unusable. However, if no fastd connection is established, the device runs in an acceptable range.

So i'm wondering if this is a phenomenon with the 841v13 too. All devices i have seen around had no active fastd connection.

Load is graphed here: https://stats.darmstadt.freifunk.net/d/000000021/router-meshviewer-export?var-node=b04e2678adda

[rotanid]

there's a PR now for the device: #1470
someone has to test the device with this PR and some checklist like https://github.com/freifunk-gluon/gluon/issues/1434#issuecomment-399168117

[rotanid]

merged, closing.
04b446d8cda80a58ea470129adf3cd19d0623423