Year: 2014

GSoC: Features of the Retroshare social network plugin

Posted on by Tillmann Gansky

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.

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

Posted on by Eloi Carbó Solé

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:

Bird BGP LuCI configuration example

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

Posted on by Olden Fabre

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.

Einladung zum Freien Freifunktreffen in Halle am 19.07.2014 (Sommerfest)

Posted on by Matthias Fuhrmeister

Wie jedes Jahr, trifft sich auch dieses Jahr die hallesche Freifunk-Community im Sommer am Hufeisensee. Es ist ein regionales Treffen, welches offen für alle Freifunk-Communitys ist. Hiermit möchten wir euch einladen am 19.07.2014 vorbei zu schauen.

Diesmal sind wir zu Gast auf dem Vereinsgelände vom Tauchclub Orca in der Schkeuditzer Str. 70 | 06116 Halle, wo wir uns ab 15 Uhr treffen. Das Gelände bietet alles, was Freifunker für ein produktives Treffen benötigen: Freifunk, Internet, Strom und Grill sind genauso vorhanden, wie Tische und Stühle um eigene Rechentechnik aufzubauen. Die Freifunk Community aus Halle will dieses Treffen nutzen, um einen eigenen Förderverein zu gründen. Der Förderverein soll die Aufgabe übernehmen, das Projekt Freifunk in Halle organisatorisch zu unterstützen. Weitere Informationen gibt es im Freifunk.net-Wiki. Fragen und Anregungen können auch bei uns im Forum diskutiert werden. Gäste werden gebeten, sich anzumelden, um besser planen zu können.

 

API in Progress

Posted on by Andreas Bräu

Die API-Entwickler haben einen großen Sprint eingelegt und viele Neuerungen implementiert. Das größte Ziel neben der Verbesserung der Nutzerfreundlichkeit war die Schaffung höherer Datenqualität. Dafür wurden einige Freitextfelder in Checkboxen umgewandelt und bestehende Auswahlfelder um weitere Optionen ergänzt. Textfelder, für die ein definiertes Format bekannt ist (z.B. Emailadressen oder URLs) prüfen wir bei der Validierung gegen Pattern.

Die wichtigsten Änderungen im Überblick:

  • neue Felder für Fokussierung, politische und technische Aspekte, z.B. Umgang mit Störerhaftung oder Updatemodus
  • Kategorie ‘podcast’ zu Feeds hinzugefügt
  • Länderfeld mit Auswahl und Speicherung von ISO-Codes
  • Top Level Domains in DNS umbenannt und für mehrere Domains geeignet
  • jede Community kann mehrere Routingprotokolle haben
  • Arten von Kartenlösungen erweitert
  • Formate und Beschreibungen hinter Feldern ergänzt, damit beim Ausfüllen mehr Klarheit über die erwarteten Daten herrscht
  • Doppelte oder überflüssige Felder entfernt (z.B. topology data, bootstrap, “needs to be defined”)

Durch die Umwandlung einiger Freitextfelder in eine Mehrfachauswahl müssen die betroffenen Felder neu belegt werden. Der API-Generator in seiner aktuellen Version weist auf diese Felder hin.

Auch in anderen Bereichen gibt es Fortschritte. Durch die Erweiterung der Feeds um Podcasts bietet freifunk.net nun auch einen aggregierten Podcastfeed aus den Podcasts der Communities an.

Weitere Entwicklungen gibt es auch beim Kalender: Ein WordPressplugin ermöglicht es nun, die einzelnen Kalender der Communities zu einem großen Gesamtkalender zusammenzufassen.

Ihr seht, es gibt mehr als genug Gründe, eure API-Files zu aktualisieren und anzupassen. Falls ihr Daten wie z.B. Anzahl der aktiven Knoten oder in eurem Netzwerk angekünigte Dienste regelmäßig erneuert, schreibt sie bitte auch in eure API-Dateien. Freifunk Mainz hat dazu ein einfach handhabbares Werkzeug entwickelt.

In Zukunft soll es auch Visualisierungen und Suchmöglichkeiten über die API-Daten geben. Teile davon wollen wir zum Freifunk Hackathon vom 1.8. bis 3.8.2014 in Berlin besprechen und umsetzen. Auf dem Hackathon soll es um die Weiterentwicklung von Freifunkfirmwares gehen, es wird also sehr interessant und ihr seid herzlich dazu eingeladen.

Neue Webseite, neue Firmware, neue Neuigkeiten aus Bielefeld

Posted on by mwarning

Unsere kleine Community in Bielefeld wächst zur Zeit ruhig aber stetig. Jetzt wurde unsere Webseite komplett erneuert und unsere Mailingliste ist auch endlich von googlegroups umgezogen, nachdem immer mehr Leute gemeldet haben das ihr Emails nicht ankommen würden – wer da böses denkt. 😉

