Re: [FFP] [FFP-Orga] Diskussion bzgl. der ESSID und des Schemas der Node-Namen
Hallo Kai Am 23.03.2016 um 22:58 schrieb Kai Sommer:
Juten Tach zusammen …
Schon seit einiger Zeit brennen mir zwei Themen (s. Betreff) unter den Nägeln und nun möchte diesbzgl. gern nochmal etwas konkret nachfragen …
––––– 8< ––––– Hinweis: Eig. sollte/könnte IMHO diese Diskussion auf der user-ML stattfinden. – Da ich jedoch nicht weiß, wie gut ihr das findet, mache ich es erstmal hier. → Sollte die erste Person, die antworten will, auch finden, dass wir auf der user-ML diskutieren sollen, bitte dies nur kurz als Antwort hier senden und dann sende ich diese E-Mail nochmal auf die user-ML. :) ––––– >8 ––––– ich meine mich zu erinnern, dass wir zu einigen dieser themen eine diskussion auf der user-ml hatten. die beteiligung war halt eher mäßig.
schicks ruhig nochmal an die userliste, oder ich antworte gleich mit an die userliste...
Vorab 1: Das Folgende kann für die techn. versierteren Personen ggf. etwas DAU-mäßig erscheinen. – Entsch. das bitte und versucht mein Anliegen einf. zu verstehen und bei Begrifflichkeiten lerne ich gerne noch was dazu! :)
Vorab 2: Ich weiß, dass ich bei einigen Dingen eher schlecht informiert bin und mir durchaus Informationen fehlen, weil ich arg selten bei den Treffen bin. – Allerdings sind beide anzusprechenden Themen IMHO so essenziell, dass ich mir gewünscht hätte, zur Entscheidungsfindung auch auf den MLs, oder im Wiki etwas zu finden, was leider nicht wirklich der Fall ist. (Für Hinweise bin ich auch hier dankbar! :))
Vorab 3: Mit Folgendem will ich niemanden ans Bein pink*** o.ä. – Es gibt nen paar Dinge die ich nicht verstehe und zu denen ich mich gern unterhalten möchte. – Ich bin sehr froh über die Aktivitäten (und die Leute dahinter), die ja v.a. 2015 richtig Fahrt aufgenommen haben!
### ESSID
Also, gaaanz am Anfang vom FFP gab es APs, die haben ein Ad-Hoc-Netz aufgemacht und dies mit der ESSID "www.freifunk-potsdam.de" vershen. – Damit konnten alle Personen, die ein Ad-Hoc-fähiges Gerät hatten, im FFP surfen und wussten, dass das Netz vom FFP ist (inkl. der ja gleich mitgelieferten Domain für mehr Informationen …)
Nun ist es so, dass die (schon damals sehr geringe Zahl) der Ad-Hoc-fähigen Geräte leider nicht angestiegen ist und unser FFP-Netz gar nicht richtig genutzt/ausgelastet werden kann. Glücklicherweise haben sich jedoch Hard- und Software weiter entwickelt und nun ist es so, dass ein AP mehrere Netze aufspannen kann.
IMHO besteht ein akt. Standard-Setup aus - 1 x Ad-Hoc mit der ESSID "Mesh23" und - 1 x Infrastructure mit vom AP-Namen abgeleiteter ESSID (bspw: 254-67-sokai)
nein, das essid schema für die Infrastructure netze ist eines der folgenden: Freifunk-Potsdam-x-y z.B. Freifunk-Potsdam-254-16 bei bernd Einrichtung@Freifunk-Potsdam z.B. Kuze@Freifunk-Potsdam für das roaming netz im kuze
Die folgenden Dinge finde ich nun etwas verstörend und würde gern mal über Alternativen bzw. Gründe für den Istzustand diskutieren.
a) In allem, was nun ‚verstrahlt‘ wird, ist nicht ein Fitzel mehr als Hinweis auf den FFP zu finden ist, was ich (mindestens sehr) schade finde … – Für mich zählt leider das ‚Argument‘: „"potsdam.freifunk.de" ist zu kompliziert/verwirrend und desh. nehmen wir "Mesh23".“ nicht wirklich … :-/
doch, siehe oben lediglich das Mesh netz hat keinen hinweis mehr auf den ffp, was so gewollt ist, da: 1. es Geräte gibt, die Ad-Hoc netze nicht sehen 2. es Geräte gibt, die Ad-Hoc netze sehen, sich aber nicht verbinden können 3. selbst Geräte, die Ad-Hoc unterstützen, damit nichts mehr anfangen können, da wir aus gründen 1 und 2 dort kein dhcp mehr betreiben für die User sah es üblicherweise so aus, dass ffp nicht funktioniert und daher eher negative werbung war.
b) Im Wiki konnte ich Anfang des Jahres was zum Thema Roaming (mit batman) finden/lesen. – Ich frage mich nun, ob es nicht sinnvoller/besser wäre/ist, wenn auf allen APs als Infrastructure-ESSID (bspw.) "potsdam.freifunk.de" verwendet wird und wenn dann iwann batman läuft, geht das Roaming ‚automatisch‘ … (Das Sichtbarkeitsargument aus a) zählt hier nat. auch.
das roaming via batman betreiben wir nur in der nähe größerer stadorte, z.B Kuze, Rechenzentrum, Pub es ist technisch zwar möglich, aber keine gute idee, ein roaming netz für ganz potsdam zu betreiben. wenn interesse besteht, führe ich da noch näher aus.
c) Bzgl. der Ad-Hoc ESSID "Mesh23" hatte ich kurz nen Chat mit Marcel aus Cottbus, der meinte, dass hier ggf. "intern-ch5.potsdam.freifunk.net" (2,4GHz auf Kanal 5) und/oder "intern-ch??.potsdam.freifunk.net" nehmen könnte. (Das ist wohl so von Berlin abgeguckt …)
prizipiell ist die ssid im adhoc netz egal, das meshen funktioniert über die bssid, also könnte man das nennen, wie man will, aber wie oben erwähnt, sollte es was sein, womit kein user auf die idee kommt sich zu verbinden, um die userfrustration niedrig zu halten.
### Schema der Node-Namen
Schon seit Ewigkeiten finde, dass die AP-Benennung mal überarbeitet werden sollte. – Dies aus mehren Gründen … Hier nur zwei: 1. Sie waren ‚gewachsen‘ und desh sehr uneinheitlich. 2. Ich fand es schon immer wichtiger anhand eines AP-Namens den Standort, statt die IP eines APs erkennen zu können.
Nun ist das ja im letzten Jahr auch mal angefasst worden, leider aber aus meiner Sicht zum Nachteil und meines Wissens ohne (breitere) Definition/Diskussion eines Schemas bzw. wenigstens von Regeln. :-/
→ Ich möchte hiermit die Diskussion um ein Überdenken der Node-Namen-Konventionen (noch)mal anstoßen!
Denn zu den beiden obigen Punkten kommt für mich mom. noch folgende Problematik: Unter <http://www.freifunk-karte.de/> sind auch unsere Nodes zu finden. – Die Idee dahinter ist (einfach erklärt), eine Map _aller_ FF-Communities zu machen, in dem alle offiziellen FF-Community-API-Files [0] durchgegangen werden und alle gefunden Community-Maps zusammen gehext werden. (Unsere Nodes kommen dabei aus der OWM [1].)
[0] <https://github.com/freifunk/directory.api.freifunk.net> [1] <https://openwifimap.net>
Nun ist es aber so, dass die FF-Communities Berlin, Cottbus und Potsdam (und noch mehr) alle die OSM nutzen. Und bei der Generierung der AP-/Node-Liste für [0] alphabetisch vorgeangen wird und _B_erlin vor C und P kommt, wird bei unseren/den FFP-APs als Community Berlin angezeigt. Dazu gibt es auch ein Ticket [2], in dem der erste Kommentar die ganze Geschichte erklärt. Die Lösung der Problematik ist/wäre, eine eigene Node-/AP-Liste für Potsdam zu generieren und zur Verfügung stellen. Dies wollte ich mal probieren und bin über die Problematik mit unseren AP-Namen gestolpert … :-/
[2] <https://github.com/ffansbach/de-map/issues/26>
Wie findet man alle Potsdamer APs in der OWM? – In dem man einfach alle APs in einer Bounding Box (BB) abfragt. Problem dabei ist, dass diese Box nur rechteckig sein kann und wir leider zu nah an Berlin sind, als dass wir bei der Abfrage _nur_ FFP-APs abfragen können. Wenn man bspw. die BB des OpenStreetMap-Nodes nimmt, erhalten wir über 270 APs [3]. Nimmt man die BB der offiz. definierten OpenStreetMap-relation (basierend auf der Gemeindegrenze), erhält man 82 Nodes?
(Hinweis: [3]–[6] bitte nach dem Aufruf nochmal neu laden; is mom. etwas buggy …) [3] <http://freifunk-potsdam.de/apdb/owm-ffp_nodes-osm_node.htm> [4] <http://freifunk-potsdam.de/apdb/owm-ffp_nodes-osm_relation.htm>
→ Warum ist das so unterschiedlich? – Weil wir zu nah an Berlin sind … (Für Cottbus ist das weniger problematisch, s. [5] + [6].) → Welche APs haben wir denn nun in Potsdam? – Keine Ahnung, denn „Potsdam“ ist nirgendwo definiert (auch nicht für uns als Community) … → Was machen wir denn nun? – Wir benennen unsere APs so, dass sie anhand des Node-Namens (in der der Menge der 207 Nodes aus [3]) identifizierbar sind. :) → Wie benennen wir sie denn dann? – Ich kann nur einen Vorschlag machen. Wie wäre es mit: ffp-$straßenküzel-$hausnummer-$zusatz !? (Da würden dann bspw. "ffp-schopenhauer-29-sokai", "ffp-geschwi-82-waschbar-kneipe", "ffp-elflein-10-kuze-dach" … rauskommen.)
[5] <http://freifunk-potsdam.de/apdb/owm-ffc_nodes-osm_node.htm> [6] <http://freifunk-potsdam.de/apdb/owm-ffc_nodes-osm_relation.htm>
Nun, was denkt ihr … – Hat jmd. ne Meinung!? → Würde mich freuen! :) wir sind jetzt bereits nen halbes jahr dabei umzustellen und haben so etwa 3/4 des netzes fertig, die restlichen knoten sind eher so
klingt interessant, prinzipiell finde ich den ort im namen sinnvoller, als wer damit was zu tun hat. es gibt da von bernd ein paar knoten, die sind ziemlich weit verstreut ;) aber vielleicht will nicht jeder seine knkrete adresse preisgeben, sollten wir unbedingt auf der userml diskutieren. könnten wir für die freifunk-karte nicht das nodelist format auf der apdb exportieren, da sind aktuelle eh mehr knoten drin, als in der owm. in den listen bei [3] und [4] tauchen uach noch uralte knotennamen auf, bekommt man die da auch irgendwie wieder raus? problemkinder...
Danke und Grüße der Kai
PS: Sry für den Sermon – is denn doch länger geworden, als gedacht. Tippfehler können desh. auch gern behalten werden … ;)
Hellau, nochmal ich zu diesem (etwas von mir vergessenen) Thread … :) Am 24.03.2016 um 10:33 schrieb me@seth0r.net:
[…]
Am 23.03.2016 um 22:58 schrieb Kai Sommer:
[…]
### ESSID
[…]
IMHO besteht ein akt. Standard-Setup aus - 1 x Ad-Hoc mit der ESSID "Mesh23" und - 1 x Infrastructure mit vom AP-Namen abgeleiteter ESSID (bspw: 254-67-sokai)
nein, das essid schema für die Infrastructure netze ist eines der folgenden:
Freifunk-Potsdam-x-y z.B. Freifunk-Potsdam-254-16 bei bernd
Einrichtung@Freifunk-Potsdam z.B. Kuze@Freifunk-Potsdam für das roaming netz im kuze
*korrekt* – Mein Fehler … Damit ist dann auch der Punkt „PR über ESSID“ (aus meiner Ursprungs-E-Mail) hinfällig. (Außerdem gibts noch ne ESSID mit „service“ drin. Hatte ich letztens mal in Nähe des KuZe gesehen, dazu aber auch nix groß gefunden … *nuja,anderesthema*)
[…]
lediglich das Mesh netz hat keinen hinweis mehr auf den ffp, was so gewollt ist, da: 1. es Geräte gibt, die Ad-Hoc netze nicht sehen 2. es Geräte gibt, die Ad-Hoc netze sehen, sich aber nicht verbinden können 3. selbst Geräte, die Ad-Hoc unterstützen, damit nichts mehr anfangen können, da wir aus gründen 1 und 2 dort kein dhcp mehr betreiben
für die User sah es üblicherweise so aus, dass ffp nicht funktioniert und daher eher negative werbung war.
O.K. – kann ich nachvollziehen und ist echt doof, dass ‚uns‘ 1. + 2. zu der Entscheidung brachten.
b) Im Wiki konnte ich Anfang des Jahres was zum Thema Roaming (mit batman) finden/lesen. – Ich frage mich nun, ob es nicht sinnvoller/besser wäre/ist, wenn auf allen APs als Infrastructure-ESSID (bspw.) "potsdam.freifunk.de" verwendet wird und wenn dann iwann batman läuft, geht das Roaming ‚automatisch‘ …
[…]
das roaming via batman betreiben wir nur in der nähe größerer stadorte, z.B Kuze, Rechenzentrum, Pub es ist technisch zwar möglich, aber keine gute idee, ein roaming netz für ganz potsdam zu betreiben. wenn interesse besteht, führe ich da noch näher aus.
Ahso … – Habe zwar keinen Schimmer, wesh. das Roaming problematisch sein sollte (und wozu man dazu batman benötigt), aber ich denke, wir sollten das nochmal anderweitig ‚diskutieren‘ (danke fürs Angebot :)). Nur so viel (aus meinem Noob-Gehirn) nochmal, wie ich dachte, dass es funktioniert: Alle FFP-APs haben die ESSID "potsdam.freifunk.de" fürs DHCP-Client-Netz und wenn jmd. den AP wechselt (weil der Client sich bewegt), bekommt er ne neue IP. (Kann sicher zum Verlust von nen paar Paketen führen, wäre aber vllt. vertretbar, weil das Roaming funktioniert … Allerdings fällt mir dabei grad ein, dass es wahrsch. auch problematisch ist, wenn man sich genau zw. zwei APs befindet und der Client ständig zwischen diesen beiden hin und her hopst …)
c) Bzgl. der Ad-Hoc ESSID "Mesh23" hatte ich kurz nen Chat mit Marcel aus Cottbus, der meinte, dass hier ggf. "intern-ch5.potsdam.freifunk.net" (2,4GHz auf Kanal 5) und/oder "intern-ch??.potsdam.freifunk.net" nehmen könnte. (Das ist wohl so von Berlin abgeguckt …)
prizipiell ist die ssid im adhoc netz egal, das meshen funktioniert über die bssid, also könnte man das nennen, wie man will, aber wie oben erwähnt, sollte es was sein, womit kein user auf die idee kommt sich zu verbinden, um die userfrustration niedrig zu halten.
O.K. – weiß leider auch nicht, wesh. Marcel das ansprach bzw. es in Berlin so gemacht wird …
### Schema der Node-Namen
[…] (Hinweis: [3]–[6] bitte nach dem Aufruf nochmal neu laden; is mom. etwas buggy …) [3] <http://freifunk-potsdam.de/apdb/owm-ffp_nodes-osm_node.htm> [4] <http://freifunk-potsdam.de/apdb/owm-ffp_nodes-osm_relation.htm>
[…]
→ Was machen wir denn nun? – Wir benennen unsere APs so, dass sie anhand des Node-Namens (in der der Menge der 207 Nodes aus [3]) identifizierbar sind. :) → Wie benennen wir sie denn dann? – Ich kann nur einen Vorschlag machen. Wie wäre es mit: ffp-$straßenküzel-$hausnummer-$zusatz !? (Da würden dann bspw. "ffp-schopenhauer-29-sokai", "ffp-geschwi-82-waschbar-kneipe", "ffp-elflein-10-kuze-dach" … rauskommen.)
klingt interessant, prinzipiell finde ich den ort im namen sinnvoller, als wer damit was zu tun hat. es gibt da von bernd ein paar knoten, die sind ziemlich weit verstreut ;)
*zustimm* Carsten hatte allerdings auch schon angemerkt, dass wir – nach der Komplett-Umstellung des Netzes, also inkl. Node-Namen – über „254-“ am Anfang des Namens unsere APs identifizieren können …
aber vielleicht will nicht jeder seine knkrete adresse preisgeben, sollten wir unbedingt auf der userml diskutieren.
*zustimm* Würde dazu dann mal nachher den Thread abspalten …
könnten wir für die freifunk-karte nicht das nodelist format auf der apdb exportieren, da sind aktuelle eh mehr knoten drin, als in der owm.
Könnte man … Und dann bauen wir uns unsere eigen Karte mit apdb … Alles Überlegungen, die man machen könnte. – Ein Punkt bleibt aber: Wir nutzen die FW aus Berlin und da wird standardm. OWM angeboten/die OWM befüllt. Ergo sollten wir das nutzen und unsere Energie in andere Dinge stecken, als um die FW ‚drumherum‘ zu basteln … *uknow?*
in den listen bei [3] und [4] tauchen uach noch uralte knotennamen auf, bekommt man die da auch irgendwie wieder raus?
Jo, nach ner Woche off, sollten dir eig. raus sein … (Muss ich nochmal schauen bzw. muss man bei Abfragen halt iwie filtern … *gradnichimkopf*)
[…]
wir sind jetzt bereits nen halbes jahr dabei umzustellen und haben so etwa 3/4 des netzes fertig, die restlichen knoten sind eher so problemkinder...
+1000 dafür! :) Das also nochmal von mir … – Grüße der Kai -- Kai Sommer | http://sok.ai Schopenhauerstraße 29 | http://ka.i-sommer.de 14467 Potsdam | xmpp: me@sok.ai sig: CB0E 7DC5 5F32 456A 94A4 | pubkey: http://ma.ximi.se/mekey
Hellau, nochmal ich zu diesem (etwas von mir vergessenen) Thread … :)
Am 24.03.2016 um 10:33 schrieb me@seth0r.net:
[…]
b) Im Wiki konnte ich Anfang des Jahres was zum Thema Roaming (mit batman) finden/lesen. – Ich frage mich nun, ob es nicht sinnvoller/besser wäre/ist, wenn auf allen APs als Infrastructure-ESSID (bspw.) "potsdam.freifunk.de" verwendet wird und wenn dann iwann batman läuft, geht das Roaming ‚automatisch‘ …
[…] das roaming via batman betreiben wir nur in der nähe größerer stadorte, z.B Kuze, Rechenzentrum, Pub es ist technisch zwar möglich, aber keine gute idee, ein roaming netz für ganz potsdam zu betreiben. wenn interesse besteht, führe ich da noch näher aus. Ahso … – Habe zwar keinen Schimmer, wesh. das Roaming problematisch sein sollte (und wozu man dazu batman benötigt), aber ich denke, wir sollten das nochmal anderweitig ‚diskutieren‘ (danke fürs Angebot :)).
Nur so viel (aus meinem Noob-Gehirn) nochmal, wie ich dachte, dass es funktioniert: Alle FFP-APs haben die ESSID "potsdam.freifunk.de" fürs DHCP-Client-Netz und wenn jmd. den AP wechselt (weil der Client sich bewegt), bekommt er ne neue IP. (Kann sicher zum Verlust von nen paar Paketen führen, wäre aber vllt. vertretbar, weil das Roaming funktioniert … Allerdings fällt mir dabei grad ein, dass es wahrsch. auch problematisch ist, wenn man sich genau zw. zwei APs befindet und der Client ständig zwischen diesen beiden hin und her hopst …) das problem ist, wenn sich unterschiedliche netze mit der selben essid überschneiden, wechselt der client zwar ins neue netz, aber behält seine alte ip. er kann dann in dem netz nichts mit der ip anfangen und merkt es nicht. eine neue ip holt er sich nur, wenn er die verbindung zum netz komplett verloren hat und sich neu verbindet, beim einfachen wechsel von einem router zum nächsten nicht. deshalb benutzen wir batman womit die am roaming beteiligten router ein gemeinsames layer 2 netz haben in dem es einen zentralen dhcp server gibt.
könnten wir für die freifunk-karte nicht das nodelist format auf der apdb exportieren, da sind aktuelle eh mehr knoten drin, als in der owm. Könnte man … Und dann bauen wir uns unsere eigen Karte mit apdb … Alles Überlegungen, die man machen könnte. – Ein Punkt bleibt aber: Wir nutzen die FW aus Berlin und da wird standardm. OWM angeboten/die OWM befüllt. Ergo sollten wir das nutzen und unsere Energie in andere Dinge stecken, als um die FW ‚drumherum‘ zu basteln … *uknow?* wenn ich das auf https://github.com/ffansbach/de-map/issues/26 richtig verstanden habe, müssten wir nur so ein community file ausliefern, das hätte dann höhere
Am 20.04.2016 um 12:02 schrieb Kai Sommer: priorität, weil aus der owm wird dann alles erst mal berlin zugeschlagen. die owm selber ist kein problem, weil da garkeine zuordnung zu einer stadt stattfindet.
in den listen bei [3] und [4] tauchen uach noch uralte knotennamen auf, bekommt man die da auch irgendwie wieder raus? Jo, nach ner Woche off, sollten dir eig. raus sein … (Muss ich nochmal schauen bzw. muss man bei Abfragen halt iwie filtern … *gradnichimkopf*)
bei http://freifunk-potsdam.de/apdb/owm-ffp_nodes-osm_node.htm gibt es weiter unten ap-4-192-pub – Update (2 months ago) Sven
Hi
in den listen bei [3] und [4] tauchen uach noch uralte knotennamen auf, bekommt man die da auch irgendwie wieder raus? Jo, nach ner Woche off, sollten dir eig. raus sein … (Muss ich nochmal schauen bzw. muss man bei Abfragen halt iwie filtern … *gradnichimkopf*) bei http://freifunk-potsdam.de/apdb/owm-ffp_nodes-osm_node.htm gibt es weiter unten ap-4-192-pub – Update (2 months ago)
An dem API-File müssen wir eh nochmal ran. Dan können wir noch sau viel raus holen. https://freifunk.net/api-generator/
Sven Carsten _______________________________________________ Users mailing list Users@lists.freifunk-potsdam.de https://lists.freifunk-potsdam.de/listinfo/users
participants (4)
-
Carsten N
-
Kai Sommer
-
me@seth0r.net
-
Sven