Berlin:Zukunft:Treffen02
Wie soll die Zukunft des Freifunk in Berlin gemeinsam gestalltet werden? Hierzu hat sich eine Berlin weite Initiative gebildet, um Entwicklungen, Hintergründe und Zukunftspläne betreffs des Berliner Freifunks zu diskutieren. Auf den Berlin Core Meetings wollen wir zweimonatlich, jeden 3. Mittwoch, 21:00 Uhr, in der C-Base einen Weg für den Freifunk in die Zukunft finden.
Weitere Hinweise zur Agenda, den genauen Terminen und dem Veranstaltungsort, siehe Berliner_Zukunft.
Core Meeting 02
Diskussions-Protokoll des Berliner Zukunft:Treffen02.
Organisatiorisches
- Ort: C-Base - Seminarraum (Im Rahmen Freifunk für Fortgeschrittene)
- Datum: 17.12.2008
- Uhrzeit: 21:00
Verfolge Geschehen aus der Ferne
- Mario Behling,
A: Wir sollten Freifunk verstaerkt als globale Idee sehen und das nutzen und Kompatibilitaet herstellen soweit wie moeglich - also als Beispiel meine Freifunkverbidung soll sofort in Leipzig funktionieren, wenn ich aus Berlin komme. Weiterhin heisst das Addressbereiche mit Initiativen weltweit absprechen. Dazu brauchen wir auch ein englisches Wiki. Verschiedene Wikis kann man mit der Installation eines Sourcecodes hinkriegen. Habe ich grad bei einem anderen Projekt gemacht. Mal schauen, wann ich dazu komme :-)
B: KILLERAPPLIKATION: Wir brauchen nicht eine sondern mehrere Killerapplications und eine einfache Art ins Freifunknetz zu kommen:
1. Wir haben bereits die erste Killerapplication: Das neue OpenWRT mit Luci
2. Wir brauchen meiner Meinung nach autoconfing - echtes autoconfig (nicht wie open-mesh.com)
3. Wir brauchen Firmen, die Router mit Label - Freifunk-kompatibel verkaufen und so wie jede Distribution automatische Updates liefern - kann man jedoch nach Belieben aendern, also Repository wechseln. Preis der Geraete bestimmt der Markt. Eine Freifunk-Organisation sollte das Label Freifunk vergeben duerfen nach fest gelegten Kriterien.
4. Wir brauchen ne Netzinterne Suchmaschine - Yacy: Wer kuemmert sich um die Config-Datei und haelt die IP-Adressbereiche auf dem Laufenden? Alles andere ist da.
5. P2P-Suchmaschine: Erster Schritt - Wer passt Emule als Client fuer netzinternes Sharing an?
6. Wir brauchen einen Freifunk-Button auf dem Desktop (wie OLSR-Switch). LXDE kann hier ein guter Partner sein.
Themen
Wieder aufzugreifende Themen
DHCP - Splash im Freifunk
Wie könnte soewas realisert werden? Einfache möglichkeiten
Arbeiten mit dem Wiki für die Communitys
Für Freifunkkommunitys wäre es gut, bestimmte module hier im Wiki bereit zu stellen. Es wäre zu klären, in wie weit es möglich ist, solche Module "herzustellen", einzubinden und zu nutzen.
In der vorstellung der BNO'er könnte man sich ein Communtiy-Plugin vorstellen, dass ähnlich wie auf wikipedia.org auf der rechten seite eine Art Steckbrief zur Community erzeugt (Verwendete Einstellungen, ESSID, Kanäle, IP-Vergabe-Stellen ect... ähnlich einer Quartettkarte) Für das Ende der Seite oder für den Kopf einer seite wäre es schön, ein "Community-Navi-Console" zu haben. Das könnte das Einbinden der Wiki-Seiten und das Rückverlinken aus Wikiseiten in Communitys vereinfachen --Keksdosenmann21:27, 20. Nov 2008 (CET)
Erste Erfolge seit dem Letzten Treffen
der Freifunk-Spint und die Router
Wir haben nun ein Ort für unsere alten Router, gesammelt über Cven
Die Neue Map
Integration in der Map in der Freifunk - Firmware -> Aber im Moment werden die Koordinaten nur via Freifunk-Intern verteilt, die Freifunk-Map ist nicht per Default installiert, und somit tauchen nicht alle Knoten in der Freifunk-Google-Map auf (Auf der sich auch die anderen Communities in Deutschland.
wiki.freifunk.net
kleines "Know-How" für den Umgang mit dem Wiki und dessen "Kategorien", um Struckturierung der Inhalte zu verbessern
berlin.freifunk.net
Mailingliste
Verhalten dort / was empfehlt man Neulingen?
Neuerungen im (e)BGP für Freifunk
VPN
Zukünftige Treffen
Ab sofort alle 2 Monate am 3. Mittwoch des jeweiligen Monats. Das nächste Treffen findet also im Feb. 2009 statt. Alternierend findet an den anderen "3. Mittwoch" weiterhinn die Freifunk für Fortgeschrittene - Vorträge statt.
Es wurde zur besseren Planung eine Roadmap angelegt.
IRC LOG des Abends
Es wurde ein kleiner Log von der Gesprächsrunde erstellt. Hier ist er:
phaidros> re <phaidros> was gehtn hier? <Keks_BNO> moin <Keks_BNO> hier geht es gleich los <phaidros> tach der keks :) <Keks_BNO> ein paar punkte von dem meeting <Keks_BNO> tachtach <phaidros> jaja, welches meeting? <Keks_BNO> freifunk berlin <phaidros> o.O <Keks_BNO> ;) <phaidros> ah, gut. <Keks_BNO> joa <phaidros> topic ? <Keks_BNO> das geht gleich los <Keks_BNO> wir müssen nur mal den anstoß machen <phaidros> keks, da ich ja nicht in der base bin, du reportest nach hier? <Keks_BNO> will ich <Keks_BNO> ja <phaidros> kewl <Keks_BNO> aber immo bist du der einzigste ;) <phaidros> ack. base voll? <Keks_BNO> naja <Keks_BNO> geht so <phaidros> irc aufm beamer? <Keks_BNO> noch nicht <phaidros> muss auch nich :) <Keks_BNO> http://wiki.freifunk.net/Berlin:Zukunft:Treffen02 <Keks_BNO> mh <Keks_BNO> scheinbar wenig interesse -->| thinkstrohi (-andre@pD952A237.dip0.t-ipconnect.de) hat #berliner_zukunft betreten <Keks_BNO> ahja ;) <thinkstrohi> lifeschnipsel? cool, würd ich morgen lesen, muss noch etwas fürs vorabi anschaun <Keks_BNO> so, nun geht es wirklich los <phaidros> <phaidros> vorabi .. ^^ <phaidros> das lange her .. <thinkstrohi> na eigentlich mach ichmir kein stressdrum, aber hab seit über ner woche sau die zahnschmerzen udn der arzt kann aus dem sympomefoo nix deuten :/ <phaidros> Keks_BNO: v.a. interessiert mich vpn/eBGP <phaidros> worum gehts gerade? <Keks_BNO> geht gleich los <Keks_BNO> jetzt! <phaidros> hi crowd, hi harv ;) <Keks_BNO> svenola: zwei router für die einsteiger sind bereits da, kostet 30 euro <Keks_BNO> pfand <Keks_BNO> es sind jetzt zwei schlüssel für den spind vorhanden <Keks_BNO> diese hat Sven <Keks_BNO> 5 Foneras und ein paar abg-karten hat sven bekommen <Keks_BNO> verteilt werden sollen diese an die aktiven freifunker <Keks_BNO> um diese in die richtigen wege zu leiten <Keks_BNO> es sollen die standartpasswörter und logins verwendet werden <Keks_BNO> admin admin usw <Keks_BNO> zum thema IP's <phaidros> evtl. lieber sshkeys anstatt admin:admin ? <phaidros> ein credential zum *merken* ist wesentlich unsicherer als ein credential zu *haben* <Keks_BNO> was ist eigendlich notwendig ? (für ip-kram) <Keks_BNO> na root:admin <Keks_BNO> wie gehen wir mit den problem ip-vergabe umgehen <Keks_BNO> wir haben technische probleme <Keks_BNO> 2000 ip-adresse, 600 router die eine neue ip brauchen <Keks_BNO> jetzt ist die frage: wie kommen wir von den 104'er ip-adressen weg und kommen zu unsern neuen öffendlichen ip-adressen? <phaidros> ooops, auf *die* antwort bin ich gespannt :) <Keks_BNO> wir wollen unsere öffendlichen ipadressen für die clients benutzen, also die endgeräte, nicht für unsere infrastrucktr ... also den router an sich <Keks_BNO> Elektra: wie gehen wir jedoch mit der vielzahl an rechnern hinter den routern um, denn das sind weitaus mehr als 2000 <Keks_BNO> ndb: wir sollen nicht zu verschwenderisch mit den ip-adressen umgehen <phaidros> router bekommt eine limitierte anzahl *moeglicher* oeff. ip adressen und nutzer *kann* diese ins intranet vergeben? <phaidros> evtl. mit nem heartbeat auf dem router, der checkt ob eine oeff. ip vergeben ist und diese dann announciert (oder eben auch nicht, wenn ungenutzt) <Keks_BNO> alx: 1) eine öffendliche ip, die raus genattet wird, 2) rfc 1918 : <phaidros> zb. 2 oder 3 oeff. ip adressen pro router mit lan dahinter vorsehen, infrastruktur router bekommen keine. <phaidros> switch im webif: infrarouter / lanrouter <phaidros> my 2cents <Keks_BNO> danielp: zwei möglichkeiten: dem enttor zum nutzer eine ip bereit stellen, oder eben den leuten öffendliche ips geben <phaidros> hm, das liest hier eh keiner :p <Keks_BNO> svenola: frage: wollen wir jeden router eine öffendliche ip geben? hat das sinn? <phaidros> nicht jedem .. siehe weiter oben. <Keks_BNO> danielp: wir sollten unsere IP-v6 - adressen für die interne infrastruktur nutzen, weil wir für unsere internen sachen keine ipv4-adeessen verbraten müssen <Keks_BNO> (ist auch als log gedacht) <Keks_BNO> kommt hinterher ins wiki <Keks_BNO> svenola: wie kommt der endnutzer an die ip-adressen? <Keks_BNO> ndb: :wie kann die ip-adresse schon gleich mit den dns verknöpfen -->| cven (~cven@shell.c-base.org) hat #berliner_zukunft betreten <Keks_BNO> daniel: wir werdem eine ip-adressenverwaltung brauchen, haben wir noch nicht <Keks_BNO> -> bgp <Keks_BNO> routingprotokoll wird im moment von einen uplink verwendet -->| nbd (~nbd@nbd.name) hat #berliner_zukunft betreten <Keks_BNO> im moment wollen wir unsere router bgp sprechen lassen <phaidros> alle?? <Keks_BNO> im letzten jahr haben wir versucht mit tinc diese probleme zu lösen <Keks_BNO> und in letzter zeit wurde ein wenig mit n2n rumporbiert <Keks_BNO> nur an bestimmten punkten, an den "dicken" <Keks_BNO> z.z. an einen <Keks_BNO> probleme bei n2n <Keks_BNO> : <Keks_BNO> hat noch nicht alle features, die wir wollen / brauchen <Keks_BNO> konfigurationsprobleme <Keks_BNO> bleibt irgendwann stehen <Keks_BNO> hört auf zu funktioneren <Keks_BNO> alx: ist von prinzip toll, problem: es gibt immo 1 supernode, nicht viele <Keks_BNO> wir wollen kein single point of falure <Keks_BNO> -> mit bgp können wir mehrere einspeisepunkte betreiben <Keks_BNO> die redundant laufen <Keks_BNO> grundsätzliches prinzip: ein paar supernodes, <Keks_BNO> immo skalliert bgp nicht, wird drann gearbeitet <Keks_BNO> frage: brauchen wir ein routerprotokoll oder ein tunnel <Keks_BNO> wir reden über tunnelprotokolle <Keks_BNO> gibt es eine liste von anforderungen? <Keks_BNO> -> alles sollen mit allen reden, und das möglichst einfach <Keks_BNO> immo machen wir das mit n2n <Keks_BNO> weitere probleme von n2n -> vorhanden, aber bedarf noch einiger anpassung und pflege <Keks_BNO> im moment suchen wir nach einer möglichkeit, unsere ips ins internet bereit zu stellen <Keks_BNO> es soll zwischen den endanwendern keine ipv4 angewendet werden <Keks_BNO> konzept: ipv6wokle mit ipv4 - traffic <Keks_BNO> wir haben einen funktionieren prototypen <Keks_BNO> es wird dazu einen workshop auf dem congress geben <Keks_BNO> -> grundprinzip: ipc4 in ipv6 packen und transportieren <Keks_BNO> diese pakete werden nicht getunnelt, sondern übersetzt <Keks_BNO> das ganze funktioniert stateles <Keks_BNO> s <Keks_BNO> svenola: gibt es voraussetzungen? probleme? <Keks_BNO> alx : mtu ->header von ipv6 sind länger <Keks_BNO> immo gibt es ein workaround <Keks_BNO> wir haben das selbe problem wie pppoe <Keks_BNO> vorschlag danielp <Keks_BNO> : <Keks_BNO> Disskusion beim nächsten mal, voher sollten wir uns über die dinge klar werden <Keks_BNO> svenola: eine möglichkeit / berliner lösung, die nicht exportiert werden kann <Keks_BNO> fragen: wie nutzen wir die tunnel und wie wollen wir den traffic wo aufkommen lassen? <Keks_BNO> Problem: provider filtern alles was kleiner als /21 bist <Keks_BNO> daher werden /24 -netzen gefiltert <Keks_BNO> wenn zwei wege in das selbe netz geroutet wird, müssen diese auch miteinander verbunden werden <Keks_BNO> das ist aber ein problem, da wir dies nicht garantieren können <Keks_BNO> lösung: mehrere punkte mit /21 werden verbunden <Keks_BNO> aber für unseren fall nicht einfach zu realisieren <Keks_BNO> -> bei uns mit n2n - vermeshung von uplinks <Keks_BNO> was bekommen wir? was geben wir? <Keks_BNO> wir suchen leute, die für uns den traffic abnehmen und den zu uns leiten <Keks_BNO> es ist einfacher traffic zu bekommen, da der provider nicht mehr für den traffic verandwortlich ist, sondern der freifunk <Keks_BNO> svenola: wie soll die verwaltung laufen? <Keks_BNO> cven: will stefen davids einladen, im januar <Keks_BNO> ist dem freifunk-routingproblem sehr aufgeschlossen <Keks_BNO> er könnte uns in unseren ANliegen weiterhelfen <Keks_BNO> -> hat connections <Keks_BNO> alx: kontakt zu weiteren provider eingeleitet <Keks_BNO> versucht weitere personen für bgp - routern und mehrere router zu finden <Keks_BNO> sucht auch noch neue leute, die sich dort beteiligen können und wollen <Keks_BNO> wie connecten wir uns zu unsere wolke? wie können wir die zugangshürde gestallten <Keks_BNO> immo via wiki <cven> - <phaidros> ? <phaidros> pause? vorbei? <cven> :-) <cven> nein <phaidros> hehe <Keks_BNO> im moment fragen zum thema gateways <Keks_BNO> bgp <cven> bgp freifunk weltherschaft <Keks_BNO> es dar nicht sein, dass das gesammte netz an denen paar leuten hängt, die bgp fahren <Keks_BNO> dazu muss es auch weiterhinn eine rückfallebene geben <phaidros> ack <Keks_BNO> svenola: wir sollten die leuten aus wien einmal auf die füße treten und uns über deren lernprozess informieren <Keks_BNO> eventuell könnten wir auch einmal auf athen schauen <Keks_BNO> diese haben eine interne bgp <phaidros> das groessere problem ist das vorhalten einer globalen routenliste, das kann nicht skalieren <Keks_BNO> dort gibt es "kingdom" -treffen <phaidros> das naechste problem ist, wie man ipv6 segmentiert, damit das gateway announcieren noch hinhaut <Keks_BNO> um dort probleme mit dem internen routen zu klären <Keks_BNO> das problem ist auch das einstiegslevel für bgp ... <Keks_BNO> daher braucht man erst einmal einen plan der ganzen sache <Keks_BNO> wir haben das ic-vpn <Keks_BNO> mittlerweile schon seit 3 jahren <Keks_BNO> zum lernen <Keks_BNO> das 104 wird immo verteilt <phaidros> verteilt an wen? <Keks_BNO> via regulationsstelle <Keks_BNO> n <phaidros> mal jemand nen antrag geschrieben fuer 104/8 ? <phaidros> *g* <Keks_BNO> wenn wir jetzte was "anfassen" sollten wir etwas wählen, dass wir nicht wieder in 4 jahren neu machen müssen <cven> naja, das sagen wir immer, und wir sollten von vornherein nichts ausschliessen <cven> +neues -->| tetzlav (~tetzlav@leipzig.freifunk.net) hat #berliner_zukunft betreten <cven> moin <tetzlav> tach <phaidros> welcome on cbase beamer :) <Keks_BNO> probleme: luci. ip-vergabe, leute dazu zu bringen, ip'S zu regestrieren <Keks_BNO> wie bekommen wir die leute dazu, öffendliche ip's zu nutzen <Keks_BNO> möglichkeit: 104'er ips am router auf ne nervseite umleiten <Keks_BNO> aber offende aufgaben: <Keks_BNO> wer schreibt was? <Keks_BNO> Roadmap <cven> http://wiki.freifunk.net/Wireless_Community_Weekend_2009 <cven> diesen termin als ersten milestone nehmen <Keks_BNO> Problem: Migrationen im kern <cven> * 22.-24.05.2009 at c-base berlin <cven> [bearbeiten] <Keks_BNO> http://wiki.freifunk.net/Roadmap <Keks_BNO> vorschlag: ipv6 ausprobieren <Keks_BNO> rest wird auf das wireless communtiy weekend vertagt <Keks_BNO> problem: hardware-doku <Keks_BNO> im wiki ist es zu einfach, an daten zu kommen. Es ist zu einfach, an diese informationen zu kommen <Keks_BNO> vorschlag: export ins interne netz / wiki im freifunk <Keks_BNO> next topic: map
