Free Network News

Call to fund experiments from SME (Fed4FIRE)

Confine -

(By leandro in CONFINE Project.)

Community-Lab is part of the Fed4FIRE federated testbeds. As part of that there’s a call to fund experiments from SME (typically European but other countries may apply). See below. You can get up to 25,000 € with a quite lightweight application.

2ndFed4FIRE competitive call for SME Experimenters – An instrument for SME’s to get involved in FIRE activities
Get involved in Future Internet … Get access to advanced Future Internet testbeds … Get funding for running your own experiments on these testbeds…

Fed4FIRE has just launched its 2nd Open Call specifically targeting SMEs using a simplified and fast application and review process. The major objective of this Open SME Call 2 is to make the federated infrastructure easier and more directly available for execution of innovative experiments by experimenters at SMEs. These experiments should be of a short duration (maximum 4 months) and should demonstrate technological expertise, novelty and quality in the area of Future Internet (e.g. in domains such as wired and wireless IP networks, cloud computing, software defined networks and innovative Internet services).

The SME experimenters should seek contact with the Fed4FIRE consortium partners prior to submitting their proposal for a feasibility check of the project. One of the Fed4FIRE partners will also act as a “Patron” during the execution of the experiment and will receive an additional funding of up to 10k to provide direct support to the SME.
Max. funding request per experiment of € 25 000 (+€ 10 000 for Fed4FIRE partner acting as “patron”)

Submission deadline: 30 October 2014, at 17:00 Brussels local time

Network Commons Part 3

Confine -

(By Armin Medosch in Confine@Funkfeuer.)

This chapter starts out with a summary of the achievements of Consume.net, London and then traces the development of this idea, how it was spread, picked up, transformed by communities in Germany, Denmark and Austria. The internationalisation of the free network project also saw significant innovations and contributions, developing a richer and more sustainable version of the network commons through groups such as Freifunk.

Full text : http://thenextlayer.org/node/1284

September sprint

Confine -

(By tanzer in Confine@Funkfeuer.)

In the first week of September, Mihi, Ralf and me did a sprint on the CNDB.

Mihi did a lot of work on the dashboard, Ralf improved the converter for the old database of Funkfeuer Graz and worked on IP allocation.

I fixed several bugs of the dashboard, some of which had been introduced by the refactoring done in June. More important, I extended the dashboard to include IP allocation and deletion.

During the work on IP allocation, Ralf and I stumbled over a shortcoming of the query implementation. The permission model for nodes comprises two checks: the currently logged in person

  • either is owner or manager of the node in question,
  • or is member of a group that is owner or manager of the node in question.

To be able to write such a query, I added support for restricting the type of an abstract attribute like owner or manager that allows all instances of Subject to a subtype like Person or Group.

To simplify interactive testing, I added a script command to the CNDB application. That way, one can easily set up test objects, e.g. IP-pools, after running the converter for Funkfeuer Wien or Funkfeuer Graz.

Special session on community networks and services in GECON 2015

Confine -

(By felix in CONFINE Project.)

We presented in GECON 2014 a paper on the participatory analysis in Guifi, in order to raise a discussion on how community clouds need to be designed regarding their economic and social components. You can find our paper in the GECON programm.

We found GECON as an excellent forum to discuss on interdisciplinary aspects of community network systems and services. As a consequence, we agreed with the GECON organizers to prepare a special session on community networks and services in the next GECON 2015, in order to bring together researchers working in various disciplines of this field.

Dashboard Sprinting

Confine -

(By mihi in Confine@Funkfeuer.)

This week Christian, Ralf and Myself spent sprinting the dashboard to a state we can have alpha-testers use it. We decided to set up a test-instance of the CNDB for our friends at FunkFeuer Graz to get useful input from them on how to push the dashboard forwards.

Right now the dashboard not only looks fancy but the basic functionality for network participants is implemented.

Key features:

The dashboard now has a nice map showing all the nodes the user manages and their position:

Next, Node creation and editing also has a map. You can assign the position of the node either through the map or through geo-lookup of the nodes address.

More bling:
The node list can of course be filtered (both through the map and through the list) and all devices etc. added and edited.

Overall this week of dashboard sprint brought us and the common node db closer to the goal of having a management software that is not only representing the network well in its data structure but has an attractive surface to participants of networks.

Links sammeln und Termine teilen

Freifunk Blog -

Was ist das?

Die beiden Werkzeuge LinkSink und Calcifer sind nun einsatzbereit. Mit LinkSink können wir für Freifunk Links zu unseren Themen zusammentragen und daraus RSS-Feeds erstellen. Durch Kategorisierung und Hinzufügen von Tags können wir damit sehr flexibel RSS-Feeds zu bestimmten Themen bereitstellen und bei vorhandenen Mediendateien sogar diese einbinden. Calcifer kann man zum Verwalten von Terminen und Erstellung von ics-Dateien verwenden. Auch hier kann nach Tags und Orten gefiltert werden.

Für einige Anwendungen nutzen wir beide Werkzeuge schon aktiv:

Wie funktioniert das?Auswahl und Filter

