On Saturday, 17 April 2021 18:08:34 CEST Maximilian Hahn wrote:

Bin morgen 9:30 Uhr im Parkhotel. Ich denke es liegt laut Beschreibung von

André am an dem Gastzugang

[...]

Danke fuer den Hinweis mit dem Gastzugang. Hoffentlich wird das hier nicht der
Hauptgrund sein, aber der ist bei der Fritzbox fuer IPv6 (und eigentlich auch
IPv4) ziemlich kaputt. Deshalb hatte ich auch mal den Blogbeitrag [1] auf
unserer Seite entsprechend markiert.

Auch im Parkhotel sieht man das beim Offloader gut (zum Glueck nicht bei der
Verbindung zwischen den einzelnen Knoten):

   $ sysctl net.ipv6.conf.br-wan.mtu
   net.ipv6.conf.br-wan.mtu = 1280

Die MTU ist also auf das Minimum gesetzt, dass bei IPv6 erlaubt ist. Wird also
schwierig ein volles IPv6-Paket darueber zu schicken, wenn dieses selber schon
mindestens 1280 Bytes gross aber, aber dann natuerlich fuer den Tunnel nochmal
extra Header zum Einpacken hinzufuegt werden muessen.

Wie schon angedeutet, ist das besonders problematisch wenn man ueber so ein
Interface (mit reduzierter MTU) das Mesh-on-WAN/LAN zu machen, da die dafuer
benutze VXLAN-Encapsulation nicht fragmentiert wird - diese Pakete gehen dann
einfach verloren. Das Problem hatten wir hier schonmal auf der Mailingliste
debugged.

On Friday, 16 April 2021 18:25:12 CEST Enno M. wrote:

Zu debug Zwecke würde ich (also ich 🧐) das wifi mesh für knoten deaktivieren und testen. Somit sollten die Geräte dann über das LAN nur noch meshen... vielleicht kann hier Simon oder Sven was dazu sagen, wie das routing in der firmware routet 😬.

WiFi-Mesh ist fuer die Knoten deaktiviert. Und jetzt schicken die die Pakete
wie folgt (das Meiste hat aber nichts mit "Routing" zu tun):


(                          PL-Raedel18-Parkhotel-E2-1) -------------> (PL-Raedel18-Parkhotel-Offloader                           ) -------------> Netzzugangsinfrastruktur
(AP-Interface -> br-client -> bat0 -> VXLAN -> br-wan) -> Ethernet -> (br-client -> VXLAN -> bat0 -> br-client -> br-wan -> fastd) -> Internet -> VPN04 -> FFRL -> Blablub, ...



Ich (eigentlich war es Nick) hatte festgestellt, dass es bei ath9k zu
sporadischen Hangs kommt. Bei genauer Betrachtung koennte es einen
Zusammenhang mit den TX Path Hangs der WiFi-Hardware zu tun haben. Als ich es
mir genauer angeschaut hatte, sind mir hier zwei Moegliche Ursachen
eingefallen, da diese dynamisch Parameter der ath9k WiFi-Hardwaere aendern:

* Adaptive Noise Immunity
* Dynamische Ack timeout/slot time

Ich hatte deshalb entsprechende Anpassungen fuer Tests in unseren Gluon-Fork
geschmissen. Dabei muss ich aber nochmal eine andere Version des Deaf Fixes
fuer ath9k portieren, da der alte auf ein aktives ANI setzt (was dann ja aus
waere).

Was ich eigentlich sagen wollte: Es ist bei einer solchen Betrachtung
teilweise notwendig zu schauen ueber welche Art von Interface man angebunden
ist. Bei den Geraeten haben wir glaube ath9k fuer 2.4GHz und ath10k fuer 5GHz.
Allgemein ist es beim Testen auch gut mal WiFi komplett auszuschliessen und an
das Ethernet zu gehen. Genauso koennte es auch interessant sein nicht ueber
FFRL oder sogar VPN04 zu testen und die Verbindung eher zu terminieren. Damit
man besser zu versteht wo das Problem sein koennte. Wir haben dafuer ja auch auf
einigen Servern dieses bigfile um wenigstens den Download testen zu koennen.


Zu dem eigentlichen Problem mit dem Einbruch der Geschwindigkeit ueber die
Zeit - das koennte alles sein und ich kann dazu keine wirkliche Antwort geben.

Gruesse,
   Sven

[1] https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/