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.

Monday, April 14, 2014

The global recession

At the moment I am without a job, mostly due to the global recession that hit also my previous employer.
If you want to give credit to my efforts in this project, your donation will help me to bring home the bacon.

So, let me remind you that I am accepting donations through bitcoin. See the link on the right side.

I will not provide another method for supporting me with donations.
You do not own a bitcoin wallet yet? Well, you definitely should.

Thanks for any contribution.

Wednesday, March 5, 2014

Status Report

The porting of Netsukuku to Vala has been completed.

Almost! The DNS wrapper is still missing. It is a piece of code that listens to standard DNS queries and forward them to the ANDNA system. But there are tools that can query directly ANDNA.

Also, the Internet Sharing is still missing. Consider also that in the python implementation this feature was rough and poorly tested yet.

So, yes, I consider the porting really complete.

Obviously the code has to be tested, debugged, fixed, tested again, etc etc.

The daemon is misbehaving in a number of ways.
There are a number of testsuites here and there for various parts of the operations but they are not exhaustive at all. So it was really expected.

Finally I want also to introduce a tool that I made to help the debugging by providing a view of some of the status informations that can be queried to the nodes.

This node has two direct neighbours.
Look, these are the IDs of gnodes and of the entire network.
Behold! All the known destinations, and for each the entire path!
Look ma': I am the Coordinator!
Some ANDNA records.

Monday, February 24, 2014

Participation rewards

Recently I read about a fresh new project that shares with netsukuku a lot of principles.
This project aims to create a mesh-network where the collaboration of the nodes is rewarded with a crypto-currency. This currency is then used as a payment for sending ones own trafic over the network.
Francois Zard, the ideator, contacted me before going public, asking for clarifications on the status of our project.
I wish him and his project to grow up well.

His idea made me think about the possibility to exploit the features of netsukuku network protocol in order to have a similar rewarding scheme. After a few days I came out with a rough idea that I share with you.

The rewarding mechanism

A new feature of Netsukuku will allow the participants to give a reward in money to the owners of the nodes that permit them to reach their favourites contacts and services.
This is on a completely voluntary basis. The network remains free of charge for everybody.

There are many projects today that have the goal of building a self-sustaining network where participants are incentivised to improve the network. The key point in all of them is to reward not just the provider of a service, but the owner of the nodes that make it  possible in the first place the connection between client and server.
Many of the proposed payment schemes try to reproduce how the bitcoin transactions work, but with a new digital crypto-currency.

Netsukuku will take no effort to create a new currency, and not even be tied to the best payment solution that we could find. It will just make it possible for a node owner to reward the right people. More precisely, the owners of the nodes that are in a precise instant connecting him to his favourite friends.

Netsukuku will not, of course, expose their identity, but only a payment address that is at their disposition.

The actual payment processor can be anything that has the required properties. There can be at the same time more than one.

A first implementation of this will use Bitcoins, the real thing. With most probability it will use Coinbase services, because it is good for us to have a practical way of enabling micro-payments with no fees and with low delay confirmations.

At the moment I figured out 2 types of payment procedures. One is initiated by the client at his will. One is required by a service provider.

Client-initiated procedure

A node owner, say A, uses frequently a certain service hosted on the node of another participant, say B. Or she speaks with B owner via a VoIP application that contacts directly the node B.
Supposedly, A might be willing to donate, every now and then, some money to the nodes that make her communications possible. Because she wants them to keep on running their nodes and possibly improve their links.
Node A will send a particular message to node B; this will trace the nodes that make up the best route right now, and obtain from them a Bitcoin address (or other payment address, but for now we refer to this). Node B responds to A with the list of addresses and A can make the payment.
Obviously A can make this donation whenever she likes and for the amount she likes. A good strategy for A would be to make frequent micro-donations during the very same hours when she uses the most the service that she cares.

Service-required procedure

The owner of node S (S=server) provides a service to his customers. He wants to get paid for this service based on the volume of trafic that is used.
S might be willing to share (a part of) his income with the nodes that form the link from his server to his customer. Because he wants to incentivise them to stay and new nodes to arise for him to be reachable by a broader mass of potential customers. Hence, S advertises that he is providing a service through this channel with this feature.
A client C sends a particular message to S; this will trace the nodes that make up the best route right now, and obtain from them a Bitcoin address. Node S will append its own Bitcoin address and respond to A with the list of addresses and the amount of payments that he has to do to each of the addresses per unit of trafic. Furthermore, the nodes that form the link will be notified of the IP address of C and S and the amount that they are going to receive per unit of trafic. These hops might then verify every now and then the payments and (if they want) temporarily block the trafic on this flow if they don't receive the payment.
A consideration: C could "cheat" and not make the payment to the hops, because he thinks that they will not check. But for sure he will not be able to cheat S, because he will verify, of course, and deny the service. So S, if he really wants to reward and incentivise the hops, could ask for a slight bigger price for his service and then take care on his own to donate back to the bitcoin addresses that he receives with the message from the client C.


What has been briefly exposed until now is plausibly feasible with any payment processor that possesses some properties.
Now let's take the assumption that the Bitcoin network is used.
Here are some considerations about the problems that arise with this choice.

First, not all the nodes are required to participate to the service.
But only those who participate can be rewarded or initiate a payment.

When a node participate to the service, the only requirement is to be configured with a Bitcoin address where he can receive payments. It is advised to generate a new valid address for each payment, if the node is able to do it; but it is not mandatory.

If a node wants to be able to check the payments then he needs to get connected to the bitcoin network. Or at least to get connected from time to time to the Internet and use some host which provides informations, such as This requirement is not particularly hard to satisfy. For example it's enough if the owner of the node has got also a computer which is connected to both the netsukuku network and to the Internet.

If a node has trouble to get to the Internet but wants to participate he can do. It will not be able to check the payments, so it shall never block the trafic. Nevertheless it will probably receive payments, because when the network is highly dynamic it's hard for the client to know in advance which hops will verify the payments and which ones will not.

A node that wants to pay (or donate) could do this by having a bitcoin client and having access to the Internet. Anyway this requires big computational and memory resources. Further, it would be prohibitive to send micropayments because of the fees built into the bitcoin network.
There is a better alternative if the payment address of the sender and the receiver are both accounts of Coinbase service. In this case micropayments with low delay and no fees are possible. Furthermore the client just need to use the API of that service and this can be done with very low computing resources.

Final note:
The porting goes on steadily. I presume to have a first version ready for the masses before summer. I hope obviously to be able to implement also the rewarding system.