Auf der Startseite sind zunächst alle Einträge zu sehen. Durc h einen Klick auf ein Tag eines Eintrags oder durch Nutzung der Filterleiste kann man diese Auswahl einschränken. In Calcifer kann derzeit entweder nach Tags oder nach Orten gefiltert werden. Filter in LinkSink können Kategorie, Jahr und ein Tag enthalten.

Fü r ein Filterergebnis steht dann ein Link zum RSS-Feed oder der ICS-Datei bereit. Die URL des Feeds bleibt konstant, so dass diese in anderen Anwendungen permanent eingesetzt werden kann. Mit jedem Aufruf wird der dahinterliegende Feed neu erzeugt und mit aktuellen Daten gefüllt. Calcifer erzeugt dabei nur in der Zukunft liegende Termine. LinkSink ordnet die Einträge absteigend nach Erscheinungsdatum.

Neue Links oder Termine kann man mit einem Klick auf Neuer Link bzw. Neuer Termin oben in der Navigationsleiste anlegen. Dann öffnet sich das entsprechende Formular. Sind alle Pflichtfelder richtig gefüllt, kann der neue Eintrag gespeichert werden.

Mediendateien wie bei Podcasts können zu einem Linkeintrag hinzugefügt werden. Die notwendigen Felder für Länge und Typ stellt LinkSink beim Speichern fest und schreibt die Werte in die Datenbank. Die RSS-Feeds sind so aufgebaut, dass Podcastclients integrierte Audiodateien erkennen können und abspielen.

Calcifer kann auch wiederholende, regelmäßige Termine anlegen. Als Intervalle sind wöchentlich, 2-wöchentlich und monatlich auswählbar. Das Verwaltung wiederkehrender Termine erreicht man durch einen Klick auf den Link in der Navigationsleiste oben.

Zur Erleichterung der Aufnahme neuer Links gibt es ein sogenanntes Bookmarklet. Das ist in der Navigationsleiste rechts oben zu finden. Um es zu nutzen, zieht man es in die Bookmarkleiste des eigenen Browsers. Auf Webseiten, die als man als Link speichern möchte, drückt man dann auf dieses Bookmark und wird zu einem vorausgefüllten Formular in LinkSink weitergeleitet. Das Bookmarklet erfordert ein aktiviertes Javascript im Browser, bei Erweiterungen wie Privacy Badger müssen Ausnahmen für rss.freifunk.net erstellt werden, damit Javascript von einer anderen Seite ausgeführt werden kann.

Vereinbarungen

Damit das Chaos überschaubar bleibt sind hier noch ein paar wenige Regeln: 

  • soll ein Link im Medienspiegel auftauchen muss das Tag Medienspiegel gesetzt sein. Wenn es eine Community betrifft ist es schön, wenn ein weiteres Tag mit dem Communitynamen dazukommt
  • Für eine schöne Darstellung im Medienspiegel sollte das Quellmedium auftauchen. Der Titel für einen Medienspiegeleintrag sollte so aussehen: <Quellmedium>: <Titel>
  • Termine in Calcifer, die communityübergreifend stattfinden (z.B. WCW oder der Congress) verseht ihr bitte mit dem Tag freifunk_common. Diese Termine erscheinen dann im gemeinsamen Kalender mit der Markierung, dass es sich um einen übergreifenden Termin handelt. Communityeigene Termine taggt ihr bitte nicht mit freifunk_common, sondern z.B. mit eurem Communitynamen. Den Feed dafür könnt ihr dann per Freifunk API bereitstellen, wodurch sie ebenfalls in den gemeinsamen Kalender kommen. Dann sind sie aber als Termine eurer Community markiert.
Nutzung

Jede Community darf die beiden Werkzeuge gern benutzen. Achtet bitte darauf, die Tags und Orte richtig zu setzen, damit es nicht zu Überschneidungen mit anderen Communities kommt. Versucht auch, doppelte Einträge zu vermeiden, fügt lieber euer Tag zu einem Eintrag hinzu, falls ihr ihn auch in eurem Filterergebnis haben wollt.

Falls euch das alles zu unübersichtlich wird könnt ihr auch eigene Instanzen installieren. Beide Werkzeuge sind quelloffen und werden in Github-Repositories gepflegt (LinkSink, Calcifer) und freuen sich über weitere Installation oder Mithilfe und Anregungen zur Weiterentwicklung.

GSoC: Work on Freifunk API Query Client will go on

Freifunk Blog -

This is the final blogpost for my GSoC project for the Freifunk-API Query Client.

Goals
 
We want a comfortable tool to query all the Freifunk API files as there are nearly 100 communities all over Germany providing their data. There are already several applications like our community map, a common calendar, our feed aggrator or the community podcast collector. But it's still hard to find communities by properties like routing protocols or focus topics.
 
Challenges
 
When we began this project we only planned to query the generated JSON data for the community in a browser and additionally provide query results via a webservice. But then we talked to several people and we heard about DeepaMehta with features like connectors to OpenStreetmap. So we did something what you don't do normally: We changed our project goals before the midterm evaluations.
 