Auch ist eine neue Firmware verfügbar (0.3), die nicht nur stabiler läuft sondern auch viele neue Router unterstützt. An dieser Stelle einen Dank an das Gluon-Projekt für einige Pakete und Patches die wir übernehmen konnten (autoupdater / traffic control). Für einige Modelle mussten wir aber aber auf eine noch experimentelle OpenWrt Version zurückgreifen (Barrier Breaker). Aber es funkt! 😀

Heute gab es auch einen Vortrag zum Thema Freifunk im Rahmen der Netzwoche in der Universität Bielefeld. Vielleicht wurde die eine oder andere Person dazu inspiriert einen Router aufzustellen oder aktiv mitzumachen. Die Folien sollen bald veröffentlich werden, so dass auch andere sie nutzen können.

Viele Grüße,

Freifunk Bielefeld

GSoC: Netengine project

Posted on by Alessandro Bucciarelli

Here it is my second blog post for the Mid Term Evaluation of GSOC2014.

As I wrote in the previous one, I’m working on Netengine, a Python module to abstract network devices and get information from them.

The work is going very well, I’m learning new things every day with the help of my mentor, Federico Capoano, and I’m very happy with the development.

In this first part of the work we completed as per goals, the SNMP back-end for AirOS and OpenWRT firmwares.

The most difficult part of this first part was to work with SNMP (Simple Network Management Protocol) because I had never worked with it, so I had to learn it’s basics and how it works, in particular it’s way of retrieving info from devices.

It uses different codes (MIB), everyone of it gives access to different information of the device (e.g device name, addresses, interfaces); so before starting to write I had to look for the correct MIBs to query.

Now we are focusing on the ssh.OpenWRT back-end ready to switch the next one on the list once completed.

I’m definitely very happy with how the work is going, with the communications I’m having with my mentor and with all coding practices I’m learning from him.

The program gave me not only the possibility to improve my skills but also to meet new people very experienced on the field.

The next step is to start coding on the new back-end, probably an HTTP back-end for AirOS, to complete the program in time.

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

GSoC: Freifunk API Query Client meets DeepaMehta

Posted on by Martin Tippmann

This post will give an overview about the ongoing work on the API query client GSoC project. As I’ve wrote a few days ago I met Jürgen Neumann at the WCW 2014 and he introduced me to DeepaMehta. We decided to use this tool as a database for the API data. This approach is quite a leap from my original proposal and idea but after a few discussions we realized there are a lot of benefits to this approach. Here I want to give a short overview about this new approach.

What is DeepaMehta?

DeepaMehta represents information contexts as a network of relationships. This graphical representation exploits the cognitive benefits of mind maps and concept maps. Visual maps — in DeepaMehta called Topic Maps — support the user’s process of thinking, learning, remembering and generating ideas. We think that working with DeepaMehta stimulates creativity and increases productivity. – Welcome to DeepaMehta

This sounds interesting but one may ask where is the connection to community data in machine readable form? The answer is in the data model. Here is an example from the website:

The data is organised in a topic map. There are topics that can represent e.g an organisation or a person or an event. These topics are associated through a hypergraph relationship. This means that it is possible to model all kinds of possible relationships between topics. For example a person can be modelled as a topic, that is associated with an address and the adress consists of location data, email adresses and so on… this person can be part of several organisations and these organisations can be aggrated by several parent organisations and so on…

We have a powerful graph to represent all kinds of information and we know about the relationships of each information-bit to other bits…

We have a graph that we can traverse for queries. It’s straight forward to e.g. list all organisations, that a person is a member of.

To take an example from the API data: We want to know which communities use “olsr” as their routing protocol . This would be an instance of the topic type “routing protocol”. We now only need to follow the links to all instances of the type e.g. “freifunk-community” that are connected to the “oslr” instance of the “routing protocol” topic.

This would allow for flexible queries. Another example would be a map where all instances of location topics are displayed and their parent-topics are included as label for the points on the map. If e.g. node data is present for communities this would allow for a global node map that shows not only node locoations but also community event locations and meeting places. Of course there is a huge amount work do before this will be working but overall I hope this explains why there are a lot of benefits for using this representation.

Freifunk API data in DeepaMehta

So how will it work? I’ve tried to put it in a diagram:

More details:

Data

At the moment there is a specification – a JSON schema file – for the API data and an instance – a JSON API file.

Magic

Magic is probably the wrong word for that, but all the hard work is done by DeepaMehta and I only build a plugin on top of that – unaware of the implementation details – so I thought it is appropriate. To quote Arthur C. Clarke: Any sufficiently advanced technology is indistinguishable from magic

At first, we need to put the schema into the DeepaMehta platform. This is possible using a plugin that creates the topics in DeepaMehta for the entries in the JSON schema.

The next step is to feed the current data into DeepaMehta. This creates instances of the previously defined topic types. E.g. a topic for each community.

Once the data is in DeepaMetha it’s possible to query that data.

Presentation

We can now speak JSON over HTTP using REST with the platform and present the results in various ways. E.g. display communities in a map or provide an text interface to query the data. DeepaMehta already provides an REST API and a web-based interface for exploring and editing topic maps but while testing and playing with the interface we found it too complicated.

Current Progress

