Wednesday, June 3, 2015

Why are we going to 2.0 ? Third post

I have another cookie to share with you about the advantages that are coming with the rewrite of a second version of Netsukuku.
The modularization work has brought the code to a point where the critical sections about multithreading have been refactored. Without going through too deep details, this has to do with the fact that Netsukuku code makes use of lightweight collaborative threads (also known as microthreads or tasklets).

The old implementation in python was using Stackless Python for this. The new one in Vala is using GNU Pth.

The good news is that this modularization work is going to make it easy to plug in another implementation of a "tasklet" system.

This is good because GNU Pth poses some problems. For instance it is common in a glibc-based operating system, such as most Linux distributions. But it has problems with a uClibc-based system, such as default builds of OpenWRT. Furthermore it's not on Windows.

Hence, next version of Netsukuku will be more easy to port to Windows.

Tuesday, April 14, 2015

Why are we going to 2.0 ? Second post


Modularity is another reason for the rewriting of Netsukuku.

The software is being structured in modules, with the aim that each module will be able to operate independently from the others and has no knowledge of the others.

This modularity has advantages. The implementation of simulated network environments will be possible, that will prove the correctness of each aspect of the whole system, putting apart the other ones.

For an example of that, let me introduce the Neighborhood module. This module is responsible for the detection of nearby nodes through a number of NICs. Furthermore, it has the duty to periodically measure the "cost" of the link to a neighbor, expressed as the latency of a message through it. Finally it has to detect when a link becomes unusable.

This module has been already well documented and an implementation has been completed. Then, a testbed has been prepared (both a simulated and a real-world one) that allowed me to verify the behaviour of just this aspect.

The tests have highlighted a couple of problems with the mechanisms of the old implementation, which were an issue in particular when a network segment was under load. And allowed me to explore some adjustments and finally find a good solution.

Status report

There are two other modules that have been documented and for which I feel that the current approach is the final one. The coding phase is going on for them. They are the Qspn and the Peer-Services.

The Qspn module is responsible for the exploration of the network in order to give to each node its knowledge base of the network graph.

The Peer-Services module lays the basis for the creation of peer-to-peer services.

Then, some more aspects of the system have to be addressed. I don't want to bore you with details. A complete release will be ready, I hope, before winter.

Tuesday, March 31, 2015

Why are we going to 2.0 ? First post in a series...

An important reason for the rewriting of Netsukuku 2.0 is the fact that a good documentation is being written, at the same time, for each software module.

There is an overview of the problem that the module addresses and how it is solved.  The problem is described as a whole, but at the same time in a precise and detailed manner.  Also, the role of this module in the solution of that problem is described in details.

Then, the algorithm is described that implements the role of the module. The algorithm is described in great details when it is the case, although using a "pseudo code" language. To the point that it would not be difficult for a developer to follow the steps and write the code in his favourite programming language.

Not all the modules, that will make up the full app, have been described yet. However, if one has already read the old Netsukuku documents written by Alpt and companions, he could easily guess which modules are yet to be described and how they should be integrated in the whole.

There is a problem with this documentation, that is it is written in my mother tongue: Italian. Since it is a work constantly in progress, I'm not going to translate it into English soon. Do not hold your breath.

At this link you can see the most recent draft of the documentation:

Monday, December 22, 2014

Merry Christmas

Merry Christmas to everybody.

Work is in progress towards Netsukuku 2.0.
More efficient, more stable, new features. Stay tuned.

Thursday, August 7, 2014

1.0 released

I released version 1.0 of Netsukuku.
WARNING. This is NOT a product ready for use by the masses.

At this page I wrote some notes so that you know what you can and cannot expect from this release.

I've put the tarballs again at:

Instructions for ubuntu and openwrt have their pages:

Wednesday, June 4, 2014

New release. Enjoy the net also from unmodified devices.

I just released a new version of netsukuku (0.9.1) that fixes a major bug. In version 0.9 the dns-to-andna redirector was working perfectly on a PC with Ubuntu, but it did not work at all on a router with OpenWrt.

I take advantage of this new release to try and see what are the necessary steps to deploy a router in the following scenario.
Those who follow my blog know that in my house, I prepared a simple cabling. There is a room in which a number of cables arrive. Among these, one comes from the roof (where my WISP provider has installed an antenna of their property), one comes from the garage (where I have placed a server) and one comes from the living-room.
In that room is a simple non-configurable hub where all the cables are attached.
I have a router that has a wireless interface and an internal configurable switch which is usually configured to have one WAN port and four LAN ports. A classic tp-link 1043 to be exact. I want to put this router in the living-room to be able to connect with several devices to the Internet.
Let's see how to configure this router to meet these needs and start building at the same time a Netsukuku network.

First, I have built the OpenWrt firmware according to the instructions linked in my previous post. I also included the package for the web commands interface (luci). I flashed the router with the firmware.