DeepaMehta is not just another database product, it provides a different way to store and handle data. It uses a graph to store connections between items and allows to modex complex datatypes and associations between them. We had to change our mind and had to learn a new kind of thinking. The API data is constantly evolving and changing and there a lot of cross-references in the data e.g. links to various nodemaps. We think the switch to DeepaMehta is useful because we can query the graph and add new relations and data without problems.

 
It's difficult to handle different spec versions if you want to query all API files, because some fields changed, other fields were added to the specs or got another meaning. In an ideal world all communities update their files as soon as possible. But we all know, it will never happen like that. As a workaround we first focused on less fields, available in all versions.
 
What we got
 
We're able to import communities from the API directory as a base entity. We also tried some different ways to import and store the specs, but we need some improvements here. By using the summarized API file, the import of our payload can be done via the DeepaMehta REST API.

The switch to DeepaMehta brought a lot of complexity to the project and I'm personally not happy my results at this point because I had trouble to spend enough time for the project. Additionally some basic problems like dealing with changing schema and data import are not really solved well at this point. The data is in DeepaMehta and can be queries with the included client but it's not in a state where it's usable for the community.

Overall the GSoC was an interesting experience for me. Through I've failed to set aside enough time for the tasks. The timely overlap with university lectures does not make it easier. So I can only recommend to know beforehand that you'll have enough time to accomplish your goals. But the support from the Freifunk community was always great and helpful! As the project is not a state that can be considered 'ready' I'm continuing working on it.
 
Future Plans

I definitly want to finish the work at least to point where it can be used by the wider Freifunk community.

The default DeepaMehta client isn't designated to query a lot of fields like our API provides. Here we need a new web based client to provide users an interface to select fields and get a proper response.

Work will continue on integrating the API data and DeepaMehta.

Repository: https://github.com/freifunk/query.api.freifunk.net

Final Blog Post: Netengine

Freifunk Blog -

Hi everybody, this is going to be my last blog post as a participant of GSOC2014. I'm very sad about this, those have been very hard worked months but very formative.

I improved both my coding skills but above all I have earned a work methodology thanks to my mentor Federico, who said to me to be more reflexive and to be more precise in what I do.

I have learnt some aspect of versioning (Git) I ignored before and learned much more on Python than I did by myself.

This is the “change log” of the last time period of the program: we developed a new backend, the HTTP backend. It aims to retrieve informations from the web admin interface of AirOS devices, that's why we called it HTTP.

We wrote documentation about all the project, describing all the things an user should do both to contribute or use Netengine, trying to be as much more clear and to make it simpler as we could.

Unfortunately this is my last year as a student, no PhD on my way (for now), so I will not be eligible at all for next editions coming.

Greetings and thanks: I would like to thank Ninux , the community network I’ve worked with. I’ve had the possibility of joining their meetings, to talk a lot with every member and to be supported every time I had some problem about what I was doing.
Obviously my mentor Federico Capoano, Mario Behling from Freifunk who supervised projects.

For further questions on the project please visit https://github.com/ninuxorg/netengine or email us at ninuxdev@ml.ninux.org or read the docs!

GSoC 2014 Final - OpenWrt: IEEE 802.1ad VLAN support

Freifunk Blog -

Hi all!

Because I have worked very hard in the first part of GSoC, the implementation was almost done already for mid term, in the second part I have been mostly testing the code, and taking advantage of it in a lot of setups :)

The GSoC experience have been very formative to me and I would like to repeat it next year either as student or mentor :)

Moreover I'll suggests to apply to GSoC to a lot of friends!

Many thanks to Freifunk to chose my proposal I hope you will take advantage of 802.1ad too :)

Cheers!

GSoC 2014: Hardware Detection [ Final ]

Freifunk Blog -

 

Hi everyone!

I am very happy to have participated do GSoC 2014, this experience have permitted to me to learn a lot about opensorce comminity and programming, i have learned also Lua programming language, while it seemed a little ugly  to me in the firsts times I ended up loving it.

This GSoC project permits to people installing Libre-Mesh on their devices and have device specific quirks already solved by the hardware detection module, without user intervention, while it permits to developers to write little modules to easly supports new hardwares and solve their quirks.

In particular in the second part of my GSoC I have improved hardware detection, in particular I have created a module to autoconfigure TL-WDR3600 and a module that permits to Libre-Mesh to detect wan port of a lot of routers taking advantage of the OpenWRT infrastructure.

While creating those new modules I have also realized how to improve general Libre-Mesh infrastructure and committed various improvement to the hardware-detection branch, that is now in the official repository ready for merging in develop branch.

Futhermore, during the last phase of this project I have optimized the code including modules I have written in the first period like usbradio detection module. 

Obviously all this work have been possible thank to the help of the community that helped me in the whole coding period.

Best Regards ;)

GSoC: nodewatcher v3

Freifunk Blog -

Hello all!

Thanks to this year's GSoC, a lot of work has been done on nodewatcher v3 platform. It now has a better, modular monitoring agent that can run on OpenWrt-supported devices, with a new JSON-based output format that can be easily reused by other projects as well. The platform has been ported to the latest stable version of Django (1.6) together with all migrations and dependencies. Development environment setup now uses Docker and fig in order to make it very easy to dive into the code without having to battle with various dependencies.

