Saturday, December 25, 2010

Routing

Of course, the real benefit of a routing protocol is, well, the routing.
The previous installation was the first node which has more than one NIC, one wired and one wireless. My next installation will hook into the netsukuku network using that wireless network (luca-ntk).

I have a laptop. I imagine you can guess its hostname... yes: luca-laptop.
I want it to become a pure netsukuku node, that is it will not have an address in the range of 192.168.1.* and will not communicate directly with the router of my WISP, therefore it will not be directly connected to the Internet.

The configuration is really easy: I will just turn off NetworkManager, clear all the addresses from the nics (eth0 and wlan0) and all the routes from the "main" routing table.
Then I will manually connect the wireless interface to the ESSID luca-ntk. Finally I will run ntkd passing both the wired and the wireless interfaces.
As a first step, I am not aiming at being able to surf the Internet. This will be a goal for a future post, though.

I will try to hook into the network from the ad-hoc network created in the previous post. Then I will check whether I can communicate with all the nodes, thus effectively checking whether the routing bit really works.
After that, I will connect the wired interface of the laptop to the wired LAN too, and see what happens.
Let's start.

Configuring and running

After the usual installation bits, I issued the following:

# disable network management
sudo stop network-manager
sudo killall dhclient
sudo ip route flush table main
sudo ip address flush dev eth0
sudo ip address flush dev wlan0
# activate adhoc wifi
sudo ip link set wlan0 down
sudo iw dev wlan0 del
sleep 1
sudo iw phy phy0 interface add adhoc0 type ibss
sleep 1
sudo ip link set adhoc0 up
sleep 1
# join network luca-ntk
sudo iw dev adhoc0 ibss join luca-ntk 2462 fixed-freq

This time I used the more up-to-date "iw" command to operate the radio chip, because this hardware is supported.

Then I started the daemon:

# prepare to use ANDNA
sudo tee /etc/resolv.conf <<EOF >/dev/null
nameserver 127.0.0.1
EOF
# launch the daemon
cd ~/netsukuku/pyntk
sudo /opt/stackless/bin/python2.6 ntkd -i eth0 adhoc0 -vvvv

Tiny bit of technical data

The command "ip r list table ntk" shows that luca-laptop has in its routing table records for 2 destinations, that are 2 g-nodes of level 7. Both are routed via the same gateway.
The commands that follow show that luca-laptop is able to resolve the hostname luca-desktop. The address of luca-desktop is, indeed, inside one of the g-nodes whom luca-laptop knows a route for (i.e. 10.192.0.0/11).
Similar situation in luca-desktop.
Finally a slightly different scenario in luca-dell, which has 2 neighbours and a route to a g-node for each one of them.

luca@luca-laptop:~$ ip r list table ntk
10.144.120.180 dev adhoc0  scope link  src 10.44.11.173 
10.192.0.0/11 via 10.144.120.180 dev adhoc0  src 10.44.11.173 
10.128.0.0/11 via 10.144.120.180 dev adhoc0  src 10.44.11.173 
unreachable 10.0.0.0/8 
luca@luca-laptop:~$ dig luca-desktop.ntk

; <<>> DiG 9.7.1-P2 <<>> luca-desktop.ntk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62009
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;luca-desktop.ntk.  IN A

;; ANSWER SECTION:
luca-desktop.ntk. 299 IN A 10.207.229.53

;; Query time: 107 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 22 19:29:39 2010
;; MSG SIZE  rcvd: 50

luca@luca-laptop:~$ ip r get 10.207.229.53
10.207.229.53 via 10.144.120.180 dev adhoc0  src 10.44.11.173 
    cache  mtu 1500 advmss 1460 hoplimit 64
luca@luca-laptop:~$ 



luca@luca-desktop:~$ ip r list table ntk
10.144.120.180 dev eth0  scope link  src 10.207.229.53 
10.32.0.0/11 via 10.144.120.180 dev eth0  src 10.207.229.53 
10.128.0.0/11 via 10.144.120.180 dev eth0  src 10.207.229.53 
unreachable 10.0.0.0/8 
luca@luca-desktop:~$ 



