B.A.T.M.A.N.-Release-Party at the c-base in Berlin

Posted on by Mario Behling

(via Marek Lindner) Time: Wednesday 20th June
2007 / Place: c-base berlin

The B.A.T.M.A.N.-developer team would
be happy to celebrate with YOU the 0.2 release of B.A.T.M.A.N. at
the C-Base (in Berlin). FYI, there will also be a free barrel of cool
beer waiting to be flushed. Version 0.2 can reasonably be called
stable now. It works quite performant, supports multiple interfaces,
has a low CPU-load, a robustly working algorithm underneath, and
autonomously negotiates UDP-Tunnels to GWs  which ultimately
enables long-term and stable internet connections. A number of users
reported quite excitedly about the amazing experiences they made with
this protocol. Well, we want to stay neutral so join in to hear them
and try batman for yourself.

Currently B.A.T.M.A.N is
available for Linux only. The ports for Mac OS-X and BSD have fallen
asleep and are waiting for a diligent bee … Maybe there will once
also exist a windows port.

Many thanks to all the people who
helped to realize this in such a short amount of time.

Merchandizing
^^^^^^^^^^^^^^^^^^^
We
are thinking about printing further T-shirts with the
B.A.T.M.A.N.-Logo (as you can see on http://open-mesh.net/batman
) and sell them at the cost of expenses. Unfortunately the price is
not clear by now but will be about or less than 15 Euro. If you are
interested please send a mail with your size and the limit you are
willing to pay.

Considerations for the parallel operation of
OLSR and
B.A.T.M.A.N.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In
Berlin we are now facing a phase in which both routing protocols will
be used in parallel. Currently we are aware of one issue where this
can cause problems. This is in case of OLSR-Internet traffic passing
a dual-stack (OLSR and B.A.T.M.A.N.) node where the B.A.T.M.A.N
daemon is configured for tunneled GW selection. Then each
OLSR-towards-internet packet will be magically caught and warped to
the currently selected (and maybe several hops away) B.A.T.M.A.N. GW.
where the packets pop-up again and follow their usual path through
the internet to their final destination. This has caused confusion
since also programs like traceroute do not show the intermediate hops
which the packet has passed (tunnelled)  between the related
B.A.T.M.A.N. node and the GW.

This is because such a
dual-stack mesh node (where the B.A.T.M.A.N daemon is configured for
tunneled GW selection) consequently has two default routes. One due
to OLSR and another due to B.A.T.M.A.N.. The thing is, that both are
ending up in the same routing table and one of them (the latter) has
a higher priority than the other. So every packet passing along with
a destination address matching only the default entry of the routing
table will end up in the tunnel to the currently selected
B.A.T.M.A.N. GW.

The Internet-GW selection mode of
B.A.T.M.A.N. is optional and should be disabled or used with care
especially on nodes with a dedicated RF-postion (and such used by
many others as an intermediate hop) like churches and other high
buildings. Enduser using Notebooks or PDAs should be able to use this
feature without causing trouble.

Outlook
^^^^^^
In
order to make the parallel deployment of both protocols even more
smoothly, a number of new features have found their way into 0.3.
Then it will also be possible to maintain and use a the OLSR and the
B.A.T.M.A.N. default route in parallel.

Therefore we will also
release the first version of the upcoming B.A.T.M.A.N. generation
(0.3 alpha).

At the same time we already began working on the
next generation of B.A.T.M.A.N. which will be called B.A.T.M.A.N.
Advanced. It works on Layer 2 and creates a virtual network switch of
all nodes participating. It offers a bunch of new possibilities and
features which wait for you to be explored. To offer you a stable
plattform you can experiment with we will release 0.1 alpha. We will
also provide a set of tools (the B.A.T.M.A.N. toolchain – battool)
to bring you in the position to observe the magic and to debug your
setup or our daemon.  😉

B.A.T.M.A.N.-Release-Party in der c-base in Berlin

Posted on by Mario Behling

(via Marek Lindner) Zeit: Mittwoch 20.Juni 2007 / Ort:
c-base berlin

