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.

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.

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.

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.