The API for access to node configuration and monitoring data (registry API) has been much improved, with better, more usable querying capabilities and performance. During development we have discovered a bug with cascade deletions and  polymorphic models in Django. Node configuration editor based on the registry API now supports references between form models that have not yet been saved -- this functionality enables configuration of bridge interfaces which are now also supported by the firmware generator. I have implemented type support in the datastream library for long-term monitoring data storage with a new type for storing graphs as datapoints. This enables nodewatcher v3 to use datastream to store how the network topology evolves over time.

All the code is available on GitHub in several repositories:

GSoC: Retroshare social network plugin review and future

Freifunk Blog -

During Google Summer of Code i did these things:
- learn what users expect from a social network. Figure out who should receive which messages.
- map social network functions on the existing Retroshare General Exchange System
- build a backend with basic features
- build a frontend with basic features
- started a new programming interface on top of libretroshare: a JSON over http interface

The Secushare homepage says: "RetroShare should provide more social functionality" Indeed! Every country is spying on their citizens. Storage, computing power and bandwidth became cheap. These are good conditions to build a distributed social network. The first step was already started a while ago with the General Exchange System for Retroshare v0.6. This project is the second step in this direction. One thing is missing: a release for normal users.

The backend and frontend made during GSoC can display a wall with avatar image and profile text. It is possible to create posts and reference them on walls. Posts can be commented. Read more details in the previous blog post. Still it is not suitable for daily use. There was not enough time to implement a scalable user interface architecture. The web interface can't handle more than 100 posts, because pagination is missing. Whats more the UI is filled iterative. This causes many updates to the html tree with high cpu load. It would be better to send all information to the browser in one piece. The browser would then only have to update the HTML tree once. The design and layout should be improved to highlight the content and to get the date label out the way. (See the this screenshot.)

Future

Wt is nice because it allows to make a web interface without touching HTML JavaScript and CSS. But this is only the half truth. There where issues:
- completely destroyed layout by setting the image size
- menu bar was horizontal instead of vertical, this required to manual set a style class from C++
- WTimer stops working. I had to build my own server side timer

These issues where solvable. A real pain with Wt is the layout and UI design testing. You first have to go through the complete compile and start cycle to see changes. What if you missed a closing tag in a HTML template? You have to recompile and restart. Now i saw that with real web technologies you can see a live preview while you type. I think when doing layout and design it is important to immediately see the result. This is not possible with Wt. Conclusion: you can build a web interface with C++. But hard coding CSS class names and embedding HTML snippets in C++ is a pain that should be avoided.

On the other hand there exist advanced tools and frameworks for web development. AngularJS is a very nice JavaScript library. It offers data binding from JavaScript to HTML: you update a JavaScript object, and Angular updates the HTML. JavaScript objects are more flexible than C++ objects. You can even make a JavaScript object out of a JSON file. Angular makes handling of button clicks easy. AngularJS makes  Bootstrap offers a set of widgets with HTML example code and style sheets. Now i want to use other web frameworks instead of Wt.

I did not know about these web technologies when starting the project. This is some sort of a chicken-egg problem: Retroshare does not have web developers, because it doesn't have a web interface. And there will be no web interface until a web developer can show how it can be done. Gladly there is now a web developer who can teach me how to make a web interface.

The new idea: make a web interface using web technologies

The next goal is to make a clean and easy to use JSON over HTTP api for Retroshare. Then web developers are free to make a nice web interface using their favorite frameworks. This api is not only useful for web interfaces, but also for scripting. You could then send a chat message from a shell script using curl:

curl -X PUT -d '{"msg":"hi all<br/>(send from bash)"}' http://localhost:9090/api/chatlobbies/<id>

What i will do now
I will do more research for a JSON over HTTP interface for Retroshare and rssocialnet. If this stays a good idea i want to implements it. Maybe i will try to start a new web interface. But i hope someone else is faster than me. I prefer to work on the rssocialnet backend and libretroshare. Whats more a web interface is a perfect place for new contributors. If i would make a clearly documented JSON over HTTP api, then a web developer would not need C++ knowledge or experience with libretroshare.

A dream is to bring Retroshare to Android. This is possible, but we have to make a new touch-friendly user interface and we have to optimize Retroshare to make it more battery friendly. I currently see two ways to build a GUI for Android: with QML/QtQuick or HTML based with the Ionic Framework. There is already a QML prototype.

To get rssocialnet ready for daily use, i need your help. Unfortunately I’m again in a research/planning phase. This means I’m not sure how the JSON over HTTP interface will look at the end. It also means if you tell me "i want to help coding", i have to disappoint you because i don't know what we have to code and how to code it. Anyway, here are some things you can think about:

- which features are important for a social network? read some ideas
- can you make a better gui mockup than me?
- which frontend technologie should be used? QML/QtQuick or Bootstrap and AngularJS?
- what are the requirements for a first release?
- how can you use your skills to help?

Thank you Freifunk and other mesh network communities for donating one GSoC slot to Retroshare. This was a good decision, it made it possible to start a mesh friendly social network application.

AttachmentSize retroshare-4-webinterface-graph.png15.87 KB

GSoC: Features of the Retroshare social network plugin

Freifunk Blog -

Content is obviously the most important element of a social network. Currently only support for plain text is implemented. The content can have an author, but this is not required.

