Ja, ausgiebiges testen ist selbstverständlich!
Gluon Module klingt gut, habe ich aber noch nicht viel Ahnung von.
Ja, der korrekte code muss, mit Anpassung der Interface Nummer so aussehen:
uci set wireless.@wifi-iface[1].disabled=0; uci set wireless.@wifi-iface[0].disabled=1; uci commit wireless; wifi
Ich würde hier ohne uci commit arbeiten. Dann bleibt dieser Zustand nur im RAM und zerschreibt nicht den Flash-Speicher wenn der Zustand mal Online / Offline flippert.
Böse geantwortet auf diese Steilvorlage: Andere wollen einen Qualitätslevel an Connectivity.
Zum Wachseln „Über die Nerdcommunity“ benötigen wir soetwas wie „dauerhaft zufriedene NutzerInnen“ (oder „User-Experience“ auf Neudeutsch), die dann letztendlich dafür auch zu spenden bereit sind.
Natürlich kann man versuchen, User zu bekehren („Wlan ohne Internet ist auch ganz schön, schaut mal, man kann lokale Darknets bauen“). Finde ich auch spannend. Entspricht nur nicht der Erwartung der UserInnen. Die sind nicht so nerdig wie ich oder vielleicht andere hier.
Und wenn wir Reklame laufen wollen für „Freifunk vernetzt $ORTSCHAFT“, dann ist der Anspruch „mit Internet“ und nicht „mit einer SID in der man mit glück eine IPv4 erhält und dann schauen kann, ob man mit Portscans was findet was irgendwie zum Verweilen einläd“
Nur mit Leuten, die die Erfahrung machen „Wenn Freifunk draufsteht, dann geht’s Internet noch schlechter als bei $PROVIDER“ (halbtote Drones, Wackelmesh, Providerwerdungs-Experimente, leergelaufener IPv4-Pool, irgendwas ist fast immer.), dann hat man schnell einen Ruf, den man etwa so gut wieder los wird wie derzeit die Telekom mit ihrer SIP-Telefonie.
Ja das mag sein, aber ohne Qualitätsansprüche wird das hier nichts. Es müssen alle Fälle abgebildet sein (Keine Race-Conditions, Clients nicht rauswerfen wenn diese noch verbunden sind usw). Es gilt nicht „Wer macht hat recht“ sondern „Wer’s korrekt macht hat recht“. Schnell mal nen Feature ohne ordentliche Qualitätsprüfung schreiben ist nicht drin. 
Jedes Stable Update ist von 2 Personen signiert und qualitativ bedenkliche Pakete kommen nicht mit rein.
Oder sollen wir Gluon wegwerfen und zu Freifunk Advanced zurück? Da haben wir genau dieses Chaos gehabt und jeder der die alte Firmware verwendet hat und zu Gluon wechselte ist über die ordentlichere Planung froh.
Wenn dieses Feature nicht ordentlich implementiert ist dann werde ich es nicht signieren und auch keine Support dafür anbieten. Dazu zählen auch Probleme die evtl nicht direkt mit diesem Feature zu tun haben, man muss hier aussortieren damit man nicht unnötig Energie in Debugging verschwendet bei einer Firmware die vom Besitzter aufgebohrt wurde und sich nicht wie erwartet verhält.
Was den Rest angeht: Ich rede hier von Bedenken bezüglich der Softwarequalität, da sind alle subjektiven Meinungen erst mal außen vor. Ein nicht sauber zu implementierendes Feature ist auch bei Wunschdenken nicht plötzlich realistischer umzusetzen. Was nicht 100% heißt das es hierbei so ist aber alle Features die so nicht sauber zu lösen sind werden zumindest auf Eis gelegt bis man einen besseren Vorschlag hat es zu lösen.
Mag etwas forsch klingen, das stimmt. Aber wenn man sich um die Firmware Releases kümmert und vor allem vom beruflichen her ebenfalls diese Erfahrungen mitbringt, dann ist man bei so etwas doppelt vorsichtig und muss auch mal den „Versions-Nazi“ raushängen lassen. Ich weiß das man damit nicht unbedingt beliebt ist, aber ansonsten hätten wir keinerlei Qualitätssicherung und totales Chaos.
Ich weiss wirklich nicht, woher Du die Unterstellung nimmst, irgendwer wollte obiges Script „as is“ irgendwo deployen oder „1:1“ in eine Gluon-Paket umwandeln.
Deine Bedenken hinsichtlich der Softwarestabilität teile ich. Nur eben die Art mit der Du Aktionismus unterstellst(?) ist mir fremd.
Wir sind hier -nach meinem Dafürhalten- derzeit dabei zu diskutieren
a) wollen wir das überhaupt und auf welcher Basis (default-Setting)
b) auf was soll dann umgeschaltet werden (SSID)
c) wie sollen die Kriterien sein für die Umschaltung (inkl. Hysterese)
Bei den folgenden Schritten sind wir noch gar nicht
d) Musterscript
e) Implementation
f) testing
g) regression test
…
Exakt so sehe ich das auch. Normalerweise bin ich der Bremser, der vor dem Ausrollen für alle Tests im kleinen machen möchte.
Das Musterskript läuft zunächst einige Wochen bei ausgewählten Personen, die genau wissen was passiert und schreibt bei jeder Aktion die macht logs oder sogar E-Mails. Anhand dieser Daten wird optimiert falls nötig.
Irgendwann im neuen Jahr ist man dann bei einer langfristig stabilen Fassung, die dann hoffentlich auch ohne technische Bedenken in Gluon aufgenommen werden kann. Natürlich erstmal nur in den Beta Zweig.
Dieses Feature ist mir ein großes Anliegen, ein Grund mehr es lieber langsam und richtig zu machen.
Hallo alle zusammen, ich finde hier sind gerade einige verschiedene „Fässer“ aufgemacht worden. Die meiner Meinung nach auch jeweils getrennt diskutiert werden sollen. Vielleicht mag jemand vo euch es einmal ein wenig wieder so gestalten, dass klar ist über welches Thema gesprochen wird. Ich finde es immer schwierig Grundsatzdiskussionen nur in einem Forum zu diskutieren. Vielleicht tue ich euch auch jetzt unrecht mit meiner Betrachtung. Lg Inge
@phip und @CyrusFox ich find es ja toll dass ihr dass durch euere Nerdbrille seht und gleichermaßen erschreckend wie hier gefühlt eher versucht wird diesen Vorschlag kaputt zu reden obwohl es doch regen Zuspruch gibt. In erster Linie erwartet der 0815 User dass sein Internet geht und nicht dass irgendwelche internen Services, von denen er mit großer Wahrscheinlichkeit nichtmal Kenntnis hat, nicht funktionieren. Wenn das bedeutet, dass die SSID geändert wird um die 30 Leute an der Bushaltestelle nicht zu vergraulen, nehme ich dass lieber in Kauf als euch beide zu verärgern.
Ich verstehe Dich Frank, glaube es mir bitte. Glaub mir bitte auch, dass ich nicht im Stande bin dies zu implementieren, und wenn, dann würde garantiert etwas schief laufen. Aluhutaufsetz Darüber hinaus könnte dieser Mechanismus dazu genutzt werden Freifunk „abzuschalten“ Aluhutabsetz. Ich habe leider wichtigere™ Baustellen und leider auch keine Zeit dafür. Ich bin auch persönlich betroffen von dem Problem:
Man muss den Nutzern vermitteln, dass Freifunk frei ist und von Freifunkern aufgebaut ist. Jeder kann erheblich dazu beitragen, indem Knoten aufgestellt werden oder darüber gesprochen wird. Freifunk ist kein AP für eine Bushaltestelle, kann aber dazu genutzt werden, wenn es die Menschen vor Ort es aufbauen und stabil halten.
phip dass ist ja auch okay wenn du weder zeit noch know how dafür hast aber dann schmeiss doch nicht gleich den Leuten Knüppel mit Begründungen mit fraglicher relevanz zwischen die Beine die etwas zur besseren Nutzungswahrnehmung beitragen wollen. Genau so kam das da oben rüber und die Begründung dass dann internes Sharing nicht mehr geht ist für mich und die meisten anderen derzeit völlig irrelevant wenn die Infrastruktur in fast allen Regionen noch meilenweit davon entfernt ist sowas sinnvoll zu nutzen. Ich halte es auch für unwahrscheinlich dass es in absehbarer Zukunft ein größeres Interesse abseits von Internetkonnektivität gibt und daher sollte man genau das, sofern es allgemeiner Konsens ist, verfolgen.
Dein quote ist ein Henne-Ei Problem. Gerade in der Startphase müssen wir imho dafür sorgen, dass es möglichst reibungslos funktioniert um mehr Leute dafür zu begeistern und nicht zu verschrecken. Der hier eingebrachte Vorschlag ist daher sehr sinnvoll.
aber diese Begründung habe ich nun mal, vielleicht interessiert dies jemanden.
Meine Meinung ist die Menschen sollen über Freifunk aufgeklärt werden, es aufbauen und es nicht nur bloß nutzen. Ich wähle mich auch nicht in ein fremdes AP ein und verlange, dass es funktioniert.
Ich halte es für sehr wahrscheinlich, dass dem Freifunk der große Durchbruch gelingen wird. Der allgemeine Konsens darf „ihre Sonderwünsche“ gerne in die Tat umsetzen, da es ja Freifunk ist und es jedem frei zusteht die eigenen Ideen in die Tat umzusetzen. Oder doch lieber einfach nur der Freifunker vor Ort, der besser aufgeklärt werden sollte sich besser um Konektivität seines Knotens zu sorgen und zu kümmern. Ansonsten kann er meiner Meinung nach selbst den Knoten abschalten und nicht irgend ein Superduper-Skript, der erst noch erfunden werden muss.
Mal davon abgesehen das ich den Vorschlag hier vollkommen verstehe, musst Du verstehen, dass ich nicht schizophren sein kann und meine Meinung
so einfach über Board werfe, die mich auch daran hindern wird irgend eine Motivation aufzubauen mich in die Lösung des Problems einzuarbeiten und es zu beseitigen, da es meiner Meinung mit Gesprächen und Aufklärung der Menschen und dem Miteinander schneller beseitigt werden kann und einen viel größeren Nutzen erzielt.
Ich möchte nochmal auf die ursprüngliche Zielstellung hinweisen:
Viele im Freifunk genutzte Geräte haben nicht nur WLAN sonder auch einen Uplink über Mobilfunk.
Solange sie jedoch per WLAN mit Freifunk verbunden sind wird der Mobilfunk Uplink nicht verwendet.
Die allermeisten potentiellen Freifunk Nutzer verwenden das Internet zur Kommunikation, diese soll binnen Sekunden (mindesten Minuten) beim Empfänger ankommen.
Es gibt auch Dienste innerhalb des Freifunk Netzwerks, auch diese sind in aller Regel nur über mesh oder vpn-mesh zu erreichen. Diese werden von einer kleinen Minderheit der Freifunk User genutzt, trotzdem soll diesen nicht zu Gunsten der großen Masse, auch nicht in Ausnahmefällen, der Zugang verwehrt bleiben. (SSID ändern statt abschalten)
Damit also niemand in einem offline Knoten hängen bleibt sollte die SSID Freifunk auch den Anspruch haben tatsächlich Freifunk anzubieten.
Ein einzelner Konten ohne Uplink ist kein Freifunk!
@adorfer und ich haben ein Skript entwickelt das zuverlässig beim Verlust der Internet Konnektivität die SSID ändert. Das Kriterium ist momentan aber noch nicht sonderlich ausgereift. Ich möchte lieber mit der Ausgaben von „route -A inet6“ den gültigen Freifunk internen Gateway identifizieren und diesen als Kriterium nutzen.
Auch die Ausgabe von „batctl gwl“ scheint mir ein geeignetes Kriterium zu sein. Dies als primäres Kriterium zu verwenden bedeutet dass dieses Skript solange der Knoten normal am Netz ist keinerlei zusätzlichen Traffic verursacht.
Um false positive zu vermeiden könnten wir die Kriterien verknüpfen.
Ich finde, dass die SSID nicht dynamisch gesetzt werden muss. Wenn wir zwischen den folgenden Situationen unterscheiden, lässt sich das erklären.
In Fall 1 ins natürlich alles gut.
In Fall 2 funktionieren typischerweise genutzte Dienste nicht, da sie nicht lokal erreichbar sind. Endgeräte zeigen dann ein Ausrufezeichen neben dem Netzwerk-Symbol an und trennen sich wieder, wenn der User das nicht anders konfiguriert hat. Häufig tritt dieses Szenario dann auf, wenn vorübergehend etwas nicht stimmt.
In Fall 3 trennen sich Endgeräte eigentlich immer sofort wieder oder versuchen es endlos, sich zu verbinden.
In Fall 4 sollte der Node die SSID gar nicht erst ausstrahlen, da hier nichts funktionieren kann.
So sehe ich in keiner Situation einen Vorteil in der Verwendung anderer SSIDs.
„Der Node ist allein“ ist zumindest für Leute, die einen mobilen AP brauchen noch tragbar, z.B. ein NAS oder einen Drucker anzusteuern. (zumal die Dinger heute im Consumer-Bereich fast alle per Wlan daherkommen und adhoc-modus „von Hand“ niemandem zuzumuten ist.)
Äh, ja schön. Aber das doch bitte dann nicht Freifunk nennen?
Ich würde die Punkte 2-4 zusammenfassen und dann die SSID umbennen. Freifunk sollte immer Internet beinhalten. Evtl. könnte man auch per Picowebserver auf das technische Problem kurz hinweisen, statt nur einen Fehler auszugeben.
Freifunk nur mit Internet und eine zweite ssid die sowohl mit als auch ohne aktiv ist. So könnte derjenige, der wirklich mal eine Übertragung ohne Internet macht, diese noch durchführen.
Hätte auch nichts gegen 2 SSID:
Freifunk: Freifunk mit oder ohne Internet
Internet@Freifunk: Internet over Freifunk
Reale Anwendungen die kein Internet benötigen:
VoIP unter Nachbarn
Backups ein paar Straßen weiter lagern
Ein NAS um Dateien mit den Nachbarn zu tauschen
ich halte nichts davon, die SSID zu ändern. Freifunk kann und soll auch ohne Internet funktionieren.
In anderen Regionen der Welt vernetzt man sich, um Wissen und Inhalte zu teilen. Auch in Katastrophenszenarien spielen selbstorganisierende Meshnetzwerke eine große Rolle.
Wie wäre es mit einer Infoseite, die anzegeigt wird, wenn man nicht erreichbare Adressen aufrufen will (bzw. weiß der Router auch schon, dass er keinen Zugang zum Internet hat)?
Aufruf heise.de => geht nicht => Infoseite mit dem Hinweis, dass es kein Internet gibt, aber man die lokalen Dienste nutzen kann - und eine Liste lokaler Dienste z.B.
Falls es keine lokalen Dienste gibt, einfach Werbung für freifunk machen. So in der Art „Ich bin hier noch allein, aber wenn mehr mitmachen können wir ein tolles Gemeinschaftsnetz bauen und Dienste anbieten“
Wäre das nicht auch wieder die Diskussion mit dem Splash-Screen? Außerdem dürfte das beim 08/15-User, der auf dem Handy die Facebook-App nutzt, nicht funktionieren. Der merkt dann nur, dass das Internet bei Freifunk nicht funktioniert und ist sauer. 90% werden da nicht weiter nachforschen.
Und natürlich ist Freifunk ohne Internet immer noch Freifunk. Freifunk wird meiner Meinung nach aber auch erst interessant, wenn ein gewisses Netz aufgebaut ist. Und das wird in vielen Regionen ohne das Argument Internet, wenn überhaupt, nur sehr schleppend laufen.
Irgendwer hatte doch schon mal den Vorschlag von 2 WLANs gemacht: Eins, das nur erscheint, wenn Internet verfügbar ist, und eins, das auch ohne Internet besteht und für die (nicht abwertend gemeint) „Hardcore“-Freifunker und andere Dienste besteht.
Die Info Seite ist aufgrund des Pico Peering Agreements nicht möglich und würde auch ein zentrales Problem nicht lösen:
Clients die im WLAN hängen und keine E-Mails und Instant Messenger Nachrichten erhalten obwohl sie als alternative einen Mobilfunk Uplink hätten.