I connected one of the LAN ports of the router to the network port of my PC, logged in via web interface to the default URL for a fresh install of OpenWrt ( and set a password for root.

As a first modification, since the device of my WISP uses the address of, I set the LAN interface address of the router to
I changed that input field.

Once that I applied the setting, I had to redo the connection of the network interface on my PC and direct the browser to the new URL (

Then, I enabled the Wifi interface.
Click "Edit"...
I used 'ntkd' as my SSID and a password that you could guess.
The second change that I want to make is about the bridge that is enabled by default in the installation of OpenWrt between the wifi interface and the ports marked as LAN.
For now, I do not foresee to connect any other device to the LAN ports of this router. But even if this were to happen in the future, I want to give to Netsukuku the duty to route the packets received via wifi to the local wired network when necessary. So I want to remove this bridge.

We can see through the OpenWrt web interface how the bridge is made.
To start, the switch inside the device is configured to use the protocol VLAN. The VLAN 2 is composed of just the port 0 of the switch (marked as WAN port in the case). VLAN 1 is composed of the other 4 ports (marked as 1 .. 4 in the case). Both the packets that belong to one VLAN or the other will get to the router's CPU and they'll be "tagged".
Here no changes are needed
So the bridge between the LAN ports and the WiFi is actually a bridge between the eth0.1 interface and the wireless interface, as seen in the "physical settings" page shown below. The name "eth0.1" does not indicate a port other than eth0, rather it is a notation used by Linux to indicate a VLAN. As if we say to the CPU: "packets read and written in the eth0 interface are formatted according to the protocol VLAN; grab only those that belong to VLAN 1."
Interface LAN with bridge enabled
In the "physical settings" page I disable the bridge and I select only the interface "eth0.1".
Interface LAN without bridge
At this point the wireless physical interface is not associated to any logical interface. I create a new logical interface named WIFI.
Click "Add new interface"...
Name "WIFI", protocol static, interface wireless, then click "Submit"...
Set address and netmask 24 bits, then below...
click to enable a DHCP server, finally remember to click "Save and apply."

Now the router has 3 logical interfaces: LAN, WIFI and WAN. I did not make any changes to the WAN interface, which has protocol DHCP and is associated to the physical interface eth0.2 as shown below.
The WAN interface is made ​​up of the physical interface eth0.2

Now I make two changes to the configuration of the firewall included in OpenWrt.
First, optional, I include the new interface WIFI in the "lan" zone of the firewall. 

Firewall, zones, “lan” edit...

Select interface WIFI and click “save and apply”
For the second, crucial, I add some rules to the firewall to prevent it from blocking important packets.
With the first rule I tell him to accept incoming packets from the "wan" zone destined for port 269 (both TCP and UDP) on the router itself. These packets implement the routing protocol of Netsukuku. I named this rule "Allow-netsukuku."
With the second rule I tell him to accept forwarding any packet to or from any zone if the addresses of the source and destination are in the class IPv4 That is, I allow network traffic to pass through me. I named this rule "Allow-netsukuku-traffic."
These rules are necessary if other Netsukuku nodes (eg my server in the garage) must be connected to the WAN port of the router.
Use these input fields to create a rule for incoming packets.
Use these ones to create a rule for passing-through packets.

The two rules should appear in the list as shown above. You may need to reboot the router to see the rules in the list.

At this point I was pretty happy with the setup, it seemed a good time to save a backup.
The backup archive which can be generated from the OpenWrt web interface is composed of a series of system configuration files that reside in /etc. By watching those files one can understand how to get the same results even when a firmware doesn't includ the package of the web interface (luci).

Then I turned off the router and I placed it in its final position in the living-room. I connected the router's WAN port to the network wire that reaches the hub. I then connected my PC to the wireless network 'ntkd' and I checked to be able to surf the Internet.
The wireless interface of my PC has obtained an address in the subnet, as expected. I can connect wirelessly to the router at with both the web interface and with SSH. And I can surf the Internet.

I logged in to the router via SSH and I followed the instructions linked in my previous post. That is, I modified configuration files (nsswitch.conf, dnsmasq.conf, ...) and I restarted the services dnsmasq and dns-to-andna.
Finally I started the daemon ntkd and I told him to listen on interfaces wlan0 and eth0.2.
root@OpenWrt:~# ntkd -i wlan0 -i eth0.2

In my Ubuntu server (whose hostname is nodo07) ntkd was already up and I had installed a web server.
So I connected my Android phone with the wireless network 'ntkd'. With the browser of the phone I am able to visit the website of my server and navigate on the Internet websites, such as Wikipedia. Then I repeated the same test with the same results, as expected, from a Windows laptop.

Sunday, May 4, 2014

Netsukuku Beta

I released the first beta version of Netsukuku.

The suite of programs and libraries is composed of 6 packages. The tarballs can
be downloaded from the following links.

Instructions to download, build and install on a ubuntu machine are located here:

It is possible to install and run also in a router running OpenWRT.
Instructions are provided that guide you to the compilation and flashing of a
fresh new firmware with the programs and libraries already installed.

Maybe, a new web site will come up soon.

My next step will be wait for your feedback. Report bugs, request details on
documentation, ask for inclusion of features and the like. All of this please
send to netsukuku-vala at nongnu dot org.

The first final version of Netsukuku (1.0) will be released on August 1st.
During this time I will add features. When bugs are reported I will try and
fix them and release as soon as possible, e.g. version 0.9.1.