Feeding the data by hand into the plattform is not practical and I’m working on an import script for the schema and the API data. At the moment mapping the basic JSON types (string, integer, ..) into DeepaMehta is working but more works need to be done to get a better representation. Once the data is in the focus will shift on a doing actual queries.

Problems

Complexity. These are for the most part new concepts for me and I had little prior experience with semantic web technologies. DeepaMehta also covers quite a few other usecase and I need to learn more about the system.

Open Questions

Doing the actualy queries and traversing the graph is something I need to find a workable solution for. There are also different specifications of the API schema and different communities use different versions of the API. At the moment I’m ignoring that detail but here I need to find a solution. Another nice to have feature would be access to historic data. 

Lots of interesting problems.. unfortunatly I’ve been short on time in the past days and I’m quite behind the shedule but I’m optimistic that this approach is flexible enough to provide a solid ground all kinds of experiments with data. Once queries are possible things will hopefully move forward at a faster and more visible pace.

GSoC “BGP/Bird integration with OpenWRT and QMP” project report

Posted on by Eloi Carbó Solé
This entry is for updating the information regarding this GSoC Project focused on the automate of BGP-BMX6 metrics and routes exchange and “translation”. 
 
During the WBMv7 in Leipzig, the WiBed platform [0] was presentated as well as the GSoC project[1] where I am participating. WiBed was used to deploy the testbed network where many routing and mesh related experiments were executed.
I was participating in the deployment and development teams of the WBMv7, so I contributed in many bug fixes and platform improvements.
The WiBed project is important for the GSOC because it provides a testing platform very similar to the production environment where we will apply the results of the GSOC project.
 
Currently I am studying and understanding the basis system we need to accomplish the objectives of my project. I am working on Bird4 and Bird6 [2] configuration transition to UCI[3] and LUCI[4] willing to give to the OpenWRT project and community a more user-friendly Bird Daemon configuration. For those who do not know, Bird is a lightweight and flexible BGP daemon which may be used as an alternative to Quagga (which is actually very heavy).
 
Once we got an usable version, we wll upload the work done to public GIT repository following the standard OpenWRT feeds format (so it might be included in the official repositories). To test our advances and implementation we are using the WiBed platform network deployed in our laboratory (at UPC university in Barcelona).
The first production test will be made in the QMP [5] network we have deployed in Barcelona.
 
The most challenging feature in our project is the exchange of routes (and associatd metrics) between routing protocols (BGP and BMX6 [6] in our case). We (me, the workgroup and mentors) are still discussing about the different ways to implement it and how to use the Bird solution to Guifi.net [7] where the main protocol is BGP and the most common OS is the privative routerOS from Mikrotik. Including Bird in the open/libre firmware QMP will allow people in Guifi.net to use this solution instead of routerOS. However to make the interconnections between the QMP (Mesh) networks and the current BGP/Infrastructure we need the called frontier (or border) nodes (those who exchange the routes between both network clouds). 
 
To not overload the current mesh clouds (running with BMX6), we will install a BGP Bird instance only in these QMP border nodes. They will exchange routes and metrics in the entrance of the network and summarize the result by publishing the aggregated routes to each network.
 
Another idea we are considering is to create a very small and simple OpenWRT image with the BMX6 daemon ready to perform the routing. This image may be installed as a virtual machine in the RouterOS firmware (present in 50-60% of the Guifi.net nodes). So Mikrotik nodes will be able to route BMX6 packets thus the BGP instance will not be longer necessary (we believe mesh routing protocols are a much better option than BGP/OSPF for a WiFi network). This approach is compatible with the (previous) border nodes one. We will provide both options to Guifi.net users to let them decide.
 
Finally, to conclude this  mid-term report, say that we expect to finish the project in time and  just mention that in the coming days we will start testing the first solution in a real production network.
 

GSoC: Freifunk API Query Client – A short report from the Wireless Community Weekend 2014

Posted on by Martin Tippmann

Photo taken from https://twitter.com/christianheise/status/472746947569520641

Photo taken from https://twitter.com/christianheise/status/472746947569520641

From the 29th May to the 1st of June we were with Andi and Bernd from Weimarnetz at the wunderful c-base Raumstation. We visited the Wireless Community Weekend. It was my first experience of this kind of community event and I enjoyed it very much.

Beer and Bratwurst did harmonize quite well with technical talks about OpenWrt and the Freifunk Community. I was especially surprised how diverse and open the community is and how enthusiastic everyone involved was.

Andi and Monic talked about the progress on the Freifunk API and presented their work. At the end of their talk I had the chance to present my work on the query client for the API. Here are the slides.

Shortly after the talk Jürgen Neumann from Freifunk Berlin came to me and introduced me to DeepaMehta. My original plan was to use something like NodeJS for the backend the storage of the API data but DeepaMehta looked promising and offers unique features I didn’t even thought off.

So after talking with Andi about it we decided to use DeepaMehta as the foundation and storage tool for the API data. A seperate blogpost for the GSoC midterm evaluation will outline my work in this direction.

Overall it was a very exciting weekend for me at #ffwcw 2014.