add hardware: Linksys EA6350 v3

[ctr49]

successfully built, flashed and ran a device based on this

[mweinelt]

Thank you for yout contribution.

For adding device support we require the device checklist to be copied and filled out. This is to ensure that the core functionality of Gluon works on this device.

[ctr49]

• must be flashable from vendor firmware
  • webinterface
  • tftp (not tested yet)
• must support upgrade mechanism
  • must have working sysupgrade
    • must keep/forget configuration (if applicable)
  • must have working autoupdate (image name matches, autoupdate not tried)
• reset/wps/phone button must return device into config mode
• primary mac should match address on device label
• wired network
  • should support all network ports on the device
  • must have correct port assignment (WAN/LAN)
• wifi (if applicable)
  • association with AP must be possible on all radios
  • association with 802.11s mesh must be working on all radios
  • ap/mesh mode must work in parallel on all radios
• led mapping
  • power/sys led (critical, because led definitions are setup on firstboot only)
    • lit while the device is on
    • should display config mode blink sequence
      (https://gluon.readthedocs.io/en/latest/features/configmode.html)
  • radio leds
    • should map to their respective radio (no radio LEDs)
    • should show activity (no radio LEDs)
  • switchport leds
    • should map to their respective port (or switch, if only one led present)
    • should show link state and activity
• outdoor devices only
  • added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua

[mweinelt]

[p] primary mac should match address on device label label shows: eth1 mac matches label, primary_mac is off by 0x10

This means you need to modify package/gluon-core/luasrc/lib/gluon/upgrade/010-primary-mac to have it read the correct label mac from the correct interface/phy.

[ctr49]

I would have expected that the update would actually pick the eth1 mac as primary, but it picks eth0 mac now. So instead of being 0x10 off, it's 1-off. Still not tas intended. Any suggestions?

[mweinelt]

Did you sysupgrade -n <image.bin>, as in forget all settings? If not try firstboot and reboot. The primary mac adress is only configured on first boot.

[ctr49]

Yes and I also tried on a second device (using the factory image coming from stock firmware), same behavior: eth0 mac being used instead of the eth1 mac.

[neocturne]

It seems the eth1 MAC address is set "too late" for the upgrade script to notice it on this device. Try adding the device match to the board('lan') block instead.

[blocktrron]

I might be ruining the day here, but the device has a fixed 3M kernel limit which we already hit 2.7M of (OpenWrt Master - Kernel 5.4). Oh and the bootloader does not support LZMA.

So this raises the question for me if this device should be flagged as BROKEN from the beginning for this reason.

[ctr49]

board('lan') didn't help either.
What's the OpenWRT equivalent of primary_mac? I'd like to verify if plain OpenWRT does it "right"...

[ctr49]

the device has a fixed 3M kernel limit which we already hit 2.7M of (OpenWrt Master - Kernel 5.4). Oh and the bootloader does not support LZMA.

So this raises the question for me if this device should be flagged as BROKEN from the beginning for this reason.

There are other devices with a 3M kernel limit (ubnt-erx) and even some with a smaller ones down to 2M (Zyxel NBG6616) that are not marked as broken. Is not supporting native lzma (vs zImage) such a huge overhead to justify a 3M limit as cause for flagging this BROKEN?

As far as I can see this would be the very first device that would be marked broken due to kernel size limit (just grepping through "broken" in targets real quick, correct me if I'm wrong).

[blocktrron]

The ER-X might be circumventable as we can probably combine both kernel partitions to allow up to 6M kernel. The NBG6616 however is in the ar71xx target, which will never see a kernel newer than 4.14. So this is a non-issue.

For me the question is whether or not we want to add a device we know has to be dropped 2-3 releases into the future. This is something we should decide on before merging this as non-broken.

[neocturne]

board('lan') didn't help either.
What's the OpenWRT equivalent of primary_mac? I'd like to verify if plain OpenWRT does it "right"...

OpenWrt doesn't have such a concept so far (there is the idea of a "label-mac" in the device tree, not sure if that is merged yet), but this will only work when the MAC address can be determined by the kernel via the device tree - which is not the case on this device. Please post the contents of /etc/board.json - that should contain the right MAC address somewhere.

Missing LZMA support in the bootloader doesn't seem like a problem, zImage should work fine (but of course it may still be an issue if even the LZMA-compressed kernel is close to 3M). lzma-loader-like solutions (or just a second/third-stage U-Boot) would probably work, but I'm not sure if we want to go that route.

[neocturne]

@ctr49 Ah, is the MAC address 1 too high or too low? I think board('wan') might be the correct handler after all.

[rotanid]

For me the question is whether or not we want to add a device we know has to be dropped 2-3 releases into the future. This is something we should decide on before merging this as non-broken.

we do have devices which will have problems earlier than this one which aren't flagged as broken.
in my opinion BROKEN is wrong for this device, if the kernel size limit is the only point here.

maybe we need more/different steps for deprecating devices, depending on the time we estimate until a device can not be supported anymore?

the one thing which stands against supporting EA6350 without any flag - for me - is that it is still available in many online-shops, so we could encourage people to spend 90€ on a device which will only last maybe 2 years. my opinion to support it without any flag would be much stronger if it wouldn't be available brand new...

[ctr49]

Ah, is the MAC address 1 too high or too low? I think board('wan') might be the correct handler after all.

Yes, that did the trick! primary_mac is now the one from the label.

the one thing which stands against supporting EA6350 without any flag - for me - is that it is still available in many online-shops, so we could encourage people to spend 90€ on a device which will only last maybe 2 years. my opinion to support it without any flag would be much stronger if it wouldn't be available brand new...

The device is neither new nor expensive. You can get it for a bargain from time to time. The three devices I've got here were £ 27.50 each from Amazon UK ... in July 2019. Not too bad for a device with those specs.

[neocturne]

To reduce confusion about different ways to specify the interface to use the address from, and different times when these become valid in the boot process, I'm working on a patch to migrate all eth0/eth1 matches to board('lan') and board('wan').

[ctr49]

Is there anything else I can contribute to get this merged?

[neocturne]

From my side, this looks good, while @blocktrron has raised a concern. I don't think we are encouraging people to buy a device just by supporting it - lots of devices we support are not advisable at all, for various reasons.

[blocktrron]

Fine with me, i just wanted to raise awareness for this issue.