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!
No comments:
Post a Comment