Das B.A.T.M.A.N.-Entwicklerteam freut
sich Euch mitteilen zu können, dass am Abend des 20. Juni die
Veröffentlichung der Programmversion 0.2. mit einem gut
gekühlten Fass FreiBier in der C-Base Berlin gefeiert wird. Die
Programmversion 0.2 kann dann zu Recht als 'Stable' bezeichnet
werden. Sie arbeitet performant, unterstützt mehrere Interfaces,
handelt bei Bedarf selbständig UDP-Tunnels zu Internetgateways
aus, hat eine geringe CPU-Last und einen solide arbeitenden
Algorithmus.  So mancher Anwender berichtet über seine
Erfahrungen mit dem Protokoll mit leuchtenden Augen da
Internetverbindungen wegen der Tunnelfunktion auf einmal stabil
laufen und nicht mehr abbrechen. Würden wir sie jetzt zitieren
klänge das zu sehr nach Werbung, also probiert es selbst. 
😉

Im Moment gibt es B.A.T.M.A.N. nur für Linux, die
Ports für Mac OS-X und BSD sind eingeschlafen und warten auf
fleißige Bienchen die sich darum kümmern. Wir gehen davon
aus, dass sich dafür Leute finden werden, wenn B.A.T.M.A.N.
stärker verbreitet ist. Vielleicht gibt es dann auch einen
Windows-Port.

Vielen Dank an alle, die das in so kurzer Zeit
ermöglicht haben!!!

Merchandising
^^^^^^^^^^
Wir
denken zur Zeit darüber nach, nochmal T-Shirts mit dem
B.A.T.M.A.N.-Logo gegen einen Unkostenbeitrag zu machen.
Vorbestellungen nehmen wir per Mail mit Größenangabe
entgegen. Bitte teilt Uns mit, welche Preisobergrenze Ihr bereit seid
dafür zu bezahlen. Der Preis steht momentan noch nicht fest und
hängt davon ab, wo wir die Shirts drucken lassen. Er sollte aber
um die 15 Euro oder darunter liegen.

Überlegungen zum
Parallel-Betrieb von OLSR und
B.A.T.M.A.N.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Es
steht nun eine Phase bevor, in der beide Routingprotokolle
übergangsweise parallel eingesetzt werden. Das kann zu 
Problemen führen. Sobald der Internet-Traffic von OLSR bei einem
Router mit einem ins Internet tunnelnden B.A.T.M.A.N.-Daemon ankommt,
verschwindet der OLSR-Traffic Richtung Internet auf 'magische' Weise
und findet sich plötzlich im Internet über einen
(möglicherweise einige Hops entfernten) B.A.T.M.A.N.-Gateway
wieder, ohne dass weitere OLSR-Knoten bei einem Traceroute angezeigt
werden.

Ein Router im Parallel-Betrieb hat dann zwei
Defaultrouten ins Internet weil zwei Protokolle nach
Internetanbindung suchen – eine Default-Route von OLSR und eine von
B.A.T.M.A.N., wobei letztere stehts Priorität hat (bedingt durch
die kleinere Metric). Das wird den unangenehmen Effekt haben, dass
jeglicher Internettraffic statt zu einem benachbarten OLSR-Gateway zu
einem B.A.T.M.A.N.-Gateway geroutet wird – nun werden die
OLSR-Gateways nicht mehr benutzt, sobald ein tunnelnder B.A.T.M.A.N.
auf der Route zum OLSR-Gateway liegt.

Der Internet-Such-Modus
von B.A.T.M.A.N. ist optional und sollte daher vorerst nicht auf
Transit-Routen aktiviert werden. Endpunkte, wie z.B. Notebooks, PDAs,
können diese Funktionalität problemlos benutzen.

Blick
nach vorn
^^^^^^^^^^^
Um den Parallel-Bertrieb noch
reibungsloser zu gestalten, fließen bereits etliche
Kompatibilitätsfunktionen in B.A.T.M.A.N. 0.3 ein. Dann wird es
auch möglich sein, eine OLSR und eine B.A.T.M.A.N. default route
nebenher zu betreiben.

Deswegen wollen wir die Gelegenheit
auch gleich nutzen um den ersten Release der gerade entstehenden 0.3
alpha Version zu feiern.

