Gluon: GL.Inet AR300M-Lite: Wrong Sysconfig interface

[yanosz]

Bug report

What is the problem?
On a GL.Inet-AR300M-Lite device:
root@(none):/rom/root# lua -e 'print(require("gluon.sysconfig").setup_ifname)' eth1
This is wrong, since eth1 is not wired - the lite variant only has 1 port, only.

What is the expected behaviour?
root@(none):/rom/root# lua -e 'print(require("gluon.sysconfig").setup_ifname)' eth0

Note:
Detecting the board variant may not be easy. I noticed, that eth1 shows up as a gigabit-Interface using a random mac address. All GL-300M devices are 100MBit/s, only. As a rule of thumb, I'd suggest not use GMII eths with random macs for config mode on GL-300M devices.

dmesg | grep eth1
[    0.356166] ar71xx: using random MAC address for eth1
[    2.320461] eth1: Atheros AG71xx at 0xba000000, irq 5, mode:GMII
dmesg | grep eth0
[    1.637676] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode:MII
[    4.282590] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    6.338176] eth0: link up (100Mbps/Full duplex)

Gluon Version:
2018.2

Site Configuration:
https://git.kbu.freifunk.net/ff-kbu/gluon-build/tree/2dc1cd9f8106404583450426d0997b3819e79dfb

Custom patches:
None

[blocktrron]

Just from the looks of it, it doesn't seem we list the AR300M-lite as supported. So this is more about the integration then a problem with already supported devices?

[yanosz]

@blocktrron : I don't know. Docs say: GL-AR300M, without mentioning variants. After changing eth1 to eth0 everything is fine. Guess, it's a minor thing.

[rotanid]

the GL-AR300M is one variant of the family, the GL-AR300M-Lite ist another one, the GL-AR300M16M another one. we can't change the names the vendor uses ;)

the -Lite is practically the same device as the GL-AR300M16M (i also have it) but with only one LAN port.

the problem you already noticed may have to be fixed upstream, but i'm not sure, maybe @blocktrron can help with this.
see also the following links:
https://openwrt.org/toh/gl.inet/gl.inet_gl-ar300m-lite
https://forum.openwrt.org/t/solved-ar300m-vs-ar300m-lite-art-data-was-first-boot-config-for-single-port-device/27820

[yanosz]

Thanks for the info.

I've doubts whether this bug is related to upstream. I guess that adding the lite variant into the port swapping list is suitable.
https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-setup-mode/luasrc/lib/gluon/upgrade/320-setup-ifname#L11

However, I'm not that familar with the Gluon API (bash / lua) to code a condition including the mode (GMII) and / or detecting locally generated MAC addresses.

[rotanid]

we shouldn't make a workaround for something that is also broken upstream.
as you can see from my links, it is also a problem with plain OpenWrt and thus should be fixed there.

[blocktrron]

@yanosz Okay, i did dig a bit deeper here. It looks like the GL-AR300M-Lite was introduced after the other GL.iNet models.

There is also a patch upstream to add support for the GL-AR300M lite. https://patchwork.ozlabs.org/patch/1031665/

We should, however, clear up which exact models of this series are supported by Gluon.

[yanosz]

ok - thanks for your feedback.

I'd really love to see support for the -Lite anytime soon. Due to its low price (17 €) and specs (128MB Ram, 16 MB flash) it's a really interesting device for new Freifunkas.

Edit: Using failsave the device is reachable (Gluon 2018.2) - Regarding https://patchwork.ozlabs.org/patch/1031665/: "making it unreachable firstboot or failsafe." - that observation doesn't seem to hold.

[rotanid]

as always, as soon as it is supported in OpenWrt, we can progress with Gluon support

[yanosz]

ok - well, what do you mean with supported in OpenWRT?

Afaik the devices come preinstalled with OpenWRT, while users can download a non-patched version at the vendors homepage https://dl.gl-inet.com/firmware/ar300m/clean/ - sources seem to be available, here: https://github.com/gl-inet. Guess this device is premium, when it comes to OpenWRT support ;-)

Gluon 18.02 is running fine, after changing a the sysconfig-port from eth1 to eth0. Apart from that, I don't see any practical problem.

[blocktrron]

@yanosz The Device is supported in OpenWRT, however only in the new ath79 target which is not included in OpenWRT 18.06. The ar71xx target (which Gluon currently uses) lacks support for the device.

Changing the sysconfig is more of a hack. I see no way on how to distinguish the two devices at runtime in a non-hacky way. With this, we most likely run into a mountain of trouble when #1570 becomes relevant.

[rotanid]

@blocktrron @yanosz the device is not yet supported by upstream OpenWrt. vendor-forks don't count.
there is a PR/patch ath79, which has issues. we'll wait until this is resolved and i'll prepare a patch for ar71xx afterwards.

[yanosz]

Der Hersteller hat die Lite Variante inzwischen abgekündigt (https://www.gl-inet.com/products/gl-ar300m/)- damit taugt's nicht mehr als "verfügbare Freifunk Hardware < 20 €". Ich denke nicht, dass noch viele ein 300M-Lite für Gluon verwenden möchten

Vorschlag: Von meiner Seite her können wir das issue praktisch schließen - alle anderen Geräte der Serie haben 2 Ethernet-Ports. Ich denke, es wäre ausreichend einen Hinweis in die Doku aufzunehmen (-Lite devices im failsave-Modus starten, sysconfig-port via editor umsetzen, fertig).

[rotanid]

upstream target ath79 supports the device since 13.03.2019 ( fefa34def84561688e6af2feeec2dbb390ba4486 )
but i think i won't have the time to backport this to ar71xx.
if anyone else does it, i'm happy to test it.

but @yanosz is right, if it's discontinued it may not make much sense, instead one can use GL-AR300M16 - closing per authors suggestion.