Drosselungen beginnen - Freifunk an solchen Anschlüssel kaum nutzbar

Mir sind „Schenkrouter“ schon um die Ohren geflogen weil die Stellplatz- und Stromspender die 2GB an Traffic „für nix“ nicht akzeptieren mochten.

Ist das Grundrauschen auf 30 Tage denn jetzt 2 GB oder 60GB?

1 „Gefällt mir“

Mein wunderbares Dorf-DSL ist mit Freifunk auch nicht nutzbar. Ich kann mich entscheiden, ob ich den Freifunk-Knoten am Netz lasse oder ob ich selber noch was machen möchte. Und das fast ohne Clients.

Damit kann ich Freifunk hier im Ort eigentlich gar nicht bewerben, weil sich das keiner antun kann. Mir würde eine Verringerung des Grundrauschens auf jeden Fall helfen!

1 „Gefällt mir“

Bei DorfDSL Bau eine Richtfunkstrecke zu VDSL50 auf und mach mit Freifunk der Telekom Konkurrenz.

2 „Gefällt mir“

Hallo,

bei den freifunk Nodes, die ich betreue, sind es um die 2,5 GB pro Tag an Grundrauschen (1,5 GB Down, 1 GB Up). In den letzten Tagen habe ich aber auch schon 7 GB pro Tag gesehen.

Es gibt auch schon Node Aufsteller, die ihren Uplink ins Internet daraufhin abgeschaltet haben.

Gruß Jörg

1 „Gefällt mir“

Letzten Monat hat ich 108194/23892 MB down/up. Zusammen 132085 MB. Ich glaub ich lag vor Freifunk bei 70 GB. Macht also 50GB für Freifunk (vor zwei Hauptnutzer im wesentlichen nur noch Freifunk nutzen) oder knapp 2GB/Tag mehr als zuvor.

In der Theorie klingt das toll, in der Praxis sind da mehrere Kilometer und Berge zwischen. Außerdem ist nicht einmal unsere Kernstadt komplett mit VDSL versorgt (wir haben ja LTE, damit muss man doch zufrieden sein!1!!) und ich habe alleine auch nicht das technische Wissen dazu :frowning:

Ich probiers nochmal ausgeschlafen, nachdem es nachts um 3 Uhr nicht mehr so gut geklappt hat :wink:

Es ist so, dass diese Protokollarchitektur in der Tat nicht durch Naturgesetze gegeben ist. Man kann sich Kommunikation durchaus „irgendwie“ so vorstellen. Sie ergibt sich jedoch aus der Rolle von BATMAN-adv innerhalb des OSI-Stacks.

Dein Vorschlag war, auf Layer 2 darauf zu verzichten, dass Nodes vollständige Informationen über das Netz haben, sondern nur lokale Informationen vorhalten, und alles was nicht lokal bekannt ist, an das Gateway weitersenden. Das kann man auch machen, es ist wiederum nicht so als würden wir gegen Naturgesetze verstoßen. Allerdings kann ich mir vorstellen, dass dies den Entwicklern wieder zu nah an einer Layer-3-Funktionalität ist, da in Layer 2 eben keine solchen Vermittler (engl. Router) existieren. Sobald man lokale Gateways hat, die alles bekommen, was man nicht zuordnen kann, sind das eben effektiv Layer-3-Gateways, und so hat man nach OSI-Stack eben auch lokale Netze, und sollte dann auch die Netze per IP koppeln. (Hinweis: Routing selbst ist ein Layer-3-Begriff. Die Tatsache dass wir BATMAN-adv ein Routingprotokoll nennen, zeigt, wie sehr das OSI-Schichten-Modell von uns bereits gestaucht wird.) Was die BATMAN-Gateways im Moment tun ist, ein zentrales Gateway für alle Wolken ins Internet zu bieten, aber die Wolken selbst brauchen keinen Vermittler zur Kommunikation untereinander, und können daher im selben Netz bleiben.