luca@luca-dell:~$ ip r list table ntk
10.207.229.53 dev eth0  scope link  src 10.144.120.180 
10.44.11.173 dev eth1  scope link  src 10.144.120.180 
10.32.0.0/11 via 10.44.11.173 dev eth1  src 10.144.120.180 
10.192.0.0/11 via 10.207.229.53 dev eth0  src 10.144.120.180 
unreachable 10.0.0.0/8 
luca@luca-dell:~$ 

Testing the achievements

I tried to ping "luca-desktop.ntk" from the laptop with success. The TTL value reported was 63, indicating that the travel of the packets was made of 2 hops. That's via wifi from the laptop to the Dell, then via wire from the Dell to the desktop.
While the ping was still going, I tried to connect the eth0 to the LAN. The ping continued as before, but after 5~8 seconds the TTL value passed to 64, indicating that now the packets were delivered with a single hop. In fact via wire from the laptop to the desktop.
Then I tried to remove the cable. The ping stopped for a while, then after about 15~20 seconds the packets were again delivered in 2 hops, with a TTL of 63.

The ping program is certainly a poor test. I will test the reactions to these sort of events on more sophisticated programs that use the TCP or UDP protocols and I will summarize the results in a future post.
Please note that a painless reaction to these sort of events is what we all would like to see. Netsukuku aims to provide a mechanism to automatically discover paths in a mesh network and react to changes in the topology. Anyway, the events that we really need to handle in a painless way for the users are not simulated very well on this test.
A node that wants to be a server should anyway be placed in a location where its links do not die frequently. Also, a user would expect a connection to work properly when its client machine is connected with a robust link to the network. Instead, the changes that netsukuku needs to handle efficiently are those in the links that are in between. To test these sort of events I will need many more nodes.

Houston, we have a problem

In the very first post I wrote that this blog would have documented the issues that I met during the deploy.
During the installation of this third node a problem manifested itself with the DNS wrapper. When a query for a hostname has to be forwarded to a real DNS server in the Internet that request is carried on synchronously.

The symptoms are:
1. when we do several lookups at once (e.g. when a page with images is loaded on a browser) these are completed in more time than we would expect.
2. when we do a lookup that requires long time to complete (this is the case for the current installation because the node cannot communicate with the Internet) then the whole daemon freezes for a while and unexpected behaviors for the node occur.

The problem showed up clearly because the node cannot communicate with the Internet, but anyway the problem is present also in nodes that can do it.
This requires two fixes. The first one is that we have to let the DNS wrapper know (through its configuration file) when it must refuse queries for the Internet. This is quite easy to do. It is more a workaround than a solution.
The second one, more a solution instead, is to forward the queries asynchronously. But it will require more time to fix it. We use a library (dnspython) that doesn't offer that. Once again, anyone expert in dns protocol willing to help is welcome.

I will work on fixing it, but I will also try to keep on testing and posting to the blog. So, stay tuned! Merry Christmas!

Monday, December 20, 2010

The second node

The tower pc that was the subject of the previous post is going to be placed in the garage. It will be always ON and it has to be accessed from the comfort of the living room. Did I mention that the electrician did a beautiful job? The garage, the rooms and the roof are wired. The guy of the WISP mounted their router in the roof. So, at the moment my tower pc is inside the house, but when I move it in the garage I will not need to do any change.
As suggested in a comment, I had a look at chkconfig, update-rc.d, sysv-rv-conf, ... There are many tools to configure/enable/disable a service as NetworkManager. Since Ubuntu has update-rc.d installed by default I will try and use it.
But all this is not quite on-topic.

Let's go back to netsukuku. My next installation will be on a netbook that will stay in the apartment. It is a Dell Mini 9. It will be connected to the WISP-router and to the tower pc via its wired interface eth0. As with the previous install, the netbook will be able to reach netsukuku nodes and Internet nodes directly.
Then, the netbook will use its radio interface, by creating an ad-hoc wi-fi network, managing it only with netsukuku.

Installation steps

Firstly, I followed the instructions in the wiki page that I recently blogged about. This way I installed the dependencies, got the code to run the netsukuku daemon and configured ANDNA. I did not run the daemon immediately.

Secondly I followed the same steps as for the desktop pc in order to get rid of NetworkManager. I assigned a static IP to the eth0 interface and a default route via the router of my WISP.

