|
This document illustrates a simple way to test arand. It uses three computers; in this example, one iPAQ running Familiar Linux and two laptops, each running RedHat Linux.
Each laptop will use a packet firewall, iptables, to simulate distance between them. Each laptop will only be able to "hear" the iPAQ. One laptop will then attempt to run a
traceroute to the other. On that laptop, arand will request a route through the iPAQ and then set that route up when it gets a reply from the other laptop. The traceroute will
then proceed as it usually would.
Three computer configuration:
iPAQ: 10.1.1.1
Laptop A: 10.1.1.2
Laptop B: 10.1.1.3
Test:
I wanted to test the situation where the network was in this state:
+----------+ +--------+ +------------+
| Laptop A |--------------| iPAQ |------------| Laptop B |
+----------+ +--------+ +------------+
That is, where Laptop A and Laptop B could both talk to the iPAQ, but the Laptops could not talk directly.
This will test the ability of the routing daemon on Laptop A to send a route request message, the abiltiy of the
daemon on the iPAQ to forward it to Laptop B, and the ability of the daemon on Laptop B to generate a reply
message and send it back to Laptop A. To simulate "distance" between Laptop A and Laptop B, I simply used iptables
on each laptop to block the other's UDP traffic:
On Laptop A (10.1.1.2):
iptables -A INPUT -p udp -s 10.1.1.3 -j DROP
On Laptop B (10.1.1.3):
iptables -A INPUT -p udp -s 10.1.1.2 -j DROP
I only blocked UDP because the routing daemons use UDP to send "hello messages" to notify each other of their presence.
If UDP is blocked, these messages will not get through and subsequently a kernel route won't be created between the
laptops. Also, I didnt want to block TCP so on Laptop B I request a webpage over HTTP from Laptop A. This obviously
requires TCP. So once those rules were set, I ran arand on each machine. Laptop B then requested an webpage from
Laptop A. Laptop B realizes it doesnt have a route, so it broadcasts a request for a route to A.
The iPAQ gets it and broadcasts it further to Laptop B. Laptop B sends a reply to A and A then has a route to B
through the iPAQ. The HTTP request then goes through as usual.
With the ipables rules above, regular traceroute will not work because it uses UDP packets.
If you want to run a traceroute, you can run it like (from Laptop B):
traceroute -I -n 10.1.1.2
This is getting the hops to Laptop A. Note the '-I'. That uses ICMP echos instead of UDP datagrams.
Also note '-n'. This tells traceroute not to try to resolve IP addresses into host names. Here is the result of the traceroute:
[root@localhost root]# traceroute -I -n 10.1.1.2
traceroute to 10.1.1.2 (10.1.1.2), 30 hops max, 38 byte packets
[1] 10.1.1.1 2.686 ms 8.519 ms 9.249 ms
[2] 10.1.1.2 43.178 ms 5.848 ms 21.424 ms
[root@localhost root]#
|