Ein Layer-2-Protokoll sollte also nicht eine Default-Route bzw. ein Gateway für die Clients festlegen.
Dies ist die Aufgabe von DHCP. Man sollte also zumindest sicher stellen, dass BATMAN-adv sich nicht anmaßt, die Entscheidungen von DHCP zu ignorieren, aber es wäre dumm, die Topologieinformationen von BATMAN-adv nicht dazu zu nutzen, DHCP zur bestmöglichen Lösung zu bringen.
Die Lösung im Protokoll sah so aus, dass BATMAN-adv-Gateways zwingend mit DHCP auf dem selben Node zusammenarbeiten müssen, sodass BATMAN dann DHCP durch Bestimmung der Randbedingungen im Netz zur optimalen Lösung bewegen kann. Im Endeffekt wird Broadcast verbogen, sodass nur der laut BATMAN-adv „beste“ DHCP-Server die DHCP-Requests bekommt.

Am besten denke ich, stellst du diese Fragen auf der BATMAN-adv Mailingliste. Die Fragen sind nämlich durchaus valide, theoretisch wäre das sicherlich möglich, aber nicht mit BATMAN. Am Ende kann ich auch nur Vermutungen anstellen, aus welchen Gründen die Protokollentwickler ihre Entscheidungen getroffen haben. Darum am besten bei den Entwicklern selber nachfragen. :slight_smile:
(Ich wäre dann auch an der Antwort der Entwickler interessiert)

Ich bin definitiv der Meinung, dass solche Themen extrem Schwierig via Text debattiert werden können.
Da es immer mal wieder eine gewisse Unschärfe bei der Benutzung verschiedener Begriffe gibt, kommt es unweigerlich zu Mißverständnissen.

Ich fände es gut, wenn wir mal einen Mumble Talk machen könnten, mit Leuten, die sich zutrauen zu diesem Thema etwas solides beitragen können. Vielleicht paralle ein Etherpad und noch ein Online Collab-Malwerkzeug.

Konsens scheint aber m.E. zu herrschen zu der Tatsache, dass wir ein Overhead-Problem haben, oder?

Hallo,

vielen Dank für eure Beiträge. Es ist irgendwie gut zu wissen, dass ich nicht der Einzige bin, den das massiv nervt. Und zwar nicht, weil es mir um den Traffic geht, denn meiner VDSL25-Leitung mit echter Flatrate ist das ziemlich egal. Sondern alleine aus dem Grund, weil es eben ineffizient ist.

Danke @JoBu, @paulinsche, @jbacksch und @adorfer für das Teilen eurer Erfahrungen! Ich denke nur, wenn sich viele Leute beschweren, wird das Problem endlich ernst genommen. Selbst Microsoft ist zur neuen Erkenntnis gelangt „We listen to you“.

Und natürlich Danke an @yayachiken für deinen ausführlichen Beitrag. Interessant finde ich insbesondere, dass das Netz ohnehin schon über die Spezifikationen von Layer2 hinausgeht. Damit dürfte der Begriff wohl endlich mal beerdigt werden und wir müssen uns bei diesem Thema nicht an klassische Begriffe klammern.

Ich habe gerade Mal große Teile der BATMAN Dokumentation gelesen. Und kam zu folgender Erkenntnis: BATMAN-adv ist nicht schuld!

Der Overhead resultiert aus der lieblosen Vermischung von Batman-ADV mit fastd und dem daraus resultierenden Informationsdefizit auf Seiten BATMANs.

Denn, was für jeden von uns völlig klar ist, dass der ganze VPN-Traffic über die Gateways läuft. Das kann BATMAN nicht wissen. Es weiß nichts von fastd, denn VPN ist für die niederen Protokolle nicht ersichtlich. Genau das ist ja die Idee von VPN und normaler Weise ist das auch so gewollt, wenn ich nämlich lokale Dienste über’s Internet erreichen will.

Wie könnte man das lösen? Meiner Meinung nach muss der Router, der den Traffic ins fastd steckt, die Pakete flaggen. Geflagte Pakete werden dann an der nächsten Stelle (Upload: das Gateway, Download: der Router mit dem fastd-Tunnel) vernichtet. Gleichzeitig braucht man eine default-Route, die alle Pakete, deren Route nicht bekannt ist, an die Gateways schickt.

So weiß in der Tat nicht mehr jeder Router über jeden Bescheid, aber Layer2 wird trotzdem nicht verletzt.