Future: It would be nice to have support for images. This is very easy on the backend side, but it needs a frontend which scales the image to fit on the screen. With Retroshares file transfer capabilities it would also be possible to publish large files like audio and video files. It would be nice to restrict access to content to a set of people. Retroshare is prepared for this and it only needs small changes in the social network backend. Of course this requires a user interface to sort people into circles and to select circles.

Content alone is useless without a place where it gets displayed. As explained in a previous blog post, every piece of content is stored for its own. To make content visible it has to get referenced on a wall. This happens automatically on the own wall when creating a new post. It also gets triggered by clicking the share button. A reference always has an author.

Future: maybe allow to reference content from other services. For example if Retroshare gets a Photo Share service, allow to reference a picture or photo album on the wall.

A Wall is a place where a profile text, an avatar image and references to content are stored. A user subscribes to another user to download all posts referenced on the wall. The wall owner and others can reference content on a wall.

All new posts are collected and displayed in the news feed. A news feed shows the new content, the comments and how others interact with the content. Who commented this post? Who shared this post? Currently the news feed displays posts in the order in which they where received.

Future: it is probably desired to have a more advanced logic to sort news feed entries. Imagine a user comes online after a week and gets bombed by hundred new posts. It would be possible to sort news in two dimensions: topics and rating. Example: have one tab for content from close friends, and one tab for other content. Then calculate a score to display more important content at the top. This requires a bit of backend work, but it is doable.

Users can interact with content in two different ways: they can comment it, and they can share it. Sharing creates a reference to the content on the own wall, and thus forwards the content to friends. Comments are stored with the content, so everyone who received the content will also receive the comments.

Future: one can think of other ways to interact with content. Examples are like, bookmark, vote and hide. In general these interactions are each a form of tagging. For the backend it does not make a difference if content is tagged with "GSoC14" or "like" or 3.1415. This is more a matter on the frontend side: which meaning does the tag have for the user? How does the frontend show different tags? (star, heart, thumbs up, plus sign, text, ...) How can the user filter posts with specific tags?

There has to be an entry point to let the user see the people around him. If the user recognizes a known person he might want to subscribe to this person. For now there is a widget to display all identities with their name and avatar image. Of course later this list should get filtered to fit on the screen. Retroshare circles could be used to make friends lists accessible to friends. This would allow automatic circle intersection to search for people the user probably knows.

Below is screenshot of the Retroshare social network plugin.

AttachmentSize retroshare-3-rssocialnet-screenshot.png43.98 KB

[GSoC-2014] Final report of the GSoC project: “BGP/Bird integration with OpenWRT and QMP”

Freifunk Blog -

Here I present you a report of the finals state of my GSoC project. For further information feel free to  contact me using the channels described in the github and documentation.



“BGP/Bird integration with OpenWRT and QMP” [0] project's main goals were to improve Bird4/6 Daemon [1] adding a better integration with OpenWRT bringing UCI configuration to it, to add an user-friendly interface to make it easier using the LuCI web-framework, to be able to port it to QMP mesh networks and, finally, to automate the route exchange and metric translation between Guifi.net (BGP) and QMP (BMX6) [2].


Current solution consists on two OpenWRT packets: bird4/6-uci and bird4/6-luci. While bird4/6-uci allows the user to modify Bird’s configuration and apply it using the init.d script, the bird4/6-luci package brings a web interface to make this UCI configuration even easier.


Regarding bird4/6-uci package, UCI configuration scheme was agreed with Bird main developers owing, not just to make a solution, but also to consensus its development and characteristics with their main developers. The package includes a DOCUMENTATION file with all the available options, its description and examples.


Regarding bird4/6-luci package, it brings all the necessary files to add LuCI web-based configuration interface and has bird4/6-uci as a dependency.


Finally, the solution used to automate the translation and exchange of routes between BGP and BMX6, uses Bird filters instead of an external developed tool:

First of all, as BGP routes are automatically exported and imported only using UCI configuration, the efforts were put into the reverse part. Second, initial experiments were done in the WiBed platform [3], owing to be able to repeat and test the solution without the possibility of “breaking anything”. Once the solution was stable enough, packages were installed in a QMP mesh with 5 nodes (2x WDR4300, 1x WDR3900, 1x WRTNode and 1x WR703N) and also connected with a Mikrotik RouterBoard 750G to check the routes exported. Moreover, some tests were made connecting the RouterBoard to Guifi.net’s UPC point, working with more than 500 routes.


Example of original Bird configuration:


log "/tmp/bird4.log" all;
debug protocols all;
 
#Router ID
router id 10.1.26.50;
 
#Secondary tables
table aux;

Example of the same configuration using UCI:

config global 'global'
    option log_file '/tmp/bird4.log'
    option log 'all'
    option debug 'all'
    option router_id '10.1.26.50'

config table
    option name 'aux'

An example of the LuCI configuration web page can be seen here:

Example of BMX6 Routes and how are they filtered:

# ip r show
10.0.0.0/8 dev bmxOut_HW-Ermi  proto static  metric 1024
10.1.32.0/27 dev bmxOut_HW-Ermi  proto static  metric 1024


The pattern used in IPv4 filters is the device name "bmx*" and also the metric "1024" owing not to repeat or export internal routes.

