Wireless OpenHardware

Hi all,

at the fantastic WSFII meeting during SAX at guifi.net in Spain we started to specify two wireless hardware devices. There were people from various free wireless network communites from Europe and the US. We had a three hour workshop and tried to define our wish list for cheap free open source software compatible open wireless hardware. Now we are trying to find the manufacturers who is willing to build those devices.

If you have any contacts that could help, please talk to them and show them our results. The company should best sell those products direct to the communites over webshop and only ship the bulk boards in charges of 20,50,100 or more. We think, that’s the best way to make them as cheep as possible.

There are quite a lot of people willing to help in e.g. software/driver-development or hardware-design. I am very positive that sooner or later some manufacturer is going to see their chance in our global movement!



1. Simple Node
– single wireless a/b/g radio device with support for virtual access points
– single Ethernet port with high tolerance PoE support (4-30V)
– power system must resist reverse polarity
– 4 Mbyte Flash
– 16 Mbyte RAM
– 200 MHz CPU
– serial port
– JTAG interface
– one Antenna plug (reverse SMC) and no explicit need for diversity
– for outdoor usage (which is regarded to be a standard scenario) the
board does not need a box and does not need to be shipped with antenna
and power supply
– power consumption should be as little as possible (solar systems!)

Comment: Finding the consensus on the design for the simple node was
quite easy and did not take very long. It seams that the needs and
wishes of the different groups represented by the attendees are very

2. Super Node
– two embedded wireless a/b/g radio devices with support for virtual
access points
– two Ethernet ports with standard 802.3af PoE support
– power system must resist reverse polarity
– 8 Mbyte Flash
– 32 Mbyte RAM
– 500 MHz CPU
– two USB 2.0 ports
– two miniPCI slots (both stackable up to 8 cards)
– serial port
– JTAG interface
– two Antenna plugs (reverse SMC) and no explicit need for diversity
– for outdoor usage (which is regarded to be a standard scenario) the
board does not need a box and does not need to be shipped with antennas
and power supply
– power consumption should be as little as possible (solar systems!)

Comment: Finding a compromise on the super node really was a hard time,
because there can be different ways to achieve the same goals. For
example, if wireless USB devices had a better FOSS support, many of the
super nodes could just easily be built without the need for miniPCI.
Also super nodes can be built with simple wireless bridges connected
over ethernet (high power consumption?). But anyway, after many looong
discussions the group had a consensus on the points listed above.

3. wireless USB devices
As already mentioned, super nodes could well be build using wireless USB
devices instead of mini PCI cards (less expensive cabling, less
interference between the devices). But to be able to use them, people
need FOSS drivers for them, which support all wireless modes (managed,
ad-hoc, AccessPoint), and the USB devices should have a reverse SMC
antenna connector.



c-base video – Home of the Freifunk-Community in Berlin

Die c-base crew hat "opto daten gefunden". Unter mühevoller Kleinstarbeit konnten einige Daten rekonstruiert werden. Sie stehen uns nun als Video zur Verfügung und geben einen Einblick, wie die Raumstation c-base früher einmal aussah. Daneben werden verschiedene Teams vorgestellt, die an der Rekonstruktion der Station arbeiten und, wie die Freifunker, versuchen die Technologien für die Gesellschaft nutzbar zu machen. Viel Spaß beim Angucken!

Podcast von der B.A.T.M.A.N.-Release-Party in Berlin auf Rundfreifunk

(via Ufo)
Am letzten Sonntag liefen auf Rundfreifunk Interviews von der B.A.T.M.A.N.-Release-Party. Die Party fand auf der c-base in Berlin statt. Die Sendung findet man nun auch online unter http://www.public-ip.org/sendung-170.html. Darin unter anderem Interviews mit: Elektra, Sven-Ola., Tetzlav, Ludger und Poelzi zu OLSR, BATMAN, Firewalls und Puffer-/Pollraten…

Rundfreifunk sendet in Leipzig auf UKW und im Internet unter http://rund.freifunk.net und http://www.public-ip.org.

Viel Spaß beim Hören! 

SAX2007: International WSFII Summit in Catalonia