Wir müssen uns hier denke ich nicht an die BATMAN-adv-Entwickler, sondern an die Gluon-Entwickler wenden. Denn wir müssen quasi einen kleinen Patch bauen, der die Pakete flaggt, geflaggte Pakete verwirft und entsprechend eine default Route hinzufügen. Diese Route wird nur auf den Knoten benötigt, die Gateways kennen nach wie vor jeden Client.

Dann müsste meiner Meinung nach der Traffic deutlich verringert werden. Meinungen?

4 „Gefällt mir“

Mich würden da insbesondere auch die Meinungen von @tcatm und @anon75826926 interessieren. Soweit ich die Foren-Software verstanden habe, müssten sie jetzt benachrichtigt werden.

Wie auch schon in ein paar Posts zuvor geschrieben wurde nutzt Batman-Adv keine Routen. Wir sprechen direkt Batman-adv über das VPN. Die Settings des Meshs müssen global die gleichen sein. Es wurden schon patches wie z.b. Split-Horizon hinzugefügt der OGM’s die aus dem VPN kommen nicht auf diesem erneut verbreitet. Ohne diesen Patch sowie die Multicast Filter wäre schon bei 50~ Nodes schluss mit dem Mesh aufgrund von Overhead.

Wie du siehst bei etwa 550 -800 Nodes (Je nachdem ob Rheinufer oder Ruhrgebiet) läuft dies bereits sehr gut. Trotzdem fließen im Netzwerk Informationen die wir nicht filtern können da sonst das Mesh nicht mehr funktioniert. Dazu zählt z.b. NDP (Neighbor Discovery Protocol) welcher Mutlicast nutzt. Multicast wird momentan vom Mesh als Broadcast behandelt, daher wird der Traffic mit jeder Node im Netzwerk zunehmen. Dies lässt sich nicht verhindern.

Das Einzige was wir momentan dagegen machen können ist das aufsplitten der Domain in mehrere kleinere Kollisionsdomänen welche identisch aufgebaut sind um eben Multicast Traffic, Broadcasts usw gering zu halten.
Dies braucht allerdings Zeit da dafür erst ein Konzept und die notwendige Zeit gefunden werden muss.

Klingt so ein bisschen nach dem was 802.11s macht. Hast du Lust dich da mal einzulesen und über die Vor- und Nachteile zu informieren?

batman-adv ist bei größeren Meshes tatsächlich ziemiich ineffizient und wir (also neoraider und ich) planen schon seit Jahren an einer Alternative. Erstmal ist jedoch Gluon wichtig. Wenn wir Vollzeit dran arbeiten könnten, sähe das vielleicht anders aus, aber im Moment studieren wir beide noch. Ich habe auch noch einen Plan die TT-Einträge zu reduzieren, aber auch das wird das Problem nur verzögern.

Ich sehe das VPN ohnehin als Übergangslösung bis genügend Funkstrecken vorhanden sind, denn das ist ja bei Freifunk unser eigentliches Ziel. Das „Internet“ an wenigen, gut (1Gbit/s symmetrisch) angebundenen Standorte einzuspeisen ist sehr viel sinnvoller als viele Hotspots (Knoten ohne Meshnachbarn am DSL) aufzustellen.

Trotzdem ist uns das Problem der Grundlast bewusst und das batman-adv in Gluon ist gepatcht um jene in etwa zu dritteln. VPN über DSL-Anschlüsse ist aktuell einfach Realität.

Aktuell ist aber auch Realität, dass Freifunk an gedrosselten DSL-Anschlüssen oft nicht umsetzbar ist. Provider wechseln hilft.

5 „Gefällt mir“

Habe ich nicht verstanden. Wer soll irgendwas flaggen? Anhand welcher Kriterien? Wir sind hier im Layer2. Wir kennen gar keine IP-Adressen. Alles was wir kennen sind Ethernetframes. Mit Source- und Destination (Mac)-Adresse. Nothing else.

Ja das sehe ich auch so. Ich behaupte mal so: Der Großteil des Traffics ist nicht BATMAN (speziell OGM), sondern Broadcast Traffic. Jedenfalls würde ich das gefühlt sagen, wenn ich mir den OGM Traffic anschaue:

batctl td mesh-vpn -n -p 1

Und im Vergleich dazu den Broadcast Traffic

batctl td mesh-vpn -n -p 8

Leider scheint das eingebaute tcpdump sehr stark behindert zu sein.

