Skip to content

Meeting 2022 02

Jump to bottom Edit New page
lemoer edited this page Apr 12, 2022 · 9 revisions

12.04.2022 20:00 CEST - mumble.freifunk.net

Attendees

  • Aiyion (ffh)
  • benjamin (ffsh)
  • blocktrron (ffda)
  • florian
  • goligo (ffmuc)
  • hexa
  • lemoer (ffh)
  • mkg20001 (ffgraz)
  • gabor/5br (ffgraz)
  • Neoraider
  • rotanid (ffaltdorf)
  • T_X (ffhl/ffv)
  • tomh

Topics

  • OpenWRT 19.07 is now EOL (tomh)

  • Target migration (aiyion)

  • switch to OpenWRT 22.03 for master (#2426) (blocktrron)

    • should be done before Gluon v2022.1
    • mpc85xx - WDR4900 -> progress by neoraider

  • it can happen that there are prosseces running multiple times (#2468):

    gluon-neighbour-info -s  -l -d ::1 -p 1001 -t 3 -r statistics
/lib/gluon/status-page/providers/stations mesh1
/lib/gluon/status-page/providers/neighbours-batadv

    https://0x0.st/ocKf.png

    • seen on ath79 with 128 MB RAM (EAP225-Outdoor, WS-AP3610, ...) with gluon master
    • also observed with Xiaomi Mi Router 4A Gigabit Edition (128 MB RAM)
    • can be reproduced by opening multiple tabs with the status page

  • OLSR v1 & v2 support (#2418) (mkg20001)

    • ganz viel hack
    • angedacht erstmal saubere PR mit OLSRv2 v6 only, ohne client AP und sonstnochwas
      • interfaces verwenden aktuell static stat gluon_* netifd wegen static ip für v4
    • olsr1 als v6-only upstreamen? (graz v4 kann erstmal offbranch bleiben)
    • gluon wird in graz ausgerollt sobald genug core nodes 802.11s supporten, dann gäbe es reales mesh, aktuell test mesh
      • feedback von graz tech ist generell positiv
    • entscheidung erstmal "eins von beiden" zu mergen, das wäre dann v2 weil so mit echten knoten gemesht werden kann. v1v6 kommt dann in zukunft.
      • v2 ohne client ap auch ok. so klein wie sinnvoll.
    • vxlan wird in graz tech treffen behandelt. evtl ist das "sowieso ok".
    • olsr würde Layer 3 Testsituation in gluon verbessern, babel ist aktuell nur nebenher

  • gluon-statistics-mcast / bpfcountd (T_X) (#2367)

    • (too?) much RAM... about 5MB per bpfcountd instance
      • will focus on 256MB RAM devices for now, unless someone comes up with an idea to reduce RAM usage of libpcap later
    • respondd via HTTP for large provider responses?
      • Current PR adds a small wrapper
      • Idea is to use another protocol for respondd.
      • There are currently multiple issues with the respondd protocol.
        • The current respondd protocol is susceptible to amplification attacks.
        • The current respondd protocol is unreliable if multiple udp frames are needed due to large responses.
      • Possible Protocols:
        • Maybe we can use http.
        • Another approach could be to use CoAP. (This was discussed already a few years ago. #522?)
      • An idea to use http (or another tcp protocol) is to discover devices via multicast and then query them via unicast directly.
    • respondd providers provider? (#256)
    • async data fetching
      • OLSR PR has hack to do stuff in sepearte process for async traffic. babel has some hack with threads.

  • Roadmap

    • Is outdated since long.
    • Discussion:
      • Should we have a roadmap?
      • What are the goals of a roadmap?
        • Some comments in the discussion seem to indicate that people try to use it for planing what happens when.
        • This certainly shouldn't been done. This is a FOSS project, where nothing is not predictable. A note has been added.
      • Potentially use the meeting to update the roadmap
        • We could also have internal benefit from the regular discussion of the roadmap. (Update of opinions, New discussion on old points, ...)
      • The roadmap has been updated coloboratively using a HedgeDoc. Results are found here.
      • Categories have been introduced in the roadmap.
      • We decided not to put estimated release numbers into the roadmap.

  • 60GHz (mkg20001)

    • Graz uses this on a few nodes. Does not really work well.
    • Does not work fully as 802.11s is missing in wifi driver, but ap/station p2p-go/p2p-client works.
    • OpenWrt PR for MikroTik Wireless Wire dish LHGG-60ad: https://github.com/openwrt/openwrt/pull/2417
    • Advantages of Gluon on 60GHz devices:
      • No need for separate mesh-on-lan links (see below)
      • Helps in decision making of routing protocol (e.g. with throughput metric, like BATMAN V, OLSRv2 or potentially BABEL in the future) -> does not need to do hog with own sample traffic, but can obtain throughput (guess) from (wifi) drivers

  • Seperate mesh-on-LAN links (breakout discussion from the 60 GHz topic)

    • Problem is that all wired links are bridged directly (within the same bride).
    • E.g. support for VLANs to allow usage of simple managed switch between links and just use one gluon node
    • There is already an issue: #1104.
    • currently not working, as no macaddresses for gluon created bridges due to gluon macaddress generation limit of 8 due to collisions
      • gluon creates a bridge per interface to allow sane usage on very interesting devices where WAN, LAN and wifi share the same MAC, which is problematic for BATMAN-ADV
    • A new idea during the meeting: We could maybe use the hairpin mode on the bridges.

  • Reset of system and network config (goligo)

    • The LED configuration reset is a problem in FFMUC.
      • A lot of people seem to reconfigure the LED configuration in gluon up to this point.
      • This is no longer possible on the master, since LED configuration is now reset on every update.
      • Question: Why is this changed?
      • LEDs are renamed from time to time in OpenWrt. This causes troubles since there is no stable identifier for specific LEDs.
      • Also there are some LEDs that are handled by hardware.
      • User configuartion that we may start to support in future:
        • We could add a configuration option to deactivate all LEDs.
        • We could add a configuration option to deactivate flickering/blinking for all LEDs.
        • (Issues/PRs welcome.)
      • What we will not support:
        • We will not support reconfiguring individual LEDs. This would result in an unreasonable amount of work.
    • New gluon.iface_xxx configuration is working well.

  • ArmVirt does not build factory and sysupgrade bin (goligo)

    • When build macros of armvirt are updated, Gluon build fails because of missing factory/sysupgrade image
    • Not trivial, as armvirt currently does not provide a factory image, which would need to contain a bootloader, kernel and rootfs.

  • Config-Mode UI for Interface Roles Feature (#2393 - lemoer)

    • Question: Does anybody want to add something, or can lemoer start to implement?
    • No, nobody want's to add things.
    • Some aspects of the implementation were discussed:
      • Some roles are conflicting with each other.
      • Interfaces that have switches behind them that use swconfig will not support vlan creation.
        • Supporting this would probably be too much maintainance.
        • We want to figure out which interfaces are managed using swconfig and avoid vlan creation on top of them.
          • But unsure if this works.
      • Interfaces shown in the UI should be discovered dynamically.
        • Idea: Find out all "ethernet" interfaces and show them.
        • We may face some problems with unpredictable interface names in the future.
          • But as of now, we do not care. This is definitely another topic for later.

Next meeting

14.06.2022 - 20:00 CEST - mumble.freifunk.net

Disclaimer: Please note that this wiki can be edited by anyone. Please be careful when using it.

Clone this wiki locally