Once your network project is in place, you may find that it will quickly grow beyond your expectations. What begins as a simple point-to-point link across the street might need to quickly expand to accommodate friends and neighbors, as they find out about “the network.” As the network grows, the complexity of managing it grows as well. But then, this is the fun part. Here are some novel innovations that community groups are using to extend their projects into fun new areas. While they are not directly related to wireless networking, these ideas can enhance your wireless network.
If you’re using private address space for your
wireless network and it grows to a respectable size, you will
probably want to start offering local services (such as web servers
and music streamers). But simply using IP addresses is no fun.
Consider the ease of setting up your own
top-level domain (TLD). Normally, zone
entries in named.conf
look something like this:
zone "oreillynet.com" { type master; file "data/oreillynet.com"; };
This is an entry appropriate for an authoritative DNS server for the oreillynet.com subdomain. The actual top-level domains (i.e., .com, .net, .org, .int, etc.) in use on the Internet are delegated only to the mysterious 13 known as the root DNS servers. Even though your DNS servers won’t be consulted by the rest of the Internet, it can be handy to set up your very own TLD that works only on your wireless network.
For example, suppose your wireless network uses the private
10.42.5.0/24
network. These machines
aren’t reachable directly from the Internet, and you
don’t really want to advertise their DNS information
to would-be network crackers. Try a non-standard TLD:
zone "cat" { type master; file "data/cat"; allow-transfer { 10.42.5/24; }; allow-query { 10.42.5/24; }; };
(We actually use .cat on the NoCat Network in Sebastopol. If you’ve ever wondered where the cat went, now you’ve found it.) With this added to your zone file, set up a master record for .cat just as you would any other domain:
$TTL 86400 @ IN SOA ns.cat. root.homer.cat. ( 2002090100 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire (1 week) 60 ; Negative expiry time ) IN NS ns.cat. ns IN A 10.42.5.1 homer IN A 10.42.5.10 bart IN A 10.42.5.11 lisa IN A 10.42.5.12
Reload the name server, and you should be able to simply ping
homer.cat
. If you’d like other
name servers to maintain slave copies of your TLD, just add them as
usual:
zone "cat" { type slave; file "db.cat"; masters { 10.42.5.1; }; };
In this way, you can extend your new TLD across your entire private
network architecture. Various network groups are using their own
top-level and subdomain schemes as they come online. For example,
SeattleWireless uses .swn
, and I have
.rob.swn
delegated to my machine at home
(10.15.6.1
). How did I arrive at this number? And
why would people in Sebastopol care about what I’m
doing in Seattle? (Considering that a wireless link between the two
is, well, quite improbable? Read on.)
As we have discussed many times in this book, good wireless communication critically depends on having clean line of sight between two points. If there’s an obstacle that you just can’t go over, around, or through, then you simply can’t have radio communications between those two points. Extremely long range (more than 40 miles or so) just can’t be bridged in a single hop using the techniques and equipment described in this book. But suppose you are building out a community project that has a couple of pockets of wireless infrastructure that simply can’t see each other. How can you build a large network that has a consistent address space if all of the points aren’t directly connected by radio? If there is already an Internet connection at both points, then there is hope. One way to connect the unconnectable is to use the power of IP tunneling.
If you have never worked with IP tunneling, you might want to take a look at the Advanced Router HOWTO (http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/) before continuing. Essentially, an IP tunnel is much like a VPN, except that not every IP tunnel involves encryption. A machine that is “tunneled” into another network has a virtual interface configured with an IP address that isn’t local, but exists on a remote network. Usually, all (or most) network traffic is routed down this tunnel, so remote clients appear to exist on the network as if they were local. A tunnel can be used to allow clients from the Internet access to private network services, or more generally, to connect any two private networks by using the Internet to carry the tunnel traffic.
If you want to perform simple IP-within-IP tunneling between two machines, try IPIP. It is probably the simplest tunnel protocol available, and it works with *BSD, Solaris, and even Windows. Note that IPIP is simply a tunneling protocol, and does not involve any sort of encryption. Here is one method for establishing an IPIP tunnel in Linux.
Before we rush right into our first tunnel, you’ll
need a copy of the advanced routing tools (specifically the
ip
utility). You can get the latest
authoritative copy from ftp://ftp.inr.ac.ru/ip-routing/. Be warned,
the advanced routing tools aren’t especially
friendly, but they allow you to manipulate nearly any facet of the
Linux networking engine.
In this example, I’ll assume that you have two
private networks (10.42.1.0/24
and
10.42.2.0/24
) and that these networks both have
direct Internet connectivity via a Linux router at each network. The
“real” IP address of the first
network router is 240.101.83.2
, and the
“real” IP address of the second
router is 251.4.92.217
. This
isn’t very difficult, so let’s jump
right in.
First, load the kernel module on both routers:
# modprobe ipip
Next, on the first network’s router (on the
10.42.1.0/24
network), do the following:
# ip tunnel add mytun mode ipip remote 251.4.92.217 local 240.101.83.2 ttl 255 # ifconfig mytun 10.42.1.1 # route add -net 10.42.2.0/24 dev tunl0
On the second network’s router (on the
10.42.2.0/24
), reciprocate:
# ip tunnel add mytun mode ipip remote 240.101.83.2 local 251.4.92.217 ttl 255 # ifconfig tunl0 10.42.2.1 # route add -net 10.42.1.0/24 dev tunl0
Naturally, you can give the interface a more meaningful name than
mytun if you like. From the first
network’s router, you should now be able to ping
10.42.2.1
, and from the second
network’s router, you should be able to ping
10.42.1.1
. Likewise, every machine on the
10.42.1.0/24
network should be able to route to
every machine on the 10.42.2.0/24
network, as if
the Internet weren’t even there.
If you’re running a Linux 2.2.x kernel, you’re in luck: here’s a shortcut that makes the advanced routing tools package unnecessary. After loading the module, try these commands:
# ifconfig tunl0 10.42.1.1 pointopoint 251.4.92.217 # route add -net 10.42.2.0/24 dev tunl0
And on the second network’s router
(10.42.2.0/24
):
# ifconfig tunl0 10.42.2.1 pointopoint 240.101.83.2 # route add -net 10.42.1.0/24 dev tunl0
That’s all there is to it.
If you can ping the opposite router, but other machines on the network don’t seem to be able to pass traffic beyond the router, make sure that both routers are configured to forward packets between interfaces:
# echo "1" > /proc/sys/net/ipv4/ip_forward
If you need to reach networks beyond 10.42.1.0
and
10.42.2.0
, simply add additional route add -net
lines. There is no configuration needed on any of
your network hosts, as long as they have a default route to their
respective router (they definitely should; it is
their router).
To close the tunnel, bring down the interface (and delete it, if you like) on both browsers:
# ifconfig mytun down # ip tunnel del mytun
Or, in Linux 2.2:
# ifconfig tunl0 down
The kernel will very politely clean up your routing table for you when the interface goes away.
I am currently using IP tunneling to connect the NoCatNet project with SeattleWireless. Since we are organizing the use of the reserved 10 net space (see http://freenetworks.org/ for the ad hoc IP allocation chart), we know that IP addresses won’t be reused. To date, we have successfully made Voice-over-IP phone calls and shared web and streaming music data over multiple radio hops, through a couple of IP tunnels (spanning California to Washington), and again over several more radio hops. While radio links are always best (in terms of low latency, high bandwidth, and low cost), IP tunnels can help make the impossible a reality.
18.118.28.36