Skip to content

Meeting 2021 01

Jump to bottom Edit New page
David Bauer edited this page Jan 7, 2022 · 1 revision

30.12.2021 - 20:00 https://meet.ffmuc.net/gluon-rc3

Attendees

  • tomh
  • neoraider
  • blocktrron (Darmstadt)
  • hexa
  • lemoer (Freifunk Hannover)
  • aiyion (Freifunk Hannover)
  • 1977er (Freifunk Hannover)
  • lakesider (Freifunk München)
  • herrbett
  • lqb (Freifunk München)
  • T_X
  • TheGoliath (Freifunk München)
  • tackin (Freifunk Trier)
  • dunji
  • Dr.Broiler
  • josX
  • txt.file
  • T0biii (Freifunk München)
  • Daniel
  • Fabian (Freifunk Franken)
  • Michael W.
  • rotanid (Freifunk Altdorf)

Topics

  • [name=blocktrron] 2021 recap
    • Integration of Wireguard
    • 206 commits
    • 187 new Issues & PRs
    • Someone give me a tool to provide better statistics :(
  • Target migration
    • ath79-generic / ath79-nand
      • LEDs /etc/config/system
      • Network /etc/config/network
      • PoE-passthough settings (CPE210)
    • ramips / lantiq DSA
      • Network /etc/config/network
    • Determine the user intent (limit to gluon abilities)
    • Regenerate OpenWrt config
    • Apply gluon configurable settings on every update
    • TBD: determine how to handle SUPPORTED_DEVICES / DEVICE_SUPPORT_LEVEL
    • Steps:
      1. Migration of UCI config ([name=neoraider])
      2. Build system patches ([name=blocktrron])
      3. Testing a lot of devices (community effort)
    • Erwarteter Zeithorizont:
      • Release wird auf ~2021/04 geschätzt.
      • Halbes Jahr bis Dinge wirklich flüssig sind.
  • [name=hexa] Updated branch protection rules
  • [name=blocktrron] Goal of Gluon
    • From time to time "becoming a generic mesh-framework" comes up as Gluons designated Goal
    • From my perception, this is far from the reality
    • Not forcing a decision making here, but what is the target group / audience? For whom / what do we develop Gluon for?
      • [name=hexa] Opinionated firmware framework for community mesh-networking
      • Github says: "a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes"
      • [name=blocktrron]
      • Is there some sort of communication between LibreMesh and the Gluon community?
        • There was some communication
  • [name=???] Upstreaming Gluon packages
    • Potential Package: Autoupdater
      • But the autoupdater may be not really suitable for most projects.
      • Someone has to maintain the manifest.
    • If someone is willing to upstream packages, go for it!
      • Most likely, we would have to move source code from the feed to seperate repo.
      • But this is not a problem.
  • [name=blocktrron] State of Community Packages Repo
    • We've got some activity, but what we / I've anticipated didn't happen
      • Communities upstreaming their own packages
    • Working model of community packages unclear?
      • Submit a package --> Write permission --> Maintain package on Community packages
      • Should this be emphasized in a Readme? Yes
      • Should we try to upstream community packages ourselves? (e.g. the legacy SSID eol package of Freifunk Frankfurt am Main or Freifunk München)
        • Go for it if it is modular
    • Suggestions:
  • Report of Ongoing Activities
    • [name=lemoer] WireGuard
      • In-kernel L3 Tunneling.
        • Implementation is based on wgpeerselector and VXLAN (L2 Transport).
      • Works pretty stable in Hannover (approx. 80 devices)
      • In Gluon master, but not yet released, as we did not backport anything yet.
      • Two pending PRs
        • Docs and position of MTU in site.conf.
        • lemoer will assist in making FFMUC backend compatible to Gluons client implementation
    • [name=blocktrron] usteer
      • Decentralized Client Steering (802.11v)
      • Adaptive to the current network situation and roaming patterns
      • Main advantages for communities:
        • Avoids clients getting stuck at distant nodes (hopefully)
        • More seamless, timely handover
      • Links:
      • More sophisticated, standardized alternative to Sargon's roamguide:
      • Works with 21.02 upwards
        • Needs backport to 21.02 packages (Gluon)
        • But ultimately resides in community-packages
      • Drawback: Only communication to adjacent nodes
        • No multi-hop propagandation
      • Ultimate Goal: Implement Full set of WiFi Agile Multiband functionality
      • Client Support:
        • Apple says, they have it.
        • For android, it depends on the vendor.
          • Already 2018 smartphone support it.
        • Windows 10 supports it.
          • Depends on the hardware.
          • Recent intel cards support it.
        • Linux:
          • Depends on the wpa_supplicant build configuration.
      • Gluon integration:
        • The "usteer bubble" is kept in the local mesh cloud (no connection via vpn).
        • Only direct neighbours know each other.
          • Multi-hop connections between usteer daemons is not implemented.
          • But in most mesh topologies
        • A hacky first package is available (see links above)
      • Config Examples:
        • https://github.com/blocktrron/usteer-config
        • Config-Migration darmstadt.ccc.de (Hackerspace): 
          #!/usr/bin/lua
local uci = require("simple-uci").cursor()

local section = uci:get_first("usteer", "usteer")
uci:set("usteer", section, "network", "vlan42")

-- configure ssids
uci:set_list("usteer", section, "ssid_list", {
    'darmstadt.ccc.de',
    'darmstadt.freifunk.net',
    'owe.darmstadt.freifunk.net',
})

-- enable roaming
uci:set("usteer", section, "roam_scan_snr", "-60")
uci:set("usteer", section, "roam_trigger_snr", "-72")

-- Kick a client in case no better node is found for 5
-- consecutive rounds
uci:set("usteer", section, "roam_scan_tries", "5")

-- Enable steering in case a signal-wise better AP is found
uci:set("usteer", section, "signal_diff_threshold", "12")

-- Kick when signal is worse than min_signal
uci:set("usteer", section, "min_snr", "-82")

-- Kick more agressively (~5 second disassoc-delay)
uci:set("usteer", section, "roam_kick_delay", "50")

-- enable logging
uci:set_list("usteer", section, "event_log_types", {
    'signal_kick',
    'assoc_req_deny',
    'auth_req_deny',
    'probe_req_deny',
})

uci:commit("usteer")
      • Wishlist:
        • Docs
    • [name=lemoer] Suggestion: Controller
      • Idea: Add a controller feature to gluon to manage multiple nodes
      • Parts:
        • Adding a REST API to configure the node.
        • Online reconfiguration via that API.
      • Controller itself is supposed to be a gluon package.
      • Current implemented using:
        • HTTP forwarding of the API via SSH tunneling (use of existing technologies/attack vectors)
      • RestAPI for config mode is well
    • [name=lemoer] contrib/push_pkg.sh
      • Enhancing development in gluon.
      • A small script that can be used to test your development changes without baking a whole image.
  • [name=aiyion] What is the state of babel?
    • There are rumors that it doesn't even build anymore. That's wrong.
    • It builds, probably it doesn't work.
    • We do not know about any community effectively using it.
    • The babel code causes some troubles, that we are unsure, if we break things.
  • [name=tomh] more meetups etc.?
    • [name=blocktrron] I think we should do more Community interaction in general
    • Every second tuesday per month
      • Next meeting: 08.02.2022 20:00
  • We might want to update the gluon status of devices in the openwrt wiki as there are some devices which are supported by gluon but aren't tagged as "yes" in the wiki
    • You can get a wiki account there just by asking in the OpenWrt IRC channel.
    • [name=blocktrron] I didn't knew this field is a thing
  • What's the state of the broken devices?
    • Should we ask communities to report back on those devices whether they actually work properly now?
    • [name=blocktrron] Which specific devices are meant? Some are broken due to Hardware limitations.
  • Is there a matrix channel for gluon related topics?
    • No. => Just IRC? Maybe a bridge or something?
      • Chat via Matrix erreichbar: #gluon:hackint.org
        • [name=tomh] was added to the README.md
          • pandoc convert commit pull-request
  • What is your point of view regarding the old devices?
    • These represent a large part of the Freifunk routers.
    • Will you provide security updates for these older devices?
    • (e.g. if there is a new minor version of OpenWrt, e.g. 19.07.x, will there be a new Gluon version for these older devices)?
      • [name=blocktrron] Fully dependent on the OpenWrt upstream support. The current release will (most likely) be supported till OpenWrt 19.07 falls aout of support (Mid 2021)
  • What do you think about communities that have not updated their firmware for years and are stuck on e.g. 2019.x.
  • What would you suggest as a course of action if communities don't respond, but you want to continue working on the firmware of the respective community yourself?
    • [name=blocktrron] I don't understand the question.
    • This is no technical gluon question.
    • [name=T_X]: one idea/suggestion might be to maybe add some "backup signing keys" to autoupdater, for instance from people from neighbor communities (after communicating with them) - but obviously won't help if a community was already lost
  • [name=blocktrron] Wishlist for Roadmap for 2022
    • Release w/ OpenWrt 21.02 (all)
    • Fastd L2TP ([name=neoraider], [name=hexa])
    • Wireguard L2 ([name=lemoer])
    • Roaming/Steering ([name=blocktrron])
    • RestAPI for Config Mode ([name=lemoer])
    • Mesh DFS? (2.4 GHz becomes more and more unusable, communities flash CPE510s back to stock firmware for instance and then run batman-adv over that) ([name=T_X])
  • [name=blocktrron] Open GitHub PRs

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

Clone this wiki locally