Das ist sicherlich toll, aber da gibt es ja diesen Spruch mit den Lorbeeren und dem Ausruhen.

Nein, wie oben auch von anderen Benutzern angesprochen, führt es auch jetzt wieder dazu, dass DSL-Leitungen verstopfen. Es funktioniert an schnellen DSL-Leitungen gut, an langsamen nicht. Streiten wir uns nicht darüber, suchen wir nach einem besseren Weg.

Das wirkt eher wie ein rausschieben das Problems, statt das strukturelle Defizit anzugehen.

Geiles Stichwort, werde mich dazu belesen.

Stichwort? Welches Protokoll hab ihr im Auge?

Was bedeutet TT?

Aber der Durchsatz bereits über eine Handvoll Hops ist bescheiden. Das steht diesem Plan im Wege.

Okay, dann könnte man die Idee evtl. so umstricken: Broadcast-Pakete von Batman-adv generell vor VPN-Tunneln blockieren und hier einen effizienteren Mechanismus finden. Z.B. einfach nur dem Gateway mitteilen, welche MACs hinter diesem Tunnel hängen.

Ich werde mich auch Mal dranmachen, genauer zu verstehen, was da eigentlich wirklich über die Leitung fliegt. So genau scheint das niemand zu wissen.

Danke für eure Kommentare, hab schon deutlich mehr verstanden.

Da gibts auch ne Präsentation zu:

Es wird z.B. gesagt, dass OGM bezogen auf die Clients (nicht Nodes) konstant bleibt, während Broadcast proportional zur Zahl der Clients ist. Da die Zahl der Clients normalerweise mit der Zahl der Nodes ebenfalls mitwächst, gibt es also zwei Baustellen.

Bei Broadcast kann man einfacher mehr machen (ARP wird z.B. bereits gecachet, ICMPv6-ND noch nicht, wie @CyrusFox sagt, ist bei Multicast auch noch was zu holen). Dementsprechend macht es natürlich sinn zuerst mit so wenig Aufwand wie möglich so viel Traffic wie möglich zu eliminieren.

Wir arbeiten in dem Tempo wie es unser restliches Privatleben erlaubt, ich bitte dich da ein wenig Rücksicht zu nehmen. Keiner ruht sich hier aus, wir haben genügend Baustellen woran wir dauerhaft am arbeiten sind. Alles auf einmal geht halt nicht. Ich habe durchaus Verständnis für deine Punkte, aber auch vehementes drauf beharren ändert nicht die Zeit-Probleme oder technische Gegebenheiten.
Es wird dran gearbeitet und aus Erfahrung bewirken Diskussionen wie diese hier eher das Gegenteil. Daher möchte ich dich bitten die ehrenamtliche Arbeit der Leute hier nicht als „Lorbeeren“ zu sehen auf denen wir uns ausruhen.

3 „Gefällt mir“

Wir planen ein eigenes Protokoll, das so grob zwischen Layer-2 und 3 arbeiten soll und auf dem Babel-Algorithmus basiert.

Translation Table. Das ist die Übersetzungstabelle der Client MACs zu Knoten MACs. Im Moment ist die global, d.h. jeder Knoten weiß welche MAC wo ist und wird über Änderungen informiert. Das muss eigentlich nicht so sein.

1 „Gefällt mir“

Letzteres. Tendenziell sogar noch höher. Wird halt mit jedem neuen Router in der Domaine mehr.

Noch was. Diese Grundlast trifft die Provider NULL! Alles worauf die schauen ist die Peak-Last: was geht in der Spitze durch. Nur wenn die Leitungen voll sind (und wenn es nur ein paar Minuten am Tag ist), müssen sie ausbauen. Genau auf diese Weise werden sie auch von ihren Upstream-Providern abgerechnet: nach Peak-Last.

Schaut o2 jetzt nur auf diese einzige Zahl, nämlich Integral des Verbrauchs über die Zeit, dann ist das ein verzerrendes Argument.

Entscheidend für die Kosten sind ausschließlich Latenz und Peak-Bandbreite!

Drei Bilder. Vor Freifunk. Nach Freifunk (an der Gütersloher Community). Jetzt (an der Domäne Ruhrgebiet).

Vorher:

Nachher:

Jetzt:

2 „Gefällt mir“