Our houses are within about 200 meters, and from the roofs there is optimal line of sight.
First, each of us passed a network cable from the apartment to the roof. Then we made the wireless link by means of two routers of Ubiquity.
As you know, at the moment the netsukuku daemon cannot run on such a router.
Nevertheless, in order to connect to a netsukuku network a node must run the daemon and be directly connected to at least another node on which the daemon runs.
This gives to me an occasion to describe a possible solution to that situation.
We elected two computers to be always on (or at least when we need the network to function).
Each one of these is directly connected to the router on the roof.
These two computers have an IP address in the class 192.168.2.0/24. The same goes for the routers.
Some static routes have been saved to the computers and routers to make the two computers able to communicate.
At this point, we need an application of VPN able to emulate a physical link at the layer 2 level.
I chose tinc. It's easy to install on Ubuntu. The configurations that one needs to do in order to realize a "virtual hub" between two computers is very simple.
When tinc is in action, the two computers see a new NIC, named for instance tinc0.
Via that NIC it's as if the two computer were directly connected.
After these operations, the computer of my friend is a node of the network in its own right.
The addition of the new node is not problematic for the routing. After all the topology of the network deployed til now is not complex at all.
On the other hand an interesting aspect is that now there are 2 nodes with a direct access to the Internet. A situation where the IGS feature hasn't been well tested yet.
As I said previously on this blog, the current IGS implementation makes a node able to share its own link to the Internet OR to use the links that are shared by other nodes. But not both.
So, I made some tests from a node that uses the shared links (IGS_MODE='USE').
luca@luca-laptop:~$ ip route list
default
nexthop via 10.219.181.44 dev ntk-to-inet-0 weight 3 onlink
nexthop via 10.12.13.72 dev ntk-to-inet-1 weight 1 onlink
luca@luca-laptop:~$
The browser (firefox) seems to behave normally.
The download manager DownThemAll gave some satisfactions. Putting few files in the queue I reached from time to time a rate of 800 KBs, about twice the rate I normally get with my ISP.
I used Skype for some time, without noticing any anomaly.
I haven't had enough time to test aMule's performance, yet.
Stay tuned.
Sorry for my English.
ReplyDeleteLayer 2 VPN ? I think that netsukuku must be able to store static IP list of the known nodes. VPN is very heavyweight solution, isn't it ?
What do you think about this feature request ? )))
Storing static IP list of the known nodes would be really heavy. :)
ReplyDeleteYour statement is imprecise. Probably you meant that netsukuku has to provide IP assignment and dynamic routing to the whole address space.
It does. But it requires that all the nodes are connected and run the daemon.
This requirement is not fulfilled in my network, since the Ubiquity routers don't run the daemon.
What I did in this installment is to make a very small subnet (4 nodes) where the routing is statically managed in an address space that is not conflicting with the netsukuku address space (192.168.2.*).
Not exactly as you described.
ReplyDeleteI mean that netsukuku may read small static IP list for nodes that can't be reached by netsukuku discovery process. This small list can be stored at "border" nodes.
@buffovich
ReplyDeleteCould you subscribe to the mailing list and start a thread for that?
The argument is interesting, I have in mind pros and cons.
Which mailing list I should subscribe to ?
ReplyDeletehttp://lists.dyne.org/mailman/listinfo/netsukuku
ReplyDelete