In IPv6 the procedure used is to filter the 60 kernel table, as it contains all BMX6 iroutes:

# ip -6 r s table 60
fd66:66:66:8:de9f:dbff:fe35:17b6 via fe80::de9f:dbff:fe34:17b6 dev wlan0.12  proto static  metric 1024
fd66:66:66:a:de9f:dbff:fe34:17b6 via fe80::de9f:dbff:fe34:17b6 dev wlan0.12  proto static  metric 1024

Future work:

  • Continue adding the rest of BGP options to improve the solution.
  • Add OSPF (first of all) and the rest of the protocols to the UCI and LuCI solution.
  • Send the bird4/6-uci/luci package to OpenWRT willing to became an official package.
  • Continue giving support to package users and maintaining it.

Both package repositories are actually in my personal Github account [4] and [5].

Finally, I want to  thank Freifunk for the opportunity given to me with this GSoC project, to my mentors Roger Baig and Axel Neumann, to Pau Escrich for his support during the project and to Guifi.net and QMP project and their communities for the support received.

Eloi Carbó Solé.


[0] http://blog.freifunk.net/2014/gsoc-bgpbird-integration-openwrt-and-qmp-project-report

[1] https://github.com/openwrt-routing/packages/tree/master/bird

[2] http://qmp.cat/News/12_Google_Summer_of_Code_2014_and_QMP

[3] http://wiki.confine-project.eu/wibed:start

[4] https://github.com/eloicaso/bird4-openwrt

[5] https://github.com/eloicaso/bird6-openwrt

 

 

 

GSoC 2014: Source-sensitive routing in Babel

Freifunk Blog -

In Google Summer of Code 2014. I managed to finish my implementation of source-sensitive routing in Babel, and here is a complete review of the project :

I. Introduction and Background

    1. The Packets

Data on the Internet is transmitted by packet switching, this means that data is cut in several packets and each packet is sent on the network. In order to get the packets to their final destination, these jump from router to router. They are then recombined to get the original data. The source and the destination of each packet are stored in its header.

    2. Next-Hop Paradigm

Packets then travel via routers, which are computing devices connected to one another. Their role is to forward each packet to their right neighbor so that the packet can reach its destination. To do so, they use a data structure called the RIB or Routing Information Base. This RIB gives, for each destination, the next correct router. By doing so, each packet can reach its destination by following local routes. This paradigm is called the "Next-Hop Routing".

    3. The Quagga Project

Quagga is routing software that takes care of building the RIB. It implements several routing protocols, including Babel.

    4. Zebra / Babel

Quagga is implemented on two levels. The daemon that takes care of the level that is the closest to the kernel is called Zebra, its role is to install the routes in the kernel. Quagga installs all the possible routes to a destination, in addition of the ones the user gives him, and sends all those routes to Zebra. Zebra then chooses the best one for each given destination and install them in the kernel.

    5. Source-Specific

Source-specific routing is a small extension of current routing systems. Instead of looking only at the destination in order to choose the next-hop, we use other informations already present in the packet but not used yet, the source being one of them. My contribution adds the possibility to route packets according to the pair (source, destination) instead of looking only at the destination to Babel.

    6. Its Application

One of the main goals of source-specific routing is to enable multi-homing quite easily in the absence of NAT, for example IPv6. Without source-specific routing, there is no way to identify the route taken by two packets when they have the same destination, since they just follow the route indicated by the RIB. With source-specific routing, the packets can travel to border routers using different routes and then be treated as normal packets by these border routers. The packets are then sent normally through the Internet. The source-specific routing inside a local network is a solution to the multi-homing problem in a setup in which there is no collaboration of the Internet Service Provider (ISP).

II. What I Contributed

    1. Getting in a large project

The Quagga project is a large open source routing software. It contains 287000 lines of code, and is separated in different routing protocols, including Babel. The Babel code is only 9860 lines, but it is a reasonable project to start with. With its event-driven code, Babel was a little hard to understand at first, but I had several works I could rely on.

    2. My participation

First, I took a few days getting used to ad-hoc networks and then proceeded to code the program itself. I could rely on Matthieu's work, who implemented a stand alone version of Babel to have a backbone that supported my work. I recoded the functions that needed a prefix by including a source in them as well. I then merged my work in Quagga by using Zebra's new source-specific functions, and after a bit of rewriting, everything was running well. I tested my code in complicated circumstances, by running it and moving around the lab. At first, my program crashed a lot, but after modifications in my code, it crashed less and less. I reached a point where I couldn't make it crash anymore. I let the program run for several hours, moved with the computer, and Babel was still running fine. I can now tell that the program is solid.

III. How-To

Now that I introduced the work I have done, you might wonder how to use these new source-specific routes. Babel users can now skip to part 7, for the others I will explain how to get a mesh network running. I will show you how to do it via cable. To do it via wifi, I suggest looking at how to configure an ad-hoc network.

    1. Configure your network

The first thing you want to do is to shut down any network manager that is running. For example under Debian: "service  <network manager> stop". Then to make sure your interface is up, run for example, "ifconfig" in a terminal. You should see something like this:

