kirkwood: add support for Linksys E4200 v2

[darkdragon-001]

• Must be flashable from vendor firmware
  • Web interface
  • TFTP
  • Other:
• Must support upgrade mechanism
  • Must have working sysupgrade
    • Must keep/forget configuration (sysupgrade [-n], firstboot)
  • Gluon profile name matches autoupdater image name
    (lua -e 'print(require("platform_info").get_image_name())')
• Reset/WPS/... button must return device into config mode
• Primary MAC address should match address on device label (or packaging)
  (https://gluon.readthedocs.io/en/latest/dev/hardware.html#hardware-support-in-packages)
  • When re-adding a device that was supported by an earlier version of Gluon, a
    factory reset must be performed before checking the primary MAC address, as
    the setting from the old version is not reset otherwise.
• Wired network
  • should support all network ports on the device
  • must have correct port assignment (WAN/LAN)
    • if there are multiple ports but no WAN port:
      • the PoE input should be WAN, all other ports LAN
      • otherwise the first port should be declared as WAN, all other ports LAN
• Wireless network (if applicable)
  • Association with AP must be possible on all radios
  • Association with 802.11s mesh must work on all radios
  • AP+mesh mode must work in parallel on all radios
• LED mapping
  • Power/system LED
    • 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
    • Should show activity
    • No Radio LEDs available
  • Switch port 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
• Cellular devices only:
  • Added board name to is_cellular_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
  • Added board name with modem setup function setup_ncm_qmi to package/gluon-core/luasrc/lib/gluon/upgrade/250-cellular
• Docs:
  • Added Device to docs/user/supported_devices.rst

[darkdragon-001]

A backport to 2023.1.x would also be nice, as it's been tested with it and works as expected.

[herbetom]

I haven't looked at the 802.11s situation for the target yet and i'm just relying on the checklist here with my understanding of why it's broken.

I'm generally not too happy with adding a target where (at least so far) all devices are broken. A target always consumes CI resources. For a broken target this feels like a bit of a waste.

Depending on what the issue with 802.11s is, have OWE and the Private WLAN Feature been tested?

[darkdragon-001]

I haven't looked at the 802.11s situation for the target yet and i'm just relying on the checklist here with my understanding of why it's broken.

There is no other Freifunk device nearby so I only plan to run this as AP only. As I live next to a square, there regularly are many people which would probably like to have a free network. In order to receive regular updates from my local community we would like to have upstream support.

I'm generally not too happy with adding a target where (at least so far) all devices are broken. A target always consumes CI resources. For a broken target this feels like a bit of a waste.

AP mode works well, I am running it since some weeks and people are happily using it.

Depending on what the issue with 802.11s is, have OWE and the Private WLAN Feature been tested?

• What is OWE?
• I also don't have a need for private WLAN.

[darkdragon-001]

I just tried enabling everything. So private network works in parallel. For 802.11s, I also don't get any errors at least but I don't have any other Freifunk device to test with nearby.
So I unmarked it as broken.

[blocktrron]

For 802.11s, I also don't get any errors at least but I don't have any other Freifunk device to test with nearby.

Sorry, just because you don't know doesn't mean you can. Please find a second AP and test if mesh works. This is a hard dependency.

[darkdragon-001]

Sorry, just because you don't know doesn't mean you can. Please find a second AP and test if mesh works. This is a hard dependency.

Sorry, but this is out of scope for me. I restored this PR to mark the device as broken. I would be happy if you accept my contribution as is and make this device available to all Freifunk communities. If you are not interested, then I will close this PR and we will maintain this device downstream in our community in order to make it available to our users.