Etwas gegrübelt und dann ist mir aufgefallen - die jeweiligen Freifunknetze sind lokal mit allen Vorteilen. Uni-/Multicast und medial nutzbar.
Also müsste z.B. ein chromecast dongle an irgendeiner FF-Node von jedem Gerät an einer anderen Node zu sehen und kontrollieren sein. Ausprobiert an der lokalen Node - problemlos. Danach mal quer durch die Stadt und über Smartphone getestet - war überall fehlerfrei zu sehen.
Da viele Geschäftsinhaber potentielle Aufsteller von Freifunknodes sind und hier in Lohmar die „Stadtmacher“ mit zu den Förderern zählen…
Da auf Infoterminals immer was zu sehen sein sollte, fiel die Wahl auf chromecast, der sich selbstständig aus dem Netz mit einer Playlist bedienen kann. Der Test mit Facebook fiel kläglich aus - zuerst problemlos doch bei Umstellen des Albeninhaltes waren diese schliesslich nicht mehr im chromecast zuzuordnen. Da im Playout auf dem Bildschirm der Benutzer angezeigt wird, empfiehlt es sich, ein Freifunk userprofil dafür anzulegen.
Der Test mit Flickr (obwohl offiziell von Flickr nicht unterstützt), aber mit Zugriff auf die API klappte reibungslos:
Live- und Videostreaming ist wohl die Ausnahme, aber bei Liveveranstaltungen überall in der Stadt Infoterminals laufen lassen zu können über Freifunk - oder aber nur ein Display mit Infos zu Freifunk im Schaufenster stehen zu haben und dem Hinweis „Hier gibts Freifunk“ - ist schon ein Instrument, besser wahrgenommen zu werden.
Beispiel channel 01 Playout mit aktiviertem Guest mode. So könnte jeder vor dem screen per Handy Inhalte darauf senden:
Mit dem Aufbau lassen sich natürlich auch Flüchtlingsunterkünfte mit Inforterminals bestücken, die von irgendwo aus dem FF-Netz mit Infos bestückt werden. Oder von Irgendwo aus den weiten des Internets werden einfach die Albeninhalte bei flickr für die Anzeigen geändert;)
Eine Ansteuerung mit python über GitHub - home-assistant-libs/pychromecast: Library for Python 3 to communicate with the Google Chromecast. wäre von einem im lokalen Feifunk-Netz natürlich auch möglich.
11 „Gefällt mir“
auf einem kleinen Netbook webfs als Lieferanten der clips installieren:
und dann noch python und pychromecast
ubuntu:
apt-get install webfs
apt-get install python
apt-get install pip
pip install pychromecast
Kleiner Hack des example-scripts, um die clips vom lokalen rechner auf den chromecast auszuspielen:
"""
Example that shows how the new Python 2 socket client can be used.
"""
from __future__ import print_function
import time
import sys
import logging
import pychromecast
import pychromecast.controllers.youtube as youtube
from netifaces import interfaces, ifaddresses, AF_INET
def ip4_addresses():
ip_list = []
for interface in interfaces():
for link in ifaddresses(interface)[AF_INET]:
ip_list.append(link['addr'])
return ip_list
if '--show-debug' in sys.argv:
logging.basicConfig(level=logging.DEBUG)
global numclips
numclips=10
global activeclip
activeclip=0
myadresses=ip4_addresses()
print ("IP-Adressen lokal: ",myadresses)
# hard coded - TODO - check for the one with 10.xxx.xxx.xxx
wireless = myadresses[2]
print ("My wireless IP: ", wireless)
cast = pychromecast.get_chromecast("Freifunk Chromecast 01")
yt = youtube.YouTubeController()
cast.register_handler(yt)
cast.wait()
print()
print(cast.device)
time.sleep(1)
print()
print(cast.status)
print()
print(cast.media_controller.status)
print()
if '--show-status-only' in sys.argv:
sys.exit()
if not cast.is_idle:
print("Killing current running app")
cast.quit_app()
time.sleep(5)
url="http://"+wireless+"/freifunk/videos/freifunk"+str(activeclip)+".mkv"
print("Playing: ", url)
cast.play_media((url), "video/mp4")
t = 0
activeclip = 1
while True:
try:
t += 1
if activeclip > numclips:
activeclip = 1
if t > 10 and t % 3 == 0:
print("Media status", cast.media_controller.status)
# print("Player state", cast.media_controller.status.player_state)
if t > 30 and not cast.media_controller.status.player_state == "PLAYING":
t = 0
url = "http://"+wireless+"/freifunk/videos/freifunk"+str(activeclip)+".mkv"
print ("Playing: ",url)
cast.play_media((url), "video/mp4")
activeclip = activeclip + 1
time.sleep(1)
except KeyboardInterrupt:
break
cast.quit_app()
3 „Gefällt mir“
Ich möchte anmerken, dass vor einem roll-out an zig Gewerbetreibende mit zentral gesteuertem Kontent zu prüfen sein müsste, ob das nicht in den Bereich „Rundfunk“ fällt, wo man gewissen Regularien unterliegt.
Eher nicht - ich hab’ bei Vodafone Handy TV auch nichts anderes zusammengestrickt. Und das ganze gibt’s schon als Fallbeispiel in Form der diversen Playout-Systemen über den Supermarktkassen - nur mit wesentlich mehr Aufwand für die Technik und Steuerung. Dafür bieten die POI/POS-Systeme aber auch wesentlich mehr Möglichkeiten der Ansteuerung. Rundfunk heisst eine Quelle massenhaft verteilen - hier ist es point 2 point nur zentral gesteuert.Gerade in den Gaststätten mit Node hängen Screens, die sonst nur für Sportübertragungen benutzt werden.
Oben wurde Multicast erwähnt, was je eher bedeuten würde, dass man eine Quelle generiert und das ganze unkontrollierbar auf n Monitoren wiedergegeben werden kann. Das ist nach meiner Auffassung dann durchaus eine Art Rundfunk.
Wenn die Geräte aber gezielt, mit individuellen Inhalten, bespielt werden, sehe ich da auch kein Problem.
Prinzipiell auf jeden Fall eine interessante Nutzung, mir war gar nicht bewusst, dass man dem YT-Interpreter auf den Dingern einfach so ein MKV unterjubeln kann.
Nein - ich habe geschrieben, dass es möglich ist - nicht, dass ich es bei dieser Lösung benutze.
Der Datendurchsatz über den VPN-Tunnel für HD-Videodateien war beim Testen so grottig, dass ich mich gefragt habe, wozu ich eigentlich über das Netz nach aussen gehe, wenn ich den content innerhalb des meshes beim aufrufenden Rechner hosten kann.
Der chromcast hat eine single-session, die ich ansteuere. Der ‚Multicast‘ im derzeitigen Aufbau ist einfach ein Google-Chrome-Browser, der mit parallelen usersessions die gleiche webseite auf einem Terminal ausgeben soll während einer Veranstaltung. Damit muss nur eine Webseite aktualisiert werden und die TVs auf dem Veranstaltungsgelände können das anzeigen.
Multicasting wäre z.B. ein Darwin Streaming Server oder icecast - aber die Pakete als Multicast würden viel zu viel Traffic generieren bei der schwachen Struktur momentan…
P.S.: das mkv ist ein h264 mit AAC audio = divx hd profil, also auch von noobs mit divx converter schnell zu erstellen [bei AC3 Audio kneift der chromecast 
]
P.S. 2: image dateien für slideshow gehen ja von android aus - ich muss den cast.play befehl noch mit dem richtigen mime-type raussuchen/testen) - muss zugeben, dass ich davon bislang 0 doku gelesen hab.
P.S. 3: will das ganze jetzt von meinem Netbook auf den raspberry pi verschieben - muss nur erstmal mit jessie-update durch sein.
Etwas gegrübelt und dann ist mir aufgefallen - die jeweiligen Freifunknetze sind lokal mit allen Vorteilen. Uni-/Multicast und medial nutzbar.
Also so interessant die Idee auch ist gibt es ein Problem:
Multicast wird von Batman wie Broadcast behandelt und an jede Node geschickt, ob da jetzt ein Chromecast Dongle dran ist oder nicht.
Broadcast & Multicast sollten nicht nur wenig, sondern gar nicht verwendet werden. Anwendungen die Multicast oder Broadcast benötigen, sollen im Mesh nicht verwendet werden. Dies stört die Mesh Performance enorm.
Dann eher ein vorkonfigurierten Unicast Server in den Settings.
Dazu kommt das die Freifunk-Router so gut wie sämtlichen Broadcast / Multicast Traffic filtern, was natürlich nicht der Fall ist wenn man z.b. selbst Batman auf Geräten fährt.
Stimmt - ich hab die udp Broadcasts von bat gestern auf dem Client-PI beim Einrichten der Firewall-Regeln für wlan zu sehen bekommen -
trotzdem muss es etwas wie broadcast/multicast ungefiltert geben - denn ich habe an anderen freifunk nodes beim Testen den Stick sofort angezeigt bekommen. Kein langer Netzscan, sondern wie bei Broadcast ping gabs eine direkte Antwort vom Stick - jepp, da bin ich. Response in unter 3 Sekunden.
Bei den lokalen Tests habe ich das Monitoring mit dem dgn2200b verwendet (www.netsecdb.de/node/3490) um zu kontrollieren, dass der vpn-Tunnel den Traffic nicht bekommt.
Bei den Tests von den anderen Lohmarer Freifunk Nodes (da gibt es noch keine Mesh-Verbindung) - geht der Stream durch den einen Tunnel nach Wuppertal und von da wieder zurück. Solange das Mesh-Netz in Lohmar nicht dichter ist, braucht jede node den uplink für die Versorgung der clients im Netz.
Gewisse Dinge gehen auch durch, das stimmt. Aber es ist trotzdem davon abzuraten, jeder Broadcast belegt Airtime auf den Nodes. Einmal auf dem AP Interface und natürlich um das Batman Paket via Mesh Verbindung oder VPN an die nächste Node zu verteilen.
Wenn ein Paket einmal in einem Batman-Frame verpackt ist, dann kann dieses Paket nicht mehr gefiltert werden.
Iptables & Ebtables lassen sich nur auf reine Ethernet-Frames anwenden. Die UDP Broadcasts werden also auch über den VPN-Link verschickt.
Bei kleineren Meshes mag das nicht ins Gewicht fallen, aber ab 70~ Nodes solltest du es besser lassen. Vor allem bei vielen Chromecast Dongles.
Wenn die Dongle z.b. nur lokal genutzt werden sollen dann könnte man über ein zusätzliches Batman Interface nachdenken welches nicht via VPN weitergeleitet wird.
In Düsseldorf betreiben wir Batman auf einem VLAN-Interface auf mesh0, d.h. wir können zusätzliche Batmant Interfaces anlegen oder auch völlig andere Meshing-Protokolle simultan betreiben.
Das wäre zumindest ein Ansatz um in lokalen Wolken Streams anzubieten 
1 „Gefällt mir“
Wir reden aneinander vorbei. Der chromecast Traffic ist reiner unicast. Lediglich die Bezeichnnung multicast im Schema, weil dort EIN Chrome Browser über multi-user-setup an mehrere chromecast gleichzeitig per unicast versendet - also superkorrekt wäre ‚Multiple unicast‘. Seit gestern habe ich das Setup vom Netbook auf einen raspberry pi mit usb wlan-dongle tp-wl823n umgezogen. Der Raspberry hat seine ufw Firewall-Regeln. Lediglich Bandbreitenbegrenzung für outgoing traffic vom webfs habe ich noch nicht eingerichtet (falls sich doch ein user von den lokalen nodes auf den service verirrt und Last erzeugt) Vielleicht setze ich da aber auch einfach noch eine Regel, die Zugriff von wlan0 auf die MAC-Adressen der chromecasts limitiert.
Das Trafficmonitoring auf dem dgn2200b sowie das vom Raspberry läuft, um eben das multicasting oder broadcast traffic zu erkennen/verhindern. Ach ja, wenn ich von Mesh schreibe, ist damit nicht das Mesh-Network gemeint, sondern, dass der Traffic mit den clients zwischen den Nodes ausgetauscht wird und nicht durch den Tunnel geht.
Beim Monitoring am raspberry ist mir dann aufgefallen, dass die bat-udp pakete nicht nur zum VPN-Tunnel gehen, sondern der client die als broadcast auch empfängt. Das Netbook hatte ich bei der Programmierung vorher firewallmäßig nicht soweit eingeschränkt, dass es aufgefallen wäre. Vielleicht sollte man die clients davon noch abschirmen - geht die nix an.
Mittlerweile habe ich Tests für h264 mkvs, jpeg-images und mp3-clips gefahren. Sourcen liegen auf GitHub - cmarxmeier/freifunk_loopcast: Use Freifunk mesh network to set up infoterminal with chromecast and feed from local client workstation - mp3 id3v2 Metadaten und Frontcover-Übermittlungs ans chromecast sind noch TODOs - geparst sind die Werte schon.
Das aktuelle Schema ohne doppeldeutige Beschriftung:
UPDATE: Isolation von unauthorisierten FF-clients über arptables → Howto im git-repo
UPDATE2: „Chromecast nutzt Multicast DNS zum Auffinden aktiver Cast-fähiger Geräte im aktuellen Netzwerk, auch als Device Discovery bezeichnet; es handelt sich hierbei um das Standardverfahren seit Einführung der Version 2 des Google Cast SDK.“ lt. Wiki. Wie also vermutet, nur bei der Initalisierung der Verbindung vom Rechner/Raspberry zum Chromecast. Das kostet weniger ‚Brot‘ als ein arpscan auf die MAC-Addresse.
2 „Gefällt mir“
Das erste Mal einen chromecast durch den Tunnel über eine andere FF-Node angesteuert und dementsprechendes Gefrickel wegen des fehlenden MDNS. Hab’s im github dokumentiert.
Der eigentliche Traffic ist unicast, aber für’s Auffinden der Geräte wird mdns verwendet. Bei nicht lokalen Geräten muss also am lokalen avahi rumgeschraubt werden, um die Geräte ‚sichtbar‘ zu machen.
Wenn die MAC-Adresse des Gerätes bekannt ist (per chromcast app auslesen oder lokal ansteuern und dann mit arp-n auslesen), per arping die IPv4 ermitteln und einen Eintrag in /etc/avahi/hosts aktualisieren
Unter /etc/avahi/services eine .services Datei mit den Identitätsdaten des Sticks einspielen (die bleibt dann immer gleich). Nur bei einem avahi daemon im lokalen Netz eintragen, sonst gibt’s Duplikate.
Siehe mdns readme und chromcast.service.
P.S: arptables firewalling muss abgeschaltet sein und INPUT auf ACCEPT stehen - Eintrag der Stick-MAC Addresse reicht da nicht - der kommt ja über diverse Hops:
arptables -L -n
Chain INPUT (policy ACCEPT)
Nein ich denke wir reden nicht aneinder vorbei. Es ist völlig nebensächlich ob es sich nur geringe Datenmengen handelt. MDNS wurde bereits in Lübeck getestet und ab mehr also 50~ Nodes (Denn dafür muss man die ARPTables Firewall abschalten) wird es unbenutzbar und belegt auf allen Nodes durchgehend Airtime.
P.S: arptables firewalling muss abgeschaltet sein und INPUT auf ACCEPT stehen - Eintrag der Stick-MAC Addresse reicht da nicht - der kommt ja über diverse Hops:
arptables -L -n
Chain INPUT (policy ACCEPT)
Genau sowas solltest du hier nicht schreiben, die Arptables Firewall ist absolut notwendig ansonsten überlastet diese Node mit jedem Client Traffic das Mesh.
Ich halte nichts davon hier solche „Howtos“ oder eher „Not-Todos“ zu vertreiben, du kannst nicht einfach interna der Firmware modifizieren. Gewisse Teile davon haben nicht angefasst zu werden da du mit deiner Node sonst das ganze Mesh störst. Der ARP Filter ist Tabu, dieser muss auf allen Nodes aktiv sein, denn wir können nichts Filtern was bereits im Batman-Frame ist, der Filter muss vorher den ungewünschten Traffic aus dem Mesh fern halten.
Es ist außerdem ein Unding das du dich nicht vorher ausreichend über diese Themen informierst. Niemand hat ein Problem mit Engagement aber wenn dann bitte anständig. Gut gemeint ist nicht gut gemacht.
Ich werde diese Thema auch noch den Admins deiner Domain naheliegen damit sie auf dich zukommen können, denn es wird Probleme geben wenn du den Arp-Filter abschaltest.
2 „Gefällt mir“
RTFMF - die arptables auf dem raspberry PI - die FF-nodes werden nicht angefasst dabei.
Nebenbei gesagt ist das arptables Paket in den gluon Firmware-Images eh nicht enthalten - da gibts nur ebtables. Daran hättest Du schon fühlen können.
Sonst kommt ein client über den Tunnel nicht auf den webfsd.
Der mdns /avahi läuft auf dem raspberry und versorgt ihn lokal mit den Infos über die chromecast-sticks - traffic bleibt unicast.
Das HowTO beschreibt client-Maschinen im Netz und wie zum Laufen bringen.
Das mag sein, wenn du allerdings schreibst das du einen Chromecast-Dongle auch an einem völlig anderem Segment finden kannst, wird hier etwas durchgelassen.
Spricht der Raspberri PI Batman? Falls ja muss dort der selbe FIlter wie auf den Nodes aktiv sein.
Guck Dir an, wie ich den chromecast finde. Ich gebe die Infos am lokalen avahi daemon ein - der chromecast dongle im anderen Netz kann ja gar nicht drauf antworten.
Das einzige, was ich dafür brauche, ist die IP vom Dongle und die kann ich mir über arping auf die mac holen. - wieder unicast.
Das FF-Netz kriegt die Multicasts dafür gar nicht mit - die bleiben zwischen python-sript und lokalem avahi-server. lediglich die unicast IPv4 Verbindung geht aus dem raspberry raus zum chromecast stick. So hat sich Google das zwar nicht gedacht, aber es läuft.
Das deckt sich aber nicht mit dieser unglücklichen Formulierung:
trotzdem muss es etwas wie broadcast/multicast ungefiltert geben - denn ich habe an anderen freifunk nodes beim Testen den Stick sofort angezeigt bekommen. Kein langer Netzscan, sondern wie bei Broadcast ping gabs eine direkte Antwort vom Stick - jepp, da bin ich. Response in unter 3 Sekunden.
Die „anderen freifunk nodes“ in diesem Absatz scheinen dann wohl lokale Nodes zu sein. Das solltest du evtl ausführlicher beschreiben 
Denn sobald Admins etwas über ARP-Filter abschalten lesen, kligeln die Alarmglocken denn ein kaputter ARP-Filter kann das gesamte Mesh zum erliegen bringen (Hatten wir bereits in der Vergangenheiten daher sind wir da sehr empfindlich)
1 „Gefällt mir“
das ist im lokalen Freifunk Netz, wenn ich den Stick reinhänge und mit Mobiltelefon/Tablett/rechner/raspberry OHNE über einen Tunnel zu gehen suche - dafür brauche ich auch keinen frisierten MDNS-Servereintrag.
Ein Bild sagt mehr als 1000Worte - das ist lokal:
Dem Fernseher im Schaufenster bei Elektro Hagen könnte ich also den chromecast verpassen und von hier aus lokal dahin ausspielen. Z.B. :
Die Grafik wurde entfernt, nachdem urheberrechtliche Ansprüche am Freifunk Lohmar Logo von Dritter Seite erhoben wurden.
oder:
Die Grafik wurde entfernt, nachdem urheberrechtliche Ansprüche am Freifunk Lohmar Logo von Dritter Seite erhoben wurden.
Den Unterschied zwischen lokal und über vpn Tunnel habe ich ausfühlich beschrieben. Für lokal hatte ich arptables Filter auf dem Raspberry gegen Fremdzugriff gesetzt. Für den Zugriff eines Chromecasts (der über den vpn-tunnel reinkommen muss) auf den Content beim raspberry kann der arptables-Filter nicht verwendet werden, deswegen dafür abschalten und auf ACCEPT - weil der Trafiic sonst geblockt würde. Genau das ist dokumentiert. Für deine Ängste kann ich nix
Bis zum Frühlingsfest soll das Gelände in der Hauptstrasse mit Freifunk abgedeckt sein. Also bietet es sich an, in dem Bereich auf Freifunk hinzuweisen - und das eben nicht nur mit Aufkleber/Flyer.
Will ich beim jetzigen Ausbau einen Stick in der Stadtbibliothek oder im Texas Grilll ansteuern, müsste ich momentan noch über vpn-tunnel gehen und mir lokale mdns-Einträge basteln, um die Verbindung hinzubekommen. Bei dem aktuellen Durchsatz wäre auch an mehr als jpeg-slideshows nicht zu denken - selbst die haben Ladezeit.
