falsche Priorisierung der Gatewayserver beim Laden der *-services.csv

[leoss]

Die User-APs benötigen einen UGW, um ins Internet zu kommen. Eine Liste von UGWs wird ermittelt per:

• olsrv1-nameservice plugin
• csv Dateidownload von https://services.opennet-initiative.de/[user|ugw]-services.csv
  Aus dieser Liste von UGWs ermittelt der User-AP den "besten/schnellsten" UGW aus. Dies geschieht durch die Bewertung von:
• Anzahl Hops (Routingentfernung)
• Downloadgeschwindigkeit

Problem: Bei UGWs, welche per CSV ermittelt wurden, wird "teilweise" die Prüfung auf optimalen UGW übersprungen und fälschlicherweise wird dieser UGW dann genutzt. Dies führt zu einer schlechten/langsamen Verbindung der Nutzer:innen.

[leoss]

Das Problem ist, dass der ETX/ETT von OLSR2 sehr klein ist und deshalb "besser" als der ETX (HopCount) von OLSR1 angesehen wird.

Warum ist die Zahl so klein?
Diese Zahl wird aus der Funktion get_hop_count_and_etx() [2] entnommen und soll dem ETX Wert entsprechen.
Bei OLSRv1 entspricht der ETX Wert (grob gesagt) dem Hop Count, wobei aus ETX Wert auch künstlich erhöht werden kann, wenn man bspw. die Nutzung von gewissen Strecken verhindern will. Wir erhöhen den ETX für die Strecken zwischen den Gateway Servern, sodass kein Traffic von einem Gatewayserver zu einem anderen weitergeleitet wird.
Bei OLSRv2 ist der ETX (ETT) ein "anderer" abstrakter Wert [1], welcher die reale Geschwindigkeit versucht abzubilden. Der Wert kann sehr groß werden bei langsamen Verbindungen. Beispielsweise:

Bandwidth (Hops) ETT Hop Count
3.06kbit/s (6 hops) 4210231 6
6.12kbit/s (6 hops) 2105164 6
4.502kbit/s (9 hops) 4292284 9
97.612Mbit/s (3 hops) 68 3
126.322Mbit/s (9 hops) 160 9
102.261Mbit/s (1 hops) 21 1
1.073Gbit/s (1 hops) 2 1

In der Funktion get_hop_count_and_etx() wird bei OLSRv2 der ETX mittles 1/ETT berechnet. Warum genau, weiß ich nicht. Das könnte man hinterfragen.

Das Grundproblem ist nun, dass wir zwei Metriken haben, welche nicht miteinander vergleichbar sein. Unsere derzeitige Implementierung tut aber so, als ob sie vergleichbar wären, mit entsprechend schlechtem Ergebnis.
Wie kommen wir aus dieser Situation raus?
Eigentlich dürften wir uns nur auf unsere eigenen Geschwindigkeitstests verlassen. Wir lösen das Problem also in den Layern darüber und schauen nicht auf das Routing.
Alternativ hätte man einen Schalter zwischen only-OLSRv1 oder only-OLSRv2 für die UGW Ermittlung.

Temporär haben wir erstmal das Announcement des OLSR2 UGW-Servers deaktiviert per opennet-initiative/ansible@bf70790

[1] Abschnit "2.2.2. ETT metric" https://people.ac.upc.edu/leandro/docs/olsrv2fcn.pdf
[2]

firmware/opennet/packages/on-core/files/usr/lib/opennet/routing.sh

Line 273 in c7f1180

get_hop_count_and_etx() {