sudo stop network-manager
sudo killall dhclient

sudo ip a del 192.168.1.193/24 dev eth0
sudo ip r flush table main

sudo ip a add 192.168.1.193 dev eth0
sudo ip r add 192.168.1.0/24 dev eth0
sudo ip r add default via 192.168.1.1 dev eth0
sudo tee /etc/resolv.conf <<EOF >/dev/null
nameserver 8.8.8.8
EOF

Thirdly, I created an ad-hoc wireless network. The BSSID is luca-ntk. I use no security on it because, AFAIK, the driver of the wireless chip in my laptop has some problems with it.

sudo ip link set eth1 down
sleep 1
sudo iwconfig eth1 mode ad-hoc essid luca-ntk channel 11
sleep 1
sudo ip link set eth1 up

Finally I run netsukuku this way:

cd netsukuku/pyntk
sudo /opt/stackless/bin/python2.6 ntkd -i eth0 eth1 -vvvv

and, on another terminal:

sudo tee /etc/resolv.conf <<EOF >/dev/null
nameserver 127.0.0.1
EOF

A look at the routing that ntkd is imposing

If you are not much interested in technical bits, feel free to skip this section.

The command "ip a" tells us that interface eth0 has 2 IP addresses, the one we set manually to use our ISP and the one assigned automatically by netsukuku. Furthermore, interface eth1 (my radio chip is identified with this name) has only one address, the same one of eth0 in the class 10.0.0.0/8.
Note: since this is the second node of a network, when it detects the presence of the other one, one of them is going to change its address and join the network created by the other one. Hence, if you run the command "ip a" immediately after the launch of pyntk, you might see an address that is not the final one. Just wait 15 seconds and you should be safe.

The commands "dig www.linux.com" and "dig -x 140.211.167.55" show that we can do lookup and inverse lookup on Internet names.
Note: the discrepancy that I noticed in the previous test still apply. The command "dig -x 74.125.232.113" returns NXDOMAIN when using a real DNS whilst it returns SERVFAIL when using our wrapper. If you have experience in DNS protocol and you're willing to help with this, you are welcome.

As before, the commands "ip r" and "ip rule" show that no routing rules are modified in the main table, but the new table "ntk" has been added. Its content is listed by the command "ip r list table ntk".
There is a route for the local neighbour 10.207.249.92 which has been detected on interface eth0. When we communicate with it we prefer to be identified by our address 10.62.80.193. This is important because the other address of ours (192.168.1.194) would not be guaranteed to be unique nor reachable from any other node of this netsukuku realm.

There is also a route for the class 10.192.0.0/11. Packets destined to this class's addresses will be routed via 10.207.249.92.
That class is a g-node of level 7. Indeed, in its default configuration pyntk will deploy a network with 8 levels of g-nodes and with 8 nodes per each g-node. This will consume the whole class 10.0.0.0/8 and provides 8^8 = 16 millions of places but requires only 8x8 = 64 destinations in the routing tables of the nodes.
As it was expected, our address (10.62.80.193) is not part of that class, whilst the address of the neighbour (10.207.249.92) is part of it.

There is, finally, the route for the whole class 10.0.0.0/8 which states "unreachable".
Hence, if we try to ping 10.1.1.1 we get immediately the error "Network is unreachable". If we try to ping 10.192.1.1 our node does not know if this exists, so it sends the packets to the gateway 10.207.249.92 and it answers back to us: "Destination Host Unreachable".