Gleichzeitig haben wir begonnen an
der übernächsten Generation zu arbeiten mit dem alles
sagenden Namen B.A.T.M.A.N.-Advanced. Er arbeitet auf Layer 2 und
kreiert einen virtuellen Network-Switch zwischen allen am Mesh
teilnehmenden Nodes. Layer 2 emöglicht gleich eine ganze Reihe
von neuen Möglichkeiten die darauf warten ausprobiert zu werden.
Damit es eine stabile Plattform zum experimentieren gibt wollen wir
am 20. 6. auch noch 0.1 alpha von B.A.T.M.A.N.-Advanced releasen. Und
zwar zusammen mit einer ganzen Reihe von Tools die es überhaupt
erst ermöglichen den Zauber auf Netzwerk-Ebene 2
nachzuvollziehen und zu debuggen.

The Fonera Pack Story

Posted on by sven-ola

This blog entry is mainly in english. Sorry for that, but the original recipient (a belgian guy) is very much better in english. Since beginning of 2007, a startup company called "FON" is distributing very cheap (subventioned) WLAN devices: the la-Fonera wireless LAN router. For these, I've created and published an additional software, called the Freifunk-Fonera-Pack available here: http://download.olsrexperiment.de/fonera/ . The Pack offers Freifunk meshing in parallel to the FON function. Obviously, I've missed to explain the different networking modes and hance a posting on our internal berlin mailing list reaches me with a lot of questions. Mario asked me to publish the anwers here.
Hi Steven,
yes I know. There's not enough info about the networking / mode stuff in the ff-fonera-pack readme. OK – I'll try.
Networking Model
The networking model / how internet is distributed in a Freifunk mesh is very different to the FON business model. The FON model includes a certain amount of hotspots scattered over an arbitrary area. Each FON router should have its own (wired) internet access via DSL, leased line or dialup modem. The idea is – as you hopefully know – to share/sell the unused bandwidth of the payed personal internet access to others. Freifunk is different. We form a wireless intranet, where internet access is a service offered by volunteers. We normally do not pay for internet connectivity. In short: Freifunk forms a network and FON is a hotspot service offer.
To "catch" paying users, a FON hotspot offers it's connectivity in a mode easily understand by typical end-user laptops/notebooks/PCs: the access point wifi mode. A connecting PC should have connectivity and zero-admin config, so it is hopefully really easy to display the"insert-coin-here" page. Freifunk again is different here. To participate as equal with equals in a network, we need to cooperate at least on the techical level. This includes using a specific wifi mode (ad-hoc or IBSS) as well as relaying data of other users and running a certain protocol program to find and configure optimized data paths through the network.
To combine these different networking models, the Freifunk-Fonera-Pack offers different operation "modes". These modes are designed following these simple rules:

  1. The FON and Freifunk stuff should function as designed in parallel
  2. It should not be possible to sell the internet connectivity offered by Freifunk volunteers via FON
  3. It should not be possible to nerve wreck Freifunk users with the FON login page
  4. There should be a benefit for the average FON user to install that stuff

You can use the "Open" mode, if you want to share your own internet uplink with the community. Every Freifunk user connecting via Ad-Hoc and running the OLSR routing program can use your internet gateway. It's announced per "HNA" which basically says "Internet here". The OLSR program will search and configure a data path ("route") to the nearest HNA internet gateway available. Without the FON login page of course.
You can use the "Ego" mode, if you do not want the FON stuff / FON login page at all. To keep fair play, the FON callback is stopped and there is no "FON_AP" signal then. If you want to offer internet to the community, simply configure internet as usual. If you want to use a Freifunk gateway, simply do not connect any internet uplink.
If you want to relay data via WLAN/radio from other Freifunk users, but you want your own internet uplink for yourself (and the FON users loggin in), you can use the "Stealth" mode. All the Freifunk mesh routing happens in a background routing table. You do not announce your internet gateway via HNA and an Ad-Hoc connected Freifunk node / PC / laptop uses a different default route (not your standard internet default route).
As a benefit for the FON offering user, you can tunnel your own internet gatway via Freifunk and offer a FON uplink elsewhere in the Freifunk mesh. For this, the different Master-Modes (Open-Master, Ego-Master, Ego-Slave) are offered. You can configure a second / third / forth Fonera as "Slave" and set up a tunnel via Freifunk-meshing to use and sell your own internet gateway via FON. You'll find a sample configuration on the "Freifunk-Advanced" web page installed as part of the Freifunk-Fonera-Pack. Besides that, the Freifunk-Fonera-Pack adds a bit more security currently, provided that you do not use 192.168.x.x as meshing IP – but that's another story.
Q: Why there are no "Open-Slave", "Ego-Slave" nor "Stealth-Slave" modes?
A: Well, if you re-think it and maybe read the above once more you will understand. "Open-Slave" is contraprodutive. A device should not announce internet which it does not have. "Ego-Slave" is not necessary. Simply use "Ego". "Ego" will configure/use the next HNA / Freifunk gateway, possibly your Fonera in "Open" mode. "Stealth-Slave": This is offered as "Slave" mode.
HTH
// Sven-Ola
At the next day, a posting with more questions dropped in. I don't want to cite that here, mainly because I have not asked Steven to do so. To summarize: He has not tried the tunnel stuff and wanted to have an easy configuration for a couple of other guys, e.g. "publish the FON password" and "we are all in Linus mode". I may be wrong, but those points are the main questions asked IMO.
Steven,
uuh! Lots of questions 🙁 OK – to sort that out, here are some more statements.
Tunneling Internet
Our understanding of a mesh network includes using those cheap devices, to form a network. You can – of course – use the precious laptops to join in. But in the long run, a mesh only functions, if the nodes (the laptops, PCs, the routing boxes running OLSR) are switched on for a longer period. I talk about months not minutes. Also, you normally do not want to place the laptop on the roof of your house. For example: we do not have OLSR for Vista currently – and only a very small number of whiners. We all use those boxes to connect (e.g. via DHCP and NAT). You plug in your laptop into the box (either by ethernet or by a second Access Point) and go. That's the main use case.
You wote, that you (and your friends) don't want to break your "FON promise". The ff-fonera-pack is open source, and because of that you are free to do anything you like. Some expertize required. Especially the "Chillispot needs to fiddle with the default route thing" will be the hurdle to master here. Also I expect some dirty policy routing tricks are required. I personally do not want to make that, because of the reasons I wrote in my last post.
Lets form an example. You have internet access via DSL. You have a fonera connected to the DSL line, configured all, and switched to "Open". You have two friends who also bought a Fonera. One has his own DSL line and one not. Your own fonera uses 172.16.0.254/12 as meshing IP, channel 3 and 02:ca:ff:ee:ba:be as meshing BSSID.
Friend1 with DSL line: That's easy. Just proceed as usual. He can use "Open" or "Stealth" modes, which depends on "does he want to share for free" or not. He switches to channel 3, configures an arbitrary ESSID (say IZEFON, but I would prefer a more sexy name) for meshing and the FON_Friend1 and MyPlace_Friend1 as usual. He configures 172.16.0.1/12 as meshing IP. The critical thing is the BSSID (the hex number). The meshing ESSID is not really used – the BSSID for meshing and the channel needs to be the same on all meshing Foneras. Ah – and you need a Wiki page stating: "Friend1 uses 172.16.0.1/12" as well as "Steven uses 172.16.0.254/12".
Friend2 without DSL line: To keep the "Fon promise", he normally needs to buy a DSL line. The FON promise is based on that. But: that friend can use for example the Steven-DSL via the tunnel setup. Setting up tunnels is easy, and the standad Fonera should be able to run ~ 8 tunnels concurrently (depends on memory consumption). The tunnel stuff should also be able to handle ~500kbyte/sec, which in most cases matches your DSL line speed. You will be happy if you reach that speed via meshing with some kilometres distance which also requires a very good antenna setup.
The first thing to do is adding "Friend2 uses 172.16.0.2/12" to the wiki page. Friend2 configures BSSID, MeshingIP and Channel3. Friend2 also switches to "Slave" which basically means: The device has internet via tunnel and does not interfere with the OLSR-HNA-search-best-gateway algorithm. He also changes the private MyPlace_Friend2 IP range from the default 192.168.10.1/24 to 192.168.11.1/24 (more on this later).
Now Steven switches to Open-Master to let Friend2 in. It needs to be a good friend, since he sells your DSL line to FON and he has access to your private IP range (the 192.168.10.1/24 used for your own MyPlace_Steven domain). To let his friend in, Steven needs to browse to the Advanced/Freifunk-Advanced page of his Fonera and enter this in the "Private IP" input field: "192.168.10.2:192.168.11.2/24". Steven also enters a tunnel password there, any arbitrary string will do.
Friend2 now also browse to the Freifunk-Advanced page, and enter the same tunnel password as well as this to the "Private IP" input: "192.168.11.2:192.168.10.2/24". You may note that those settings are symmetrical. Friend2 needs to define, which Master tunnel endpoint to use. So he enters this to the "Master IP" input: "172.16.0.254:4711". Which basically says: On Stevens fonera, there is an open tunnel endpoint on port 4711.
After restarting both Foneras, you should notice the "FON_xxx" on the Fonera of Friend2. This proves: Setup is working. Ah – you may enter the Foners command line or connect to MyPlace_Friend2. Then send "ping 192.168.10.1". This proves, that both private IP ranges (the 192.168.10.1/24 and 192.168.11.1/24) are linked by routing and theres no firewalling in between.
Phew. Much blabla. I hope this will help you a bit.
// Sven-Ola
To write down some final words: It is obvious, that setting up a Freifunk network is not too easy. To teach and inform, it needs much more text than (for example) attracting FON users with a Plug-and-Play promise. I'm sure, that we never reach that Plug-and-Play state, but of course things can be made more easy with good documentation and good Web-UI-Design. I hope that Steven finds his way through the competing network models. It should be clear that a company needs to make a profit, while Freifunk is created by volunteers. But we also want something from others of course – e.g. World domination (cited from Linus). TANSTAAFL!

Chatten via Messengern funktioniert schlecht. Welche Ports sind offen? Webcam einsetzbar?

Posted on by

Die richtige Kategorie für mein Posting ist mir nicht klar. Keine scheint zu passen.

ich bin neu in berlin und kann zum olsr.freifunk.net mac 02.CA.FF.EE.BA.BE am görlitzer park, kreuzberg, connecten. ich benutze dabei den olsr.org switch 0.4.9, den ich so konfiguriert habe, wie im wiki beschrieben.
das wiki habe ich so verstanden, dass ich in berlin meinem usb-wlan-stick eine feste ip geben muss.
die allgemeinen beschreibungen von freifunknet verstehe ich allerdings gerade andersrum: man darf sich selbst keine feste ip geben.

mit der benutzung von instant messengern hapert's. trillian 3.1, der die üblichen messengerprotokolle beherrscht (aim, icq, msn, yahoo, jaber), geht fürs chatten relativ gut, allerdings reißen die icq- und die msn-verbindung häufiger ab und nur die yahoo-verbindung ist ziemlich stabil. windows live messenger 8.1, nachfolger von msn, und yahoo messenger 8.1 können sich selten anmelden bzw. verlieren oft die verbindung.
da mir mit trillian video- und sprachverbindungen bisher nicht gelangen, dagegen via windows live/msn beides in ansätzen klappte, müssten vielleicht besondere ports für mich offen sein bzw. müsste ich ports einstellen – so man das kann -, die im freifunk.net offen sind.

ich stelle mir vor, dass mein surfen über olsr.freifunk.net so ist, wie über einen router. beim router kann ich port-forwarding einstellen, im freifunk.net aber nicht.

olsr.org switch, reiter 'output', zeigt folgendes an, was ich nicht interpretieren kann:

Parsing file: "C:\DOKUME~1\x\LOKALE~1\Temp\GNUBF.tmp"
Httpinfo olsrd plugin 0.1 by Andreas Tønnesen

51x

DeleteIpForwardEntry() = 00000057, Falscher Parameter.
DeleteIpForwardEntry() = 00000057,Falscher Parameter.

ERROR – sendto(v4): Ein nicht blockierender Socketvorgang konnte nicht sofort ausgeführt werden.

DeleteIpForwardEntry() = 00000057, Falscher Parameter.
DeleteIpForwardEntry() = 00000057, Falscher Parameter.

 

wer kann mir tipps geben oder wohin kann ich mich wenden? für die mailingliste habe ich mich vor ein paar tagen eingetragen, aber habe bisher nichts erhalten, weiß auch nicht, wie ich selbst was 'posten' könnte.
vielleicht gibts hier im blog antworten oder eine pn an mich.

servus

was war

Posted on by alx

Was war:

Am Mi, den 28. 2. 2007, gab es ein Gespräch zwischen einigen Forschern von FOKUS (http://www.fokus.fraunhofer.de) und einem Haufen Freifunkern in der c-base. Dazu kamen auch noch einige Freifunker aus Weimar und Leipzig, da das Thema meiner Meinung nach überregional relevant ist. Ich hatte im Vorfeld einige Berliner explizit eingeladen, des weiternen nochmal an dem Mittwoch auf der Base den üblichen Verdächtigen bescheidgesagt.
Das Thema war und ist Freifunk und die Forschung:
Es gibt grosse Meshnetzwerke auf der einen Seite, betrieben von einem Mix aus Aktivisten, Bastlern, Firmwarehackern, Programmierern, Dachkletterern u.v.a. Sie haben Netze aufgebaut, wie sie die Welt noch nicht gesehn hat, sowohl auf technischer Ebene als auch auf sozialer Ebene, dem berühmten Layer 8.
In den Universitäten und Instituten sitzen jede Menge Forscher, welche sich mit dem Thema Netzwerk und Mesh schon lange theoretisch und in Testbeds beschäftigen, einen guten Überblick über den State-of-the-Art haben und sich täglich damit beschäftigen, Probleme und Fragestellungen zu bearbeiten, die extrem abgefahren sind.
Im Bereich Meshnetworking verlassen sich viele Forscher nur auf kleine Testbeds und Netzwerksimulationen. Die Ergebnisse sind in der Realität leider nur sehr bedingt anwendbar.
Deshalb haben wir uns zusammengesetzt und darüber gesprochen, welches Potential eine Zusammenarbyte von Forshern und Freifunkern haben kann, was möglich sein kann, was unmöglich ist, versucht, eine gemeinsame Ebene uns Sprache zu finden.
Da uns die Zeit weglief, mussten wir dann irgendwann abbrechen. Die ersten 2 Beiträge auf http://www.freifunk-bno.de/component/option,com_smf/Itemid,88/topic,464.0/ beschreiben recht treffend, wie es wahr und um was es ging.
Danach entwickelte sich in dem Forum und auf der (Berliner) Mailingliste eine kontroverse Dsikussion, die zeigt, wieviele Missverständnisse es noch gibt.
Die erste Quelle von Missverständnissen war meine mangelhafte bis nicht vorhandene Informationspolitik:
Das Treffen mit den Jungs vom FOKUS habe ich nur im kleinen Kreis und in der Base angekündigt und habe danach keinen Bericht/Zusammenfassung gepostet. Unabhängig von den Gründen möchte ich dafür um Entschuldigung bitten. Ich werde in Zukunft hier über Fortschritte berichten und Treffen vorher ankündigen.
Für Topics hab ich http://wiki.freifunk.net/Science angefangen, bitte jetzt nicht ausdrucken und als amtliches Dokument behandeln, das ist ein Brainstorming, hier sind Ideen gefragt.
 
Wie gehts es weiter?
Jeden 2. Mittwoch des Monats treffen sich Forschende und Freifunker zum gemütlichen Austausch in der c-base um sich näher kennenzulernen, eine gemeinsame Sprache zu finden und über Projekte nachzudenken.
 
Zu meiner Person:
Ich bin Alex, komme aus Hamburg, hab dort Freifunk betrieben und wurde vor knapp einem Jahr von den "Headhuntern des Fraunhofer" (elektra, 1.3.06) nach Berlin geholt. Meine Bestrebungen, Freifunk mit der Forschung zu vernetzen, bekomme ich allerdings nicht bezahlt.
Gruss, Alex

Rundfreifunk: Livestreams im Freifunk-Netz und auf Radio Blau in Leipzig

Posted on by Mario Behling

Bereits bei we-funk05 (http://we-funk.de/) gab es konkrekte Überlegungen
zu überregionalen Audiostreams im Freifunk-Netz. Die erste Sendung lief in der letzten Woche, unter anderem mit
einem Livestream über 10 Freifunk-Hops!

Die Sendung war in Leipzig über
"Radio Blau" per UKW zu empfangen (multicast und ein freifunk-ungewohnter
Frequenzbereich) und weltweit über den mp3-Stream des freien Leipziger
Radios (http://www.public-ip.org/sendung-154.html). Falls
es in anderen Städten noch Interesse gibt, dabei mitzuarbeiten, würden wir
uns über Rückmeldung freuen. (Hallo Berlin, Wien, Petersborough,..) Sendung Nr. 2 wird zum großen Teil aus Weimar
kommen. p.s. das mp3-stream-Grundrauschen kommt demnächst noch weg
🙂

via Ufo

Wireless Community Weekend 2007 in Berlin

Posted on by Mario Behling

Wie es auf dem Blog
von cven bereits im November zu lesen war, plant die
Freifunk-Community auch in diesem Jahr wieder ein „Wireless
Community Weekend“.

Zeit: 26. April 2007 bis Sonntag 29.
April 2007
Ort: c-base
e.V. Rungestrasse 20, 10179 Berlin

Dieses Jahr werden neben Freifunker aus
Deutschland vermehrt internationale Teilnehmer erwartet. Wer am
Mittwoch bereits in Berlin ist, ist herzlich eingeladen am Abend beim
wöchentlichen Freifunkertreffen in der c-base vorbeizuschauen. Für die weitere Organisation des
WCW habe ich eine Wikiseite
angelegt.

Neues Freifunk-Wiki jetzt online auf wiki.freifunk.net

Posted on by Mario Behling

Das neue Freifunk-Wiki ist da und abrufbar unter: http://wiki.freifunk.net Die meisten relevanten Informationen sind bereits aus dem
alten Wiki übertragen. Wenn ich etwas vergessen habe, könnt ihr es aus dem
alten Wiki retten. Es ist noch unter https://freifunk.net/wiki/WikiStartArchiv zu
erreichen. Die ESSIDs/Subdomains der Communities mit Wikiseiten sind ebenfalls
bereits aktualisiert.

Das Wiki kann ohne Registrierung editiert werden. Als Schutz
vor Spambots habe ich ein Captcha-Plugin installiert. Sobald ein
neuer Link eingegeben wird, ist eine Rechenaufgabe zu lösen. 

Die Abgrenzung des Freifunk-Wikis zu Inhalten von Wikis
lokaler Communities erschließt sich für mich aus dem unterschiedlichen Fokus:
Einerseits Aufbau eines lokalen Netzwerks, andererseits Aufbau von
Freifunk-Netzwerken allgemein. Wir sollten uns daher hier – bei der Sammlung
von Inhalten – vor allem auf allgemeine Themen und praktische Tipps zum Aufbau
freier Netze konzentrieren. Dazu gehören z.B. Fragen wie: „Wie fange ich an
beim Aufbau eines lokalen Netzwerkes? Was brauche ich – Wissen, Werkzeuge etc.?
Welche Hardware ist für Freifunk-Netze geeignet? Wie baut man eine Antenne?
usw.“ Gleichzeitig können sich kleinere Communities ohne eigene Websites hier auch
ihre eigene Seite/eigenes Portal schaffen, um miteinander zu kommunizieren.

Das Freifunk-Wiki wird von Individual Network Berlin e.V., http://in-berlin.de,
gehostet. Herzlichen Dank für die freundliche Unterstützung und Betreuung
insbesondere an Christian. Die genutzte Software ist Mediawiki. Beim Design der
Startseite habe ich mich beim Weimar-Freifunk-Wiki (http://wireless.subsignal.org) inspirieren
lassen. Das Bild zeigt einen Rundblick über Weimar. 

In den kommenden Wochen werden wir auch nach und nach die
Verweise auf den anderen Freifunk-Sites anpassen. Wer Lust hat das Wiki
mitzuadministrieren, bitte meldet euch bei uns. Es wäre toll, wenn sich noch
mehr Leute finden würden.

Wir hoffen ihr habt Spaß mit dem Wiki und freuen uns auf
neue Einträge und zahlreiche Edits.

Freifunk in Rostock: Interview auf dem 23c3 Chaos Communication Congress

Posted on by Mario Behling

In der Wireless Corner treffen sich die Freifunker beim 23. Chaos Communication Congress am Alexanderplatz. Rene und Mathias von der Opennet-Initiative aus Rostock geben einen Einblick in die Organisation des lokalen Freifunk-Netzes, die Zusammenarbeit mit der Universität und erzählen über ihre eigene Motivation im Netz mitzumachen. Zudem berichtet Rene darüber, wie freie Netze kürzlich unter seiner Mithilfe in Kerala in Indien entstanden und Berliner Freifunker sich im Bundesstaat Goa engagieren.