(Brainstorming auf der gpn 2022)

Softwares:

• Nexus Sonartype Artifact Manager
• Artifactory
  • Eingeschränkte Version für FOSS-projekte verfügbar.
    • Sollte aber für uns reichen, da wir keine Python/C++/... Projekte machen.
    • Wir machen nur "Raw"-Artefakte.

Hauptvorteile für uns:

• Webinterface zum Browsen der Artefakte.
  • Suchmaske nach konkreten Routermodellen anlegen.
  • Dann kann man schnell alle Versionen für diesen Router aufrufen, die es da gibt.
• Retention Policies über Webinterface.

Optionen zur Nutzung:

• Jede Router-Firmware könnte ein eigenes Artefakt sein?
• Ein gesamter Build könnte ein Artefakt sein?

Optional:

• Könnte firmware.ffh.zone ersetzen?
  • Prüfen: Könnte problematisch für den Firmware-Downloader werden, weil der JavaScript-Code direkt das directory listing von nginx parst. Keine Ahnung, ob das dan bricken würde.

Gluon Auto-Channel Selection

The scope of this is, to automatically distribute nodes across wifi channels. The aim is to automatically enhance performance in installations where all nodes are normally connected via wired mesh. E.g. a large house where there "Hausverkabelung" is used to connect all routers via wired mesh.

Switching channels is not trivial, as it interferes with the capability to mesh with other nodes. While it would be possible to turn off wifi meshing completely in this scenario, it is nice to have a fallback to wifi meshing. As of now, even if wired mesh is turned off for all nodes, the channel planning has to be done manually. So if we device that the fallback is not necessary, it would still be nice to have auto channel selection.

Algorithm Idea

• A node has two modes:
  1. Wifi-Mesh-Mode
  2. Low-Interference-Mode
• Mode Definition:
  • In Wifi-Mesh-Mode:
    • The node always uses wifi channel 1 in this mode.
    • Wifi-Meshing is activated.
  • In Low-Interference-Mode:
    • The node uses a best-fit channel in this mode.
    • Wifi-Meshing is deactivated.
• Mode Transition:
  • In Low-Interference-Mode:
    • If a node observes any other node in its wifi scan (see below), to which it does not have a link via it's wired mesh* capabilities:
      • Switch to Wifi-Mesh-Mode.
    • Otherwise:
      • Stay in Low-Interference-Mode.
  • In Wifi-Mesh-Mode:
    • If all nodes in the mesh are still reachable via wired mesh*, when Wifi-Meshing is turned off:
      • Switch to Low-Interference-Mode.
    • Otherwise:
      • Stay in Low-Interference-Mode.
• Wifi Scanning for Potential Neighbours (in Low-Interference-Mode):
  • As potential neighbors might currently be in the Low-Interference-Mode, we can not scan for their mesh announcement.
  • Therefore we need to scan (on all channels) for their client wifi.
  • From the found client wifi ssids/bssids/essids, we need to figure out from the batman tables, whether we already have a wired link to them.
    • TODO: is this possible? (Check if we can find the mac address of the scan in batctl tg, if so good. If not, see what we can do here.)

* "wired mesh" includes mesh via vpn.

Theoretical Problems (?)

• What if the wired mesh is really bad, while the wifi mesh is good?
  • 🠒 Is this really an issue? I don't think so?
  • If we still think this is an issue, we could define, that wired mesh links with a TQ < X are not considered as connections. X could be very high, I guess. Because wired mesh should always have very low packet loss. But there is also the artificial hop penalty. So let's see.
• Do mixed paths make problems?
  • Links like: wired <-> wifi <-> wired <-> wifi <-> wified ?
  • 🠒 I don't think this is an issue. Every node should be able to make his decisions individually. I think this should converge to a reasonable global state.

Open Questions

• Can we figure out whether we know a node just by scanning for its client wifi? (see above)
  • Yes. All mac addresses are only differing in the last 3 bits. See here.. The bssid has the last bits as 3 or 7. The corresponding node can be found in the batctl o table by nulling the last 3 bits.
• Does a node lose its clients when, when the node performs a channel switch?
• We need to find a decentralized algorithm to find a best-fit channel with least interference. Is there something?
• TODO: Can we use DAWN? Can we maybe extend it? Can we profit from its infrastructure?
• What happens if a node observes another node from another domain?
• How do we handle nodes with multiple radios?

Steps/Work Packages

1. Think about open the questions/experiment.
2. Implement a respondd provider, which announces seen neighboring freifunk client ssids.
3. Implement the channel selection algorithm.
4. Evaluate the results.

I am actually not sure yet, what the difference between SDK and Toolchain is. But I think using one of them in gluon should be quite nice.

Provide an endpoint to capture number of roaming events from a specific roaming sources.

For reference: https://github.com/T-X/gluon/tree/v2021.1.x-gluon-statistics-mcast

Let's see what will happen there...

ath9k

(Maybe this applies to other chipsets using minstrel in kernel as well).

RX Statistics:

# cat /sys/kernel/debug/ieee80211/phy0/netdev:client0/stations/4c\:dd\:31\:74\:08\:04/node_recv
                   HT20      HT40       SGI       LGI
     MCS  0 :          1         0         0         1
     MCS  1 :          0         0         0         0
     MCS  2 :         18        11        10        19
     MCS  3 :         39        10        16        33
     MCS  4 :        202        39       100       141
     MCS  5 :          0         0         0         0
     MCS  6 :          0         0         0         0
     MCS  7 :       1622        88      1066       644
     MCS  8 :          0         0         0         0
     MCS  9 :          0         0         0         0
     MCS 10 :          0         0         0         0
     MCS 11 :          0         0         0         0
     MCS 12 :          0         0         0         0
     MCS 13 :          0         0         0         0
     MCS 14 :          0         0         0         0
     MCS 15 :          0         0         0         0
     MCS 16 :          0         0         0         0
     MCS 17 :          0         0         0         0
     MCS 18 :          0         0         0         0
     MCS 19 :          0         0         0         0
     MCS 20 :          0         0         0         0
     MCS 21 :          0         0         0         0
     MCS 22 :          0         0         0         0
     MCS 23 :          0         0         0         0

  CCK-1M/LP :         99
  CCK-2M/LP :          0
CCK-5.5M/LP :          0
 CCK-11M/LP :          0
  CCK-2M/SP :          0
CCK-5.5M/SP :          0
 CCK-11M/SP :          0
    OFDM-6M :        121
    OFDM-9M :          0
   OFDM-12M :          0
   OFDM-18M :          0
   OFDM-24M :       1740
   OFDM-36M :          0
   OFDM-48M :          0
   OFDM-54M :          0

I checked, that the sum of the "MCS" values correlates to the rx packets on client0.

TX Statistics:

# cat /sys/kernel/debug/ieee80211/phy0/netdev:client0/stations/4c\:dd\:31\:74\:08\:04/rc_stats
              best   ____________rate__________    ________statistics________    _____last____    ______sum-of________
mode guard #  rate  [name   idx airtime  max_tp]  [avg(tp) avg(prob) sd(prob)]  [retry|suc|att]  [#success | #attempts]
HT20  LGI  1         MCS0     0    1477     4.8       2.4      52.4      0.0       3     0 0             2   4        
HT20  LGI  1         MCS1     1     738     9.7       7.3      70.3      0.0       4     0 0            23   35       
HT20  LGI  1         MCS2     2     492    14.6       2.4      27.5      0.0       5     0 0            40   62       
HT20  LGI  1    C    MCS3     3     369    17.0       9.7      47.7      0.0       4     0 0            85   310      
HT20  LGI  1         MCS4     4     246    24.4       7.3      27.8      0.0       5     0 0           220   349      
HT20  LGI  1         MCS5     5     185    29.2       9.7      28.9      0.0       5     0 0           167   581      
HT20  LGI  1         MCS6     6     164    31.7       4.8      19.6      0.0       5     0 0           440   980      
HT20  LGI  1  A      MCS7     7     148    34.1      14.6      37.9      0.0       5     0 0           201   552      
HT20  SGI  1         MCS0    30    1329     4.8       4.8     100.0      0.0       0     0 0             1   1        
HT20  SGI  1         MCS1    31     665     9.7       4.8      49.3      0.0       2     0 0            11   23       
HT20  SGI  1   B  P  MCS2    32     443    14.6       9.7      59.7      0.0       5     1 5            83   136      
HT20  SGI  1         MCS3    33     332    19.5       7.3      42.7      0.0       5     0 0           189   438      
HT20  SGI  1     D   MCS4    34     222    26.8       9.7      33.1      0.0       4     0 0           293   612      
HT20  SGI  1         MCS5    35     166    31.7       7.3      22.2      0.0       5     0 0           546   1281     
HT20  SGI  1         MCS6    36     148    34.1       9.7      26.5      0.0       5     0 0           218   500      
HT20  SGI  1         MCS7    37     133    36.6       7.3      22.9      0.0       6     0 0           193   451      

I checked, that the sum of the "sum-of #success" values correlates to the tx packets on client0. The "sum-of #attempts" column has even higher values, which might be interesting as well. They show, how many packets were sent, but failed.

The rc_stats can also be obtained as csv:

