Simple entry point for "legacy systems"

A bit of new code has been committed that should make netsukuku work better as a wrapper for DNS resolution on the Internet side. See my previous post, the part about asynchronous resolution.

I am working out things for a wireless link with a house nearby. Two friends of mine live there and we want to try and see what useful benefits we can get from such a connection.
We are not ready yet but I think that soon this will be a subject for a new post on this netsukuku deploy.

In the mean time, I want to spend a post to give a humble tip on what we can do, at this moment, to make happy also the people with Windows or other OS's.
I say at the moment because I hope in a future release we'll be able to run the netsukuku daemon also in other OS's, whilst now only linux is supported. (btw, Ubuntu and Fedora have both been quite successfully tested)
Anyway, also at this stage, there can be situations in which we'd want to use the network with devices that are not so easy to hack. A smart-phone for example. Or a net-top-box or entertainment device.

A device where the netsukuku daemon cannot be run, cannot by design be a first-class citizen of the network. Its problem is that it cannot have an address that is guaranteed to be unique and reachable by any other node.
Anyway this does not preclude the possibility for us to give a NATted address to it. All in all, it's not much different from what the average user of the Internet can expect, these days.
All that is needed is a direct neighbor that is able to run netsukuku and serve as a NAT. Any linux distro can act as such.

As I said, this post wants to be a humble tip for the reader, which I suppose is not a network illiterate. But nevertheless this is a valid post in this blog because I will effectively document what I actually do in this real network deploy.

The scenario

I recall briefly the situation in my house. There is a wired LAN that connects a server (luca-desktop) in the garage, a netbook (luca-dell) in the apartment and a wireless router (owned by the WISP) in the roof. Then, the netbook maintains an ad-hoc wifi network to which a laptop (luca-laptop) is connected. (btw, a wireless card in AP mode would have worked fine, as well)

The server and the netbook are able to access directly the Internet, while the laptop is not.

Now, I have a Nokia N900 smart-phone. It can connect to wifi networks, both managed and ad-hoc ones. I want it to be able to use the net.
The ideal candidate for this job is luca-dell, since it is connected to the Internet too. It is possible (and easy) to use, at the same time, the same ad-hoc network that is used to provide access to other netsukuku nodes.

The solution

I show you again the current state of addresses and routes in the netbook. This is the machine that will do the NAT.

luca@luca-dell:~$ 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:21:70:c8:0d:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.193/32 scope global eth0
    inet 10.135.184.31/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.135.184.31/32 scope global eth1
    inet6 fe80::223:8ff:fe1f:90ba/64 scope link 
       valid_lft forever preferred_lft forever
luca@luca-dell:~$ ip r
192.168.1.0/24 dev eth0  scope link 
default via 192.168.1.1 dev eth0 
luca@luca-dell:~$ ip r list table ntk
10.117.38.179 dev eth0  scope link  src 10.135.184.31 
10.96.0.0/11 via 10.117.38.179 dev eth0  src 10.135.184.31 
unreachable 10.0.0.0/8 
luca@luca-dell:~$ 

"eth1" is the wireless network interface, in ad-hoc mode.

First, I give to the netbook a new address in a private subnet. The addresses in this subnet will be reached via the wireless interface.

luca@luca-dell:~$ sudo ip addr add 192.168.3.1 dev eth1
luca@luca-dell:~$ sudo ip route add 192.168.3.0/24 dev eth1

Now, the magic of NAT is done by iptables. The following command instructs the kernel to use masquerading for traffic originated in the subnet and destined to the outside.

luca@luca-dell:~$ sudo iptables -t nat -A POSTROUTING -s 192.168.3.0/24 \! -d 192.168.3.0/24 -j MASQUERADE

Last, I install a DHCP server and configure it to listen to requests in interface eth1. This is not strictly needed, but allows a client to auto-configure itself. This part is dependent on the distribution in use. The following commands work on Ubuntu.

luca@luca-dell:~$ sudo apt-get install dhcp3-server
luca@luca-dell:~$ sudo tee -a /etc/dhcp3/dhcpd.conf <<EOF >/dev/null
subnet 192.168.3.0 netmask 255.255.255.0 {
  range 192.168.3.2 192.168.3.20;
  option routers 192.168.3.1;
  option broadcast-address 192.168.3.255;
  option domain-name-servers 192.168.3.1;
}
EOF
luca@luca-dell:~$ sudo dhcpd3 eth1

Now, a client that is not managed by the netsukuku daemon, when it ties up to the wireless network luca-ntk, it will look for a DHCP server. It will get an address in the range 192.168.3.2 192.168.3.20, it will have a default gateway 192.168.3.1 and will use it also as a DNS. In particular, this last bit means that the hostname resolution is delegated to our "DNS wrapper". Hence, the client will be able to translate Internet hostnames as well as netsukuku ones.

Picture worth a thousand words



In this screenshot from my phone (good ol' maemo) you can see the status notification for my account on Gtalk, the green circle near the battery indicator; that means that the phone reaches the Google servers.
Further, you see that the browser has loaded a page from the web server at luca-desktop.ntk; that means that the phone reaches any node in netsukuku.

That's it. Stay tuned for more updates!