$ ifconfig
eth0        Link encap:Ethernet  HWaddr 00:11:22:33:44:55
            UP BROADCAST MULTICAST  MTU:1500  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:1
            collisions:0 txqueuelen:1000
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo          Link encap:Local Loopback
            inet addr:127.0.0.1  Mask:255.0.0.0
            inet6 addr: ::1/128 Scope:Host
            UP LOOPBACK RUNNING  MTU:65536  Metric:1
            RX packets:12 errors:0 dropped:0 overruns:0 frame:0
            TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:1134 (1.1 KB)  TX bytes:1134 (1.1 KB)

wlan0       Link encap:Ethernet  HWaddr 55:44:33:22:11:00
            UP BROADCAST MULTICAST  MTU:1500  Metric:1
            RX packets:12 errors:0 dropped:0 overruns:0 frame:0
            TX packets:194 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:1442 (1.4 KB)  TX bytes:25177 (25.1 KB)

If eth0 is not available, type "ifconfig eth0 up".

You can now add an address to your eth0 interface by typing "ip -6 route add __your_address__ dev eth0". By doing so, you have the address you wanted on the eth0 interface.

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:55
          inet6 addr: fdbf:e793:18b3::1/128 Scope:Global
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Babel can now be used.

    2. Compile programs

Before doing the following, you should compile zebra and babel. First, run "./configure --enable-vtysh" in the main directory "quagga", (we will talk about the vtysh option later on), then go in their respective folders ("quagga/babel" and "quagga/zebra") and run "make".

    3. Launch Zebra

You have to launch Zebra and Babel in two separate terminals. To run Zebra, go in the right directory, and type "./zebra". It is a silent program, so there should be very little outputs.

    4. Launch Babel

To run Babel, go in the babel folder and run "./babel". This one is more wordy. It will tell everything that is happening on the babel network, but because you don't yet have any Babel networks running, it should stay silent.

    5. Add Routes

To add routes, you will use the vtysh program we talked about earlier. Go in the folder "vtysh" and run vtysh. Here you can type commands to add routes. Vtysh is an interactive shell where you can type commands to interact with your router. To have a full list of the command, just hit the "?" button. The first command you want to use is "show ipv6 route", to bring all the current routes. You can then enter configuration by typing "configure terminal". If you want more information, you can type "?" anytime and see all you can do.

    6. Add Source-Sensitive routes

You can add source-specific routes as well, type "help" in vtysh for more information.

    7. A concrete example