# cat /sys/kernel/debug/ieee80211/phy0/netdev:client0/stations/4c\:dd\:31\:74\:08\:04/rc_stats_csv
HT20,LGI,1,,MCS0 ,0,1477,4.8,2.4,52.4,0.0,3,0,0,2,4,2615,117,1.2
HT20,LGI,1,,MCS1 ,1,738,9.7,7.3,70.3,0.0,4,0,0,23,35,2615,117,1.2
HT20,LGI,1,,MCS2 ,2,492,14.6,2.4,27.5,0.0,5,0,0,40,62,2615,117,1.2
HT20,LGI,1,D,MCS3 ,3,369,17.0,9.7,47.7,0.0,4,0,0,85,310,2615,117,1.2
HT20,LGI,1,,MCS4 ,4,246,24.4,7.3,27.8,0.0,5,0,0,220,349,2615,117,1.2
HT20,LGI,1,,MCS5 ,5,185,29.2,9.7,28.9,0.0,5,0,0,167,581,2615,117,1.2
HT20,LGI,1,,MCS6 ,6,164,31.7,4.8,19.6,0.0,5,0,0,440,980,2615,117,1.2
HT20,LGI,1,AP,MCS7 ,7,148,34.1,24.4,66.4,0.0,5,1,1,218,581,2615,117,1.2
HT20,SGI,1,,MCS0 ,30,1329,4.8,4.8,100.0,0.0,0,0,0,1,1,2615,117,1.2
HT20,SGI,1,,MCS1 ,31,665,9.7,4.8,49.3,0.0,2,0,0,11,23,2615,117,1.2
HT20,SGI,1,C,MCS2 ,32,443,14.6,9.7,58.0,0.0,5,0,0,84,137,2615,117,1.2
HT20,SGI,1,B,MCS3 ,33,332,19.5,12.2,63.7,0.0,5,0,0,190,439,2615,117,1.2
HT20,SGI,1,,MCS4 ,34,222,26.8,9.7,33.1,0.0,4,0,0,293,612,2615,117,1.2
HT20,SGI,1,,MCS5 ,35,166,31.7,7.3,22.2,0.0,5,0,0,546,1281,2615,117,1.2
HT20,SGI,1,,MCS6 ,36,148,34.1,9.7,26.5,0.0,5,0,0,218,500,2615,117,1.2
HT20,SGI,1,,MCS7 ,37,133,36.6,7.3,22.9,0.0,6,0,0,193,451,2615,117,1.2

ath10k

The above mentioned debugfs files do not work in ath10k. Ath10k does not use the mac80211 minstrel algorithm in the kernel. The wifi chips offload the MCS selection. Therefore ath10k has other mechanisms.

Theoretically there is a debugfs file called tx_stats:

• https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L773
• However, the code in ath10k_peer_stats_enabled() suggests that only some devices support the tx_stats counters.

TODOs:

• Tabs
• Untertabs
• Navigation (ggf. encoding)
• Komponenten, die sich selbst registrieren (Damit andere Pakete die App erweitern können)
• Internationalisierung aus der site config
• Validierungen der Felder
  • minLength, maxLength (String)
  • pattern (String) -> Needed for wpakey -> Check with POSIX, ECMA, something regexes.
  • minimum, maximum
  • exclusiveMaximum, exclusiveMimimum (Number)
    • DIFFERENT in different Drafts. (In Draft 4, it is a boolean. Afterwards it can be a number)
  • format -> IP Addressen
• Ableitung, ob es ein invalides Feld gibt.
• Weitere Feldtypen
  • Erweiterbare Liste (z.B. DNS-Server)
  • Mehrzeiliges Textfeld (z.B. SSH-Keys)
  • OSM-Map
• Speichern der Config
  • Speichern nur erlauben, wenn die Config valide ist.
• Übersetzung anderer Felder.
• NoScript Tag

Gluon UCI Config

Requirements:

• Config Validation
  • Traceabilty: Which field was wrong. (And maybe in which config, if configs are merged.)
• TODO: What are other requirements? (-> look at ece?)
• Config options need be able to generate other config options.

Ideas:

• JSON-Config:
  • Move gluon specific user configuration options to a json object.
  • This JSON-object could be merged from multiple JSONs.
    • This would allow the use of templates. Templates could help in managing a bunch of devices.
    • (e.g. deploy the same template.json to a bunch of nodes, so you don't have to set your Contact Info on every device.)
    • TODO: How many config variables would actually benefit from this?
• Introduce a "UCI-Strategy":
  • UCI is already able to merge multiple config directories in some way.
    • TODO: Find out more about the ways UCI can merge things.
  • Currently every application holding a UCI cursor has to setup this the way in which things are merged by itself.
  • The idea is, to introduce /etc/uci_strategy.conf, which determines a default which configuration directories are merged in which order.
  • TODO: The procedure would be most nice, if sections could only occur in one location.
• Other possible UCI-Improvements:
  • Allow makeing certain sections immutable.
• Use Lua-Templates to generate UCI-Config files:
  • This would make things a little more intuitive to read/understand?
  • However, this has the disadvantave that the syntax can get fucked up more easily.
  • Furthermore we are creating a large string from lua with templates, while we could directly use lua control flow here.
  • However, I currently still have the feeling, this would make things more cleaned up/easy to understand. Maybe it's because the lua syntax is kind of non-linear. First you need to prepare your variables/lists/... and then use them in your uci:section() statements.
  • Maybe another fact is, that in the current upgrade-scripts, things are distributed over the whole /lib/upgrade/ scripts. Theoretically a value can be set in 001-foobar and can be overwritten by the 999-blub script.
• Maybe we can integrate the site mechanism.