Bei einem Unternehmerstammtisch habe ich gerade Freifunk vorgestellt und dabei Kontakte geknüpft zu dem Unternehmen, dass hier in den Bussen das Fahrgast-TV bereitstellt.
Dort haben wir darüber gesprochen, ob Freifunk grundsätzlich eine Lösung wäre, den Fahrgästen der Vestischen WLAN zur Verfügung zu stellen. Dabei würde wohl ein zweites Gerät mobiles Internet über UMTS/LTE einfangen und ein Freifunk-Router als „Abmahnschutz“ zum Einsatz kommen. In den Bussen werkeln derzeit wohl sowieso schon mehrere SIM-Karten mit verschiedene Aufgaben vor sich hin, da kommt es auf eine zusätzliche auch nicht mehr an.
Ich weiss ja, dass es grundsätzlich klappt, meine Frage ist hier, wie die ganze Meshing-Geschichte in so einem Kontext wirkt. Klar vermascht sich Freifunk auch on the road, aber halt immer nur für ein paar Minuten, wenn eine Wolke bis zur Bushaltestelle reicht. Wo die Vestische Büros betreibt, kann man sicher nochmal selber mit stationären Routern draufstrahlen, aber auch hier hat ja man ja nur ein paar Minuten was davon - hauptsächlich am Hauptbahnhof würde sich der Knoten mal 10-15 Minuten am Stück irgendwo aufhalten.
Der Hintergrundtraffic ist wohl nicht so dramatisch, weil die Busse in der Nichtnutzungszeit auch komplett aus sind. Oder wäre es sinnvoll, bei einem großen Ausbau mit entsprechender Spende an den Verein an eine „On The Road“-Domäne zu denken?
Da man, damit die die Funkverbindung gefunden wird, ein viel höheres Intervall bräuchte, müsste es eine eigene Domäne werden und damit wäre Meshing dann auch wieder nicht möglich.
Hierbei sollte Funkmeshing einfach ausgeschaltet werden und nur über VPN zur restlichen Stadt Verbindung bestehen.
So eine ähnliche Idee gab es hier mal für Aachen
Ja, meshing funktioniert so gar nicht.
Man könnte eine Mini-Domain aufsetzen. Dann hat man aber keine Meshing-partner.
Und/oder man verlängert das Intervall, dann hat man nicht nur 5s, sondern vielleicht 50s Aussetzer bei jedem Halt in der Nähe eines Mesh-Knotens bzw der Wieder-Abfahrt.
Was ich mir vorstellen könnte bei einem Innerstädischen Streckennetz: Eigene Domain, um die Nodes auf die Anzahl der Busse und Haltestellen zu beschränken. Dann bekommen die VPN-3G-Uplinks auf den Bussen noch eine riesige Hop-Penalty, um das Wifimesh auf den größeren Haltestellen zu priorisieren.
Dann hätte man an den Zustiegspunkten für die Kunden ein günstiges Internet und zudem noch weniger Traffic wenn die Busse genau dort stehen.
So wie ich das aus meinen Fahrgast-Zeiten und Gesprächen mit Busfahrern kenne, sind die Busse doch trotzdem fast den ganzen Tag, also locker mal 12 Stunden unterwegs, also eingeschaltet. Wenn ich dann des öfteren lese, dass ein Node am Tag teils mehrere GB an Traffic allein durch „Hintergrundrauschen“ verbraucht, würde so eine SIM-Karte doch arg belastet. Kann natürlich sein, das ich mich da total irre.
Wozu soll das Meshing eigentlich unterwegs dienen? Um während des Halts an Haltestellen schnelleres Netz zu haben? Ich denke nicht, dass sich das für die kurzen Momente lohnt.
Wäre es daher nicht interessanter meshing ganz zu deaktivieren und den Router ganz auf die Verteilung des Internets zu reduzieren? (bitte jetzt keine „librefunk“ etc. Diskussion; mir ist bewusst, dass Freifunk mehr ist als Internet…)
Das lässt sich mit entsprechenden Modifikationen im selben Wifi-Mesh betreiben, ohne Probleme beim Durchfahren von bestehenden Wolken zu verursachen und nutzt dann eventuell zum Spaß immer kurzzeitig als Mesh Repeater und Uplink, wenn der Bus irgendwo steht.
Vermutlich müssen sogar nur die Werte im Pfad
/sys/class/net/bat0/mesh/
angepasst werden, da über diese die komplette Funktionsweise des Batman im Mesh geregelt wird.
Einfach mal nen ls -al auf den Pfad machen und in der Batman Doku nachschlagen, was man da schönes verdrehen kann.
Wenn da ein GPS mitarbeitet und anhand der Geschwindigkeit oder gar Position bestimmte Dinge anstößt (oder abschaltet) könnte das durchaus Traffic sparen.
Aber wie wäre es mit einem Freifunk-Light. Also ein Freifunk gänzlich ohne Meshing speziell für den mobilen Einsatz, aber mit gleicher SSID und gleicher Offenheit.
Dieses wird dann nur per UMTS direkt an die Gateways angeschlossen und können von dort mit anderen Freifunkgeräten oder auch mit dem Internet kommunizieren.
Das sollte auch den Hintergrundverkehr einschränken.
The hop penalty setting allows to modify batman-adv’s preference for multihop routes vs. short routes. The value is applied to the TQ of each forwarded OGM, thereby propagating the cost of an extra hop (the packet has to be received and retransmitted which costs airtime). A higher hop penalty will make it more unlikely that other nodes will choose this node as intermediate hop towards any given destination. On the hand, a lower hop penalty will result in longer routes because retransmissions are not penalized.
Since 2014.1.0, the hop penalty is applied in a slightly different way: it is applied once for OGMs leaving on a different interfaces it has been received, and applied twice if its leaving on the same interface if that is a WiFi interface. This is done to penalize half-duplex routes, and prefer routes with changing interfaces if there is a path with similar quality available. The default hop penalty of ‚15‘ is a reasonable value for most setups and probably does not need to be changed. However, mobile nodes could choose a value of 255 (maximum value) to avoid being chosen as a router by other nodes.
cat /sys/class/net/bat0/mesh/hop_penalty 15
Mit 255 würde man schonmal verhindern, dass man beim Durchfahren einer Wolke was kaputtmacht.
ap isolation
Available since: batman-adv 2011.4.0
Standard WiFi AccessPoints support a feature known as ‚AP isolation‘ which prevents one connected wireless client to talk to another wireless client. In most situations this is considered a security feature. If the WiFi AP interface is bridged into a batman-adv mesh network it might be desirable to extend this wireless client isolation throughout the mesh network, therefore batman-adv has the ability to do just that (disabled by default). This setting only affects packets without any VLAN tag (untagged packets). The ap isolation setting for VLAN tagged packets is modifiable through the per-VLAN settings.
Entscheidend wird sein die nicht oder nur begernzt vorhandenen Volumen!
Als Fernbusfahrer weiss ich wovon ich spreche. Alle Fernbusbetreiber bewerben ihr Produkt unter anderem mit der Nutzung von Wlan. Als Fahrer habe ich spätestens am 3 Tag des Monats ein Problem, nörgelnde Fahrgäste, die sich zwar ins Wlan einloggen können aber dank der Drossel des Internetanbieters nur tröpfchenweise Daten aus dem Internet bekommen.
Einige Fernbusbetreiber gehen jetzt dazu über Mediacenter in die Busse einzubauen und senken damit den Datenverkehr ins und aus dem Intertnet weil Fahrgäste beruhigt im Wlan sind und sich mit den Inhalten des Mediacenters beschäftigen.
Wie weit mögen wir wohl kommen mit einer üblichen 5 GB Flatrate wenn täglich nur 10 Personen einen Song streamen!
Soetwas in der Art halte ich auch für wünschenswert, nicht nur für Busbetreiber, sondern auch für Menschen, die regelmäßig ÖPNV oder andere Massenverkehrsmittel nutzen und Bandbreite abzugeben haben (gehöre selbst dazu, habe aber noch schöne keine Freifunk-kompatible Lösung gefunden)
In den Bussen der RLG, mit denen ich täglich zur Schule fahre, wird gerade eine Lösung von Hotsplots benutzt
Die könnten ihre Router auch mal umstellen.
Das Problem ist halt auch, dass sich Smartphones je nachdem ob sie per GSM oder WLAN angebunden sind, sehr unterschiedlich verhalten. Per GSM sind die meisten Apps und auch Android und iOS darauf getrimmt, Daten zu sparen.
Sobald dann ein WLAN zur Verfügung steht, werden munter Updates geladen. Ganz toll ist immer ein iPhone mit veralteter Firmware an einem GSM gespeißten WLAN. Das zieht dann mal locker eben 300 MB Softwareupdate runter.