Here is a simple example of a network where source-specific routing is useful:
                                 |--------N3--(
N1---------N2---------|                  (
                                 |--------N4--(


Here, N3 and N4 are two gateways to the Internet. N1 would like to use N3 or N4 to reach a website. Here is the RIB of N1 and N2 :

N1
-----
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, A - Babel,
> - selected route, * - FIB route

A>* ::/0 from 2001:660:3301:9208::/64 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:34:51
A>* ::/0 from 2001:660:3301:9209::/64 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:09:56
C>* ::1/128 is directly connected, lo
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8d32/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:49
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8d3b/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8d3f/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8db3/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:5c0:1505:6b00:a021:b7ff:feba:df57/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:5c0:1505:6b00:e246:9aff:fe4e:91e2/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:03:45
A>* 2001:660:3301:9202::ac17:248a/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:660:3301:9208::1de/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:22:03
C>* 2001:660:3301:9208::2de/128 is directly connected, eth0
A>* 2001:660:3301:9208:b6b5:2fff:feb8:35c3/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:660:3301:9208:e091:f5ff:fecc:7a93/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:660:3301:9208:e246:9aff:fe4e:912e/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:660:3301:9209::1de/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:08:55
C>* 2001:660:3301:9209::2de/128 is directly connected, eth0
A>* 2001:660:3301:9209:e246:9aff:fe4e:912e/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:31:06
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8d32/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:49
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8d3b/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8d3f/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8db3/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:a021:b7ff:feba:df57/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:e091:f5ff:fecc:7a93/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:e246:9aff:fe4e:912e/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:e246:9aff:fe4e:91e2/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:03:45
A>* 2001:41d0:1:f19f:e291:f5ff:fecc:7a00/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
A>* 2001:41d0:1:f19f:e291:f5ff:fecc:7abd/128 [95/0] via fe80::868f:69ff:fef0:338e, eth0, 00:44:53
C>* fe80::/64 is directly connected, eth0
-----

N2
-----
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, A - Babel,
> - selected route, * - FIB route

A>* ::/0 from 2001:660:3301:9208::/64 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:46:52
K>* ::/0 from 2001:660:3301:9209::/64 via fe80::e291:f5ff:fecc:7a93, wlan0
C>* ::1/128 is directly connected, lo
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8d32/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8d3b/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8d3f/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:5c0:1505:6b00:21b:b1ff:fe83:8db3/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:5c0:1505:6b00:a021:b7ff:feba:df57/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:5c0:1505:6b00:e246:9aff:fe4e:91e2/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:08:09
A>* 2001:660:3301:9202::ac17:248a/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
C * 2001:660:3301:9208::1de/128 is directly connected, eth0
C * 2001:660:3301:9208::1de/128 is directly connected, wlan1
C>* 2001:660:3301:9208::1de/128 is directly connected, wlan0
A>* 2001:660:3301:9208::2de/128 [95/0] via fe80::222:15ff:fe80:d0da, eth0, 00:07:25
A>* 2001:660:3301:9208:b6b5:2fff:feb8:35c3/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:660:3301:9208:e091:f5ff:fecc:7a93/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:660:3301:9208:e246:9aff:fe4e:912e/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
C>* 2001:660:3301:9209::1de/128 is directly connected, wlan0
A>* 2001:660:3301:9209::2de/128 [95/0] via fe80::222:15ff:fe80:d0da, eth0, 00:07:25
A>* 2001:660:3301:9209:e246:9aff:fe4e:912e/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:43:06
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8d32/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8d3b/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8d3f/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:21b:b1ff:fe83:8db3/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:a021:b7ff:feba:df57/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:e091:f5ff:fecc:7a93/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:e246:9aff:fe4e:912e/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:e246:9aff:fe4e:91e2/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:08:09
A>* 2001:41d0:1:f19f:e291:f5ff:fecc:7a00/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
A>* 2001:41d0:1:f19f:e291:f5ff:fecc:7abd/128 [95/0] via fe80::e246:9aff:fe4e:912e, wlan1, 00:56:53
C * fe80::/64 is directly connected, wlan1
C * fe80::/64 is directly connected, wlan0
C>* fe80::/64 is directly connected, eth0
-----

In this example, N1 has two addresses A1 (2001:XXX:XXXX:9208::2de) and A2 2001:XXX:XXXX:9208::2de), it can send packets and choose A1 or A2 as source. All the packets will go to N2, which will forward them. But N2 implements source-specific routing and even if two packets have the same destination, it will read their source and send them to different locations. In our example, it is N3 and N4. Once on the Internet, these packets behave identically to any other packet. This is due to the fact that the source is not handled by routers not implementing source-specific routing. Here are the traces of the packets with two different sources :

traces :
---------
ping6 2001:4860:4860::2de -I 2001:XXX:XXXX:9208::2de

My traceroute  [v0.82]
computer (::)                                                                                  Mon Aug 18 18:55:27 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 2001:XXX:XXXX:9208::1de                                  0.0%    62    0.8   1.0   0.6   2.7   0.5
2. 2001:XXX:XXXX:9208:e246:9aff:fe4e:912e           0.0%    62    3.1   3.7   2.3  14.5   1.9
3. 2001:XXX:XXXX:9202::ac17:2ffe                         0.0%    62    3.0   3.9   2.4  21.2   2.6
4. 2001:XXX:XXXX:80fc::4                                      0.0%    62    2.8   4.4   2.7  12.5   2.0
5. 2001:660:2401:2001::1                                             0.0%    62    4.8   6.2   2.9  32.3   5.5
6. 2001:660:3300:1004:0:82:0:2200                               3.2%    62    4.0   4.4   3.0   8.3   1.5
7. 2001:660:7903:124:1::1                                            8.1%    62    9.2  11.9   6.0  70.5  11.9
8. 2001:660:7903:2:2::2                                               4.8%    62   12.9  12.1   9.5  18.7   1.4
9. 2001:660:7903:159:1::1                                            0.0%    62   16.0  17.1  14.1  35.8   3.4
10. ???

ping6 2001:4860:4860::2de -I 2001:XXX:XXXX:9209::2de

My traceroute  [v0.82]
computer (::)                                                                                  Mon Aug 18 18:56:07 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 2001:XXX:XXXX:9208::1de                                   0.0%     5    0.8   1.3   0.8   2.6   0.7
2. 2001:XXX:XXXX:9208:e091:f5ff:fecc:7a93             0.0%     5    3.1   3.1   3.0   3.2   0.1
3. 2001:XXX:XXXX:9208:e246:9aff:fe4e:912e             0.0%     5    3.0   3.6   3.0   4.6   0.8
4. 2001:XXX:XXXX:9202::ac17:2ffe                           0.0%     5    4.7   5.0   3.8   6.1   0.9
5. 2001:XXX:XXXX:80fc::4                                        0.0%     4    6.2   9.2   3.1  23.9   9.9
6. 2001:660:2401:2001::1                                               0.0%     4    5.6   4.2   3.1   5.6   1.3
7. 2001:660:3300:1004:0:82:0:2200                                 0.0%     4    6.6   5.4   3.4   6.6   1.4
8. 2001:660:7903:124:1::1                                              0.0%     4   96.7  30.4   7.5  96.7  44.2
9. 2001:660:7903:2:2::2                                                  0.0%     4   11.8  20.3  11.6  45.9  17.0
10. 2001:660:7903:159:1::1                                             0.0%     4   18.0  23.5  15.8  30.2   7.6
11. ???
---------
The important thing to notice here is that the two traces don't use the same first router. After that, the routes are quite alike because routers quickly get the packets on the external network and they are then treated as normal packets.

You can find my branch of the Quagga project here: https://github.com/OFabre/ss-babel
And as our web server at university got shut down recently, I moved my blog here: http://ofabre.github.io/

I really appreciated working on networking and I will try my best to continue my work in the Quagga project.

Pages

Subscribe to The Next Layer  aggregator - Free Network News