The command "ip rule" shows also another table. It has no name and its number is 199. This table is not looked up for all packets, instead it is looked up for packets marked with 0xc7.
As we see with the command "ip r list table 199", that table has a rule that states to drop (that's the meaning of blackhole) the packets destined to the afore mentioned class/g-node.
But, who marks the packet with 0xc7? We can see it with the command "sudo iptables -t mangle -L PREROUTING". It tells us that the kernel will mark the packets which have been sent to us by a particular MAC.
All this intricate bits are part (not the whole) of a mechanism that netsukuku uses to avoid the formation of looping paths. Perhaps I will blog later on the details of that, if the readers are curious. For the moment it is not much important, considered the aim of this blog.

The actual commands and their output as seen in my netbook were:

luca@luca-dell:~/netsukuku/pyntk$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:21:70:c8:0d:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.193/32 scope global eth0
    inet 10.62.80.193/32 scope global eth0
    inet6 fe80::221:70ff:fec8:dc0/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:23:08:1f:90:ba brd ff:ff:ff:ff:ff:ff
    inet 10.62.80.193/32 scope global eth1
    inet6 fe80::223:8ff:fe1f:90ba/64 scope link 
       valid_lft forever preferred_lft forever
luca@luca-dell:~/netsukuku/pyntk$ dig www.linux.com

; <<>> DiG 9.7.1-P2 <<>> www.linux.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44927
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.linux.com.   IN A

;; ANSWER SECTION:
www.linux.com.  2 IN A 140.211.167.55

;; Query time: 105 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 22:46:23 2010
;; MSG SIZE  rcvd: 47

luca@luca-dell:~/netsukuku/pyntk$ dig -x 140.211.167.55

; <<>> DiG 9.7.1-P2 <<>> -x 140.211.167.55
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17442
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;55.167.211.140.in-addr.arpa. IN PTR

;; ANSWER SECTION:
55.167.211.140.in-addr.arpa. 68 IN PTR fossology.org.

;; Query time: 106 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 22:46:49 2010
;; MSG SIZE  rcvd: 72

luca@luca-dell:~/netsukuku/pyntk$ ip r
192.168.1.0/24 dev eth0  scope link 
default via 192.168.1.1 dev eth0 
luca@luca-dell:~/netsukuku/pyntk$ ip rule
0: from all lookup local 
32764: from all fwmark 0xc7 lookup 199 
32765: from all lookup ntk 
32766: from all lookup main 
32767: from all lookup default 
luca@luca-dell:~/netsukuku/pyntk$ ip r list table ntk
10.207.249.92 dev eth0  scope link  src 10.62.80.193 
10.192.0.0/11 via 10.207.249.92 dev eth0  src 10.62.80.193 
unreachable 10.0.0.0/8 
luca@luca-dell:~/netsukuku/pyntk$ ping 10.1.1.1
connect: Network is unreachable
luca@luca-dell:~/netsukuku/pyntk$ ping 10.192.1.1
PING 10.192.1.1 (10.192.1.1) 56(84) bytes of data.
From 10.207.249.92 icmp_seq=1 Destination Host Unreachable
From 10.207.249.92 icmp_seq=2 Destination Host Unreachable
From 10.207.249.92 icmp_seq=3 Destination Host Unreachable
From 10.207.249.92 icmp_seq=4 Destination Host Unreachable
From 10.207.249.92 icmp_seq=5 Destination Host Unreachable
^C
--- 10.192.1.1 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 3999ms

luca@luca-dell:~/netsukuku/pyntk$ ip r list table 199
blackhole 10.192.0.0/11 
luca@luca-dell:~/netsukuku/pyntk$ sudo iptables -t mangle -L PREROUTING
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  anywhere             anywhere            MAC 00:16:76:B6:A7:24 MARK xset 0xc7/0xffffffff 
luca@luca-dell:~/netsukuku/pyntk$ 

Testing the achievements

I can use the Internet from both my machines as usual.

Recall that my first node has hostname = luca-desktop. My netbook has hostname = luca-dell.
If I issue a "dig luca-dell.ntk" from both the machines I now get the correct address. The same goes for luca-desktop.ntk.
If I issue a "dig -x 10.207.249.92" from both the machines I now get the correct hostname. The same goes for 10.62.80.193.

luca@luca-dell:~/netsukuku/pyntk$ dig luca-desktop.ntk

; <<>> DiG 9.7.1-P2 <<>> luca-desktop.ntk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15669
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;luca-desktop.ntk.  IN A

;; ANSWER SECTION:
luca-desktop.ntk. 299 IN A 10.207.249.92

;; Query time: 128 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 22:50:09 2010
;; MSG SIZE  rcvd: 50

luca@luca-dell:~/netsukuku/pyntk$ dig luca-dell.ntk

; <<>> DiG 9.7.1-P2 <<>> luca-dell.ntk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26160
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;luca-dell.ntk.   IN A

;; ANSWER SECTION:
luca-dell.ntk.  299 IN A 10.62.80.193

;; Query time: 111 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 22:50:20 2010
;; MSG SIZE  rcvd: 47

luca@luca-dell:~/netsukuku/pyntk$ dig -x 10.207.249.92

; <<>> DiG 9.7.1-P2 <<>> -x 10.207.249.92
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13233
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;92.249.207.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
92.249.207.10.in-addr.arpa. 2592000 IN PTR luca-desktop.NTK.

;; Query time: 375 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 22:50:32 2010
;; MSG SIZE  rcvd: 74

luca@luca-dell:~/netsukuku/pyntk$ dig -x 10.62.80.193

; <<>> DiG 9.7.1-P2 <<>> -x 10.62.80.193
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44114
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;193.80.62.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
193.80.62.10.in-addr.arpa. 2592000 IN PTR luca-dell.NTK.

;; Query time: 71 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 22:50:41 2010
;; MSG SIZE  rcvd: 70

luca@luca-dell:~/netsukuku/pyntk$ ping luca-desktop.ntk
PING luca-desktop.ntk (10.207.249.92) 56(84) bytes of data.
64 bytes from luca-desktop.NTK (10.207.249.92): icmp_req=1 ttl=64 time=0.407 ms
64 bytes from luca-desktop.NTK (10.207.249.92): icmp_req=2 ttl=64 time=0.476 ms
64 bytes from luca-desktop.NTK (10.207.249.92): icmp_req=3 ttl=64 time=0.457 ms
64 bytes from luca-desktop.NTK (10.207.249.92): icmp_req=4 ttl=64 time=0.470 ms
64 bytes from luca-desktop.NTK (10.207.249.92): icmp_req=5 ttl=64 time=0.468 ms
^C
--- luca-desktop.ntk ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.407/0.455/0.476/0.034 ms
luca@luca-dell:~/netsukuku/pyntk$ 

I issued the following commands on the deskop:

luca@luca-desktop:~/netsukuku/pyntk$ ping luca-dell.ntk
PING luca-dell.ntk (10.62.80.193) 56(84) bytes of data.
64 bytes from luca-dell.NTK (10.62.80.193): icmp_req=1 ttl=64 time=0.259 ms
64 bytes from luca-dell.NTK (10.62.80.193): icmp_req=2 ttl=64 time=0.278 ms
64 bytes from luca-dell.NTK (10.62.80.193): icmp_req=3 ttl=64 time=0.275 ms
64 bytes from luca-dell.NTK (10.62.80.193): icmp_req=4 ttl=64 time=0.275 ms
64 bytes from luca-dell.NTK (10.62.80.193): icmp_req=5 ttl=64 time=0.275 ms
^C
--- luca-dell.ntk ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.259/0.272/0.278/0.016 ms
luca@luca-desktop:~/netsukuku/pyntk$ 

I activated the "remote desktop" on the netbook and tried to access from the desktop, by using the name luca-dell.ntk. Here's a little shot of the result. You can see the result of one lookup (from the name luca-dell.ntk to the IP) and one reverse lookup (from the calling IP to the name luca-desktop.NTK)



If I have a look with another device to the wireless networks, I see the ad-hoc network named luca-ntk. Obviously, if I try to connect to it with a laptop/smartphone/xxx that has not netsukuku installed and running, then the connection will fail because the laptop searches for a DHCP server and there isn't.

That's it for the second node. Stay tuned for more!

Friday, December 17, 2010

HowTo test netsukuku daemon on real hardware

As promised, I am linking to a new page in the wiki where I have summarized what you need to do with your machine (only Linux is supported right now) to try and use netsukuku. Compared to the previously linked page, this one is focusing on real hardware rather than virtual networks. And it is in English. Here's the link.

Friday, December 10, 2010

First installation

At last I am connected to Internet in the new house.
The router that the ISP gave to me acts as DHCP server to the LAN and it assigns addresses in class 192.168.1.0/24. Furthermore, it acts as default gateway and DNS server and does NAT.
My desktop computer (mini tower case) is connected to it via eth0. I want it to be able to access both the netsukuku network and the Internet.


Installing pyntk and its dependencies

I installed all the dependencies of pyntk in my desktop pc. There is a page in the project's wiki where all details of these operations are described, though at the moment it is only in Italian. I will post in the blog when a version in English will be ready. For the moment you can try and use Google Translate on it. The page is http://lab.dyne.org/Netsukuku/ita/TestWithNetkit.
Then I downloaded from the repository the current version of my netsukuku branch (the one with latest updates to the code). I typically use another laptop to code and debug. The repository can be browsed here http://dev.hinezumi.org/browser/netsukuku/sandbox/lukisi/branches/multipleip.


Disabling Network Manager

It is necessary that the network parameters of the host are managed by pyntk.
Hence, I decide to disable other managers implemented by the operating system.
Beforehand I examine the parameters which were set via DHCP. I will set these values statically:
  • IP: 192.168.1.151
  • Subnet 192.168.1.0/24 on device eth0
  • Default Gateway 192.168.1.1 on device eth0
  • DNS 8.8.8.8

Modern desktop linux distributions use NetworkManager to handle the network parameters.
We can disable it with the command "sudo stop network-manager", though we'll have to re-do at each reboot. I still have to investigate for the clean way to disable it permanently.

On my machine I also see a running process of "dhclient". Probably it has been launched by NetworkManager itself, however disabling NetworkManager has not terminated that process. Its documentation says it stays in background and it periodically refreshes the lease from the DHCP server.
This process does change the network parameters too, so I terminate it with a "killall dhclient" and I will repeat this operation at each reboot.

To summarize, after the boot of my desktop pc, I open a terminal and issue the following commands:

sudo stop network-manager
sudo killall dhclient

sudo ip a del 192.168.1.151/24 dev eth0
sudo ip r flush table main

sudo ip a add 192.168.1.151/24 dev eth0
sudo ip r add default via 192.168.1.1 dev eth0
sudo tee /etc/resolv.conf <<EOF >/dev/null
nameserver 8.8.8.8
EOF


ANDNA

ANDNA service is implemented in the current version of pyntk!
At first, ANDNA reads the name saved in the file /etc/hostname. Further, one can specify more names and details in the file /etc/netsukuku/snsd_nodes.
My file /etc/hostname contains luca-desktop. For now I do not intend to specify more in the other one.
Then ANDNA registers the names assigned to the host into the network-distributed database. The registration of each name fails if the name has already been registered by someone else or the host exceeded the maximum number of registered names.
When the registration is complete, ANDNA is able to lookup an host's name into the distributed database and retrieve its numerical address.

How do we submit a query to ANDNA? We have implemented, inside the daemon pyntk, a DNS-wrapper which listens to requests on DNS service's port. When it receives a lookup request, if the name ends with ".ntk" then the request is considered to be about the netsukuku realm, otherwise it is about the Internet realm. For reverse lookup requests, if the address is in the class 10.0.0.0/8 then the request is considered to be about the netsukuku realm, otherwise it is about the Internet realm.
If the query is about the netsukuku realm, the DNS-wrapper translates the DNS query in a ANDNA query, submits it to ANDNA, translates the answer back in a DNS answer and returns it to the caller.
If the query is about the Internet realm, the DNS-wrapper acts as a proxy to a real DNS server.

The DNS-wrapper lives inside the pyntk daemon, so it can listen only when pyntk is running. Hence, we must set the "nameserver" parameter in the file /etc/resolv.conf to 127.0.0.1 right before starting pyntk, and set it back to a real DNS server when pyntk terminates.
Furthermore ANDNA reads configuration details in other files (which I'm not going to explain right now).

In conclusion, before starting pyntk I issue the following commands:

sudo tee /etc/resolv.conf <<EOF >/dev/null
nameserver 127.0.0.1
EOF
sudo mkdir -p /etc/netsukuku
sudo tee /etc/netsukuku/dnswrapper.conf <<EOF >/dev/null
andnsserver in-process
EOF
sudo tee /etc/netsukuku/andnsserver.conf <<EOF >/dev/null
inetnameserver 8.8.8.8
EOF
sudo tee /etc/netsukuku/libandns.conf <<EOF >/dev/null
andnsserver 127.0.0.1
EOF

After pyntk terminates (in case of errors or for any other reason) I issue the following commands:

sudo tee /etc/resolv.conf <<EOF >/dev/null
nameserver 8.8.8.8
EOF


Start pyntk


To start the daemon:

cd ~/netsukuku/pyntk
sudo /opt/stackless/bin/python2.6 ntkd -i eth0 -vvvv

That command starts the daemon to handle interface eth0. It sets a very verbose output. The command will not put itself in background, so to carry on I will have to open another terminal.

Let's see what we achieved. [Scroll down to see the actual commands and their output as seen in my box]

The command "ip a" tells us that interface eth0 has 2 IP addresses. The first is the one we previously set, manually, with which we can use our ISP. The other, in the class 10.0.0.0/8, has been assigned automatically to us by netsukuku. Since this is the first node in a network, it will be absolutely random. In my case it is 10.101.92.210.

The command "dig www.google.com" proves that we can use Internet.
The server that is answering is 127.0.0.1, our DNS-wrapper inside pyntk. But actually the request has been forwarded to a real DNS server, the one we placed in the file /etc/netsukuku/andnsserver.conf in parameter inetnameserver, that is 8.8.8.8.
This confirms that we reached the Internet node 8.8.8.8. Among the answers for "www.google.com" we notice 74.125.232.113.

The command "dig -x 74.125.232.113", which should have done the reverse lookup, gives an unexpected error instead. I will debug later looking for the causes.

The command "ip r" shows that no routes have been added (nor removed) to the kernel's "main" routing table.

The command "ip rule" shows that a new routing table has been created, "ntk", which gets looked up for any packet right before the "main" routing table.

The command "ip r list table ntk" shows that a definition has been added to declare "unreachable" any destination in class 10.0.0.0/8. This rule will always be the last in the ntk table. It ensures that this table will be the exclusive responsible for routes to destinations inside netsukuku. In particular, it avoids that packets whose destination is inside netsukuku could be forwarded by this node to its default gateway, which is a router in the Internet realm.
As a result, the command "ping 10.1.1.1" will give immediately the error "connect: Network is unreachable". Whilst, of course, the command "ping 10.101.92.210" (my IP as seen before with "ip a") will work normally.

The command "dig luca-desktop.ntk" returns my IP, retrieved by ANDNA from its distributed database. The command "dig -x 10.101.92.210" shows that the reverse resolution works too inside netsukuk realm.

luca@luca-desktop:~/netsukuku/pyntk$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:76:b6:a7:24 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.151/24 scope global eth0
    inet 10.101.92.210/32 scope global eth0
    inet6 fe80::216:76ff:feb6:a724/64 scope link 
       valid_lft forever preferred_lft forever
luca@luca-desktop:~/netsukuku/pyntk$ dig www.google.com

; <<>> DiG 9.7.1-P2 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41319
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.   IN A

;; ANSWER SECTION:
www.google.com.  0 IN A 74.125.232.113
www.google.com.  0 IN A 74.125.232.115
www.google.com.  0 IN A 74.125.232.114
www.google.com.  0 IN A 74.125.232.112
www.google.com.  0 IN A 74.125.232.116

;; Query time: 73 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 10 10:15:35 2010
;; MSG SIZE  rcvd: 112

luca@luca-desktop:~/netsukuku/pyntk$ dig -x 74.125.232.113

; <<>> DiG 9.7.1-P2 <<>> -x 74.125.232.113
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33110
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;113.232.125.74.in-addr.arpa. IN PTR

;; Query time: 151 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 10 10:22:06 2010
;; MSG SIZE  rcvd: 45

luca@luca-desktop:~/netsukuku/pyntk$ ip r
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.151 
default via 192.168.1.1 dev eth0 
luca@luca-desktop:~/netsukuku/pyntk$ ip rule
0: from all lookup local 
32765: from all lookup ntk 
32766: from all lookup main 
32767: from all lookup default 
luca@luca-desktop:~/netsukuku/pyntk$ ip r list table ntk
unreachable 10.0.0.0/8 
luca@luca-desktop:~/netsukuku/pyntk$ ping 10.1.1.1
connect: Network is unreachable
luca@luca-desktop:~/netsukuku/pyntk$ ping 10.101.92.210
PING 10.101.92.210 (10.101.92.210) 56(84) bytes of data.
64 bytes from 10.101.92.210: icmp_req=1 ttl=64 time=0.029 ms
64 bytes from 10.101.92.210: icmp_req=2 ttl=64 time=0.028 ms
64 bytes from 10.101.92.210: icmp_req=3 ttl=64 time=0.021 ms
64 bytes from 10.101.92.210: icmp_req=4 ttl=64 time=0.032 ms
64 bytes from 10.101.92.210: icmp_req=5 ttl=64 time=0.026 ms
^C
--- 10.101.92.210 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.021/0.027/0.032/0.005 ms
luca@luca-desktop:~/netsukuku/pyntk$ dig luca-desktop.ntk

; <<>> DiG 9.7.1-P2 <<>> luca-desktop.ntk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13918
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;luca-desktop.ntk.  IN A

;; ANSWER SECTION:
luca-desktop.ntk. 299 IN A 10.101.92.210

;; Query time: 31 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 10 10:44:38 2010
;; MSG SIZE  rcvd: 50

luca@luca-desktop:~/netsukuku/pyntk$ dig -x 10.101.92.210

; <<>> DiG 9.7.1-P2 <<>> -x 10.101.92.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59604
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;210.92.101.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
210.92.101.10.in-addr.arpa. 2592000 IN PTR luca-desktop.NTK.

;; Query time: 54 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 10 10:44:53 2010
;; MSG SIZE  rcvd: 74

luca@luca-desktop:~/netsukuku/pyntk$ 

Stay tuned for more!

Tuesday, November 30, 2010

First things first

I thought that the first thing that I have to make clear (to the reader and to myself) is: what do I want to achieve in this deploy? That is, what features this network has to have to be considered a success?

No need to say that all the nodes have to be reachable by any of the nodes.

This netsukuku deploy will be, no doubt, a very temporary and experimental network, very prone to go down or to be unusable in unpredictable moments and for unpredictable periods of time.
Nevertheless, I want to be able to access the Internet from (at least) some of the nodes of the network.
The first effect of this requirement, since the so called "net-split" mechanism is not implemented in pyntk, is that I am going to use the so called "restricted mode". It means that the addresses of the nodes of the netsukuku network must not clash with public IPs on the Internet. We are going to use only addresses in the 10.0.0.0/8 class.
If the mechanisms of address assignment and migrations work as expected, though, we will have enough room for a long time (theoretically 16 millions nodes)

The choice of using this class will further allow me to *manually* assign a secondary private address (eg in the 192.168.0.0/16 class) to each of my own nodes, so that I will have a fallback mean of accessing them. These addresses will not clash with the addresses of the nodes of other people that will join the network. And yes, I have a positive confidence that this will eventually happen. ;)

The second effect of this requirement is that, since the Internet Gateway Sharing (IGS) mechanism is not yet implemented, I will need to use a surrogate of this. I am thinking to use some sort of web proxy or SOCKS server on the node that will be directly connected to the Internet. That will be made available only to my own nodes. (Sorry, no free Internet for now!)
Should I try a more powerful NAT solution, I envision that more problems will arise. Time will tell.

As a side note, and my very personal point of view, I tell you that a net-split mechanism (to enable the use of all IPv4 addresses instead of 10.0.0.0/8) will not be implemented very soon, and I am not much convinced of the advantages of net-split (as it currently is envisioned in netsukuku RFC) over restricted-mode.
On the other hand, an Internet Gateway Sharing mechanism will undoubtedly be implemented soon in pyntk, I think.

That's all for the moment. Next post will actually document something done.
I am still waiting for the WISP to connect my home to the Internet. This problem is going to slow my activities down a bit. Be prepared for a somewhat longer wait.

Thursday, November 25, 2010

The journey begins

This is the first post.

This journey begins with my move to a new house. I still have to arrange many things at home: I haven't got a TV yet, nor a washing machine.
From the start, I asked the electrician to provide ethernet cabling in the rooms, to the garage and to the roof. The aim is to have a server in the garage and, obviously, a wireless device on the floor roof.

At the same time that I am moving, we have a quite feature-complete implementation of the netsukuku daemon, so I thought that I could try and deploy a real network and document my activities, the issues, the work-arounds, the fine-working features, and so on.

Stay tuned!