(via Jürgen Neumann, original post @ http://guifi.net/ca/SAX2007En)

In Katalonien findet im Juli ein interessantes Communitytreffen statt. Vielleicht interessiert es einige Freifunker.

This year, the traditional meeting for the free civil networks in
Catalonia (SAX) will be extended to new contents, will take a week and
will be extended to new participants worldwide and therefore affiliated
to the WSFII (World 
Summit for Free Information Infrastructures). The registration will be
free and everyone interested in developing non-proprietary networks is

The main purpose of the SAX & WSFII event in
Catalonia is to empower and develop at all levels the civilian, open
and free infrastructures as an alternative to the classic
proprietary/corporate owned or operated network models. Around this
objective, we plan to have presence with panelists from all the actors
involved, including local government, enterprises of any size,
regulator authority, and of course, the geek community involved in the
research and development activities and the users in general.

should come to this SAX2007 & WSFII  event if you are part of a
user community or you want to start one, a local government or local
business and you whish to share your experience or understand how free
networks can become a success and sustainable instead of just draining
funds to feed unprofitable "business" models.

Take a look at the schedule. Wou'll see there the topics and the major actors of the open networks worldwide. 

event will be scheduled by days; some might be in parallel (stay tuned
to the schedule, which may change until the very last day): 

In all cases, will be keynotes, panelists and open discussions. Where makes sense, will be also practical exercises.

  • Business day. How
    can any business be friendly developed within the context of neutral
    and free infrastructures? How this can provide good ROI cases and boost
    productivity? What is saying the Spanish regulators about that? Success
  • Developer's day. How developers, hackers and geeks can contribute? Which are the methodologies for doing so? Hacking, new things, what to do…
  • Backbone day.
    Keeping the network up to date to the state of the art of the
    technology. We will configure a telecommunications tower with both long
    distance links and CPE coverage to the users at Sant Bartomeu del Grau.
  • Local government and municipalities day.
    What means civil and free networks and which unique benefits local
    governments and municipalities can take from them? Why they are a great
    opportunity for developing the civil society and increase digital
    inclusion percentages up to unprecedented levels? Real world examples:
    Hear some elected people experiencies and regulators. Understand how
    more than 40 municipalities have succesfully participated in building
    free networks around guifi.net.
  • User's day. How
    it works and how non-technical people can participate in the free
    networks? Benefits. How to connect. What has to be done at home.
    Equipments to buy or consct. Trainings.
  • "guifi.net tour". Visit and see how solar powered backbone long-distance links provide broadband access to rural areas in the pyrenees mountains.
  • Community day. What we can do, as a community, to help each other? Find out synergies, common tactics and strategies.
    • In Catalonia (SAX)
    • In Spain (redlibre)
    • South Europe, Europe worldwide and developing countries (WSFII)

Everyone interested in adding content to the SAX&WSFII is very
welcome, just contact us. Only take in mind that SAX&WSFII is about
free (as in freedom, not as in beer or as in built with open source but
proprietary) network infrastructures.

WiOpt’08 – International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks

(vie Thomas Hirsch)
Vielleicht interessant für den ein oder anderen, der der Wissenschaftswelt einmal über seine Erfahrungen und Ergebnisse im Freifunk-Netz berichten möchte.

Was bringts:
– Feedback. Das Papier wird auf jeden Fall von drei Leuten aus verschiedenen Fachgebieten quergelesen. Anschließend darf man einen Vortrag vor noch mehr Leuten halten, und wird im Konferenzjournal abgedruckt. Potentiell erreicht man also viele Leute, die Ahnung von Mesh-Dingen haben, Interessante Dinge  mit Funknetzen machen, oder sich das ganze auch mal nur aus der Mathematikerbrille betrachten.
– Aufmerksamkeit über den eigenen Kiez hinaus.

Übersicht über die Beiträge und Teilnehmer hier:

6th Intl. Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks March 31 – April 4, Berlin, Germany

Scope of the Symposium
This symposium intends to bring together researchers and practitioners working on optimization of wireless network design and operations. It welcomes works on different perspectives, including performance analysis and simulation, protocol design, numerical communication and optimization theory, for all forms of wireless networks: cellular, wide, metropolitan, local and personal-area networks, dense and sparse ad-hoc networks, domain specific vehicular, public-transport, application-specific sensor networks, as well as any combination of these.
Topics of interest include, but are not limited to:

* Modeling, simulations and measurements
* Protocol design
* Spectrum allocation
* Security and intrusion detection
* Pricing and incentives
* Scalability, manageability and optimization
* System capacity and performance
* Mobility and multihoming
* Opportunistic and cooperative scheduling
* Cognitive radio
* Interference control
* Energy efficiency


The submission format for the papers is an extended abstract, up to eight pages long. Please use the IEEE Transactions format, 11 pt character size, one column text, one-and-a-half line spacing, letter paper. This page budget should contain all figures, tables, references, etc. The extended abstract should also include a brief abstract of up to 150 words. The submission will be handled via EDAS ( http://edas.info ). Only PDF files are acceptable; please make sure that the paper prints without problems (take care to embed all required fonts, etc.). Adjunct Workshops Several one-day workshops are planned to accompany the main WiOpt


WiNMee/WiTMeMo 2008 : International Workshop On Wireless Network Measurement RAWNET 2008 : Resource Allocation in Wireless Networks
SPASWIN 2008: Spatial Stochastic Models for Wireless Networks
WNC3 2008 : Wireless Networks: Communication, Cooperation and Competition

Important Dates

Conference: April 1-3, 2008
Workshops: March 31-April 4, 2008
Submission deadline: October 1, 2007
Notification of acceptance: December 15, 2007 Camera-ready copy: January
15, 2007

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

(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.

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
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.

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

(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

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

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
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

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.

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

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.
// 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.
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 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 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" as well as "Steven uses".
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" 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 to (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 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: "". 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: "". 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: "". 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". This proves, that both private IP ranges (the and 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?

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


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.


was war

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