You /must/ change SOURCE and DEST (or override them on
the `make' command line, if you prefer); they must be
<IPv4-address>/<ethernet-address>
+ The destination ethernet address should be the address
+ of your next hop *router*, while the destination IPv4
+ address should be that of the destination machine.
You may also change PARTS, PERPART or MTU if you like.
* Say `make -j2 all'. This will generate the test data sets.
This will take a while. Vary the -j for your system.
If you want to do a quick test first, you can say
`make few' first, instead.
* Copy send-1.pcap and send-all.pcap to the sending machine.
- * Copy on-dest.sh to the to the receiving machine.
+ * Copy on-dest.sh and monitor.sh to the to the receiving machine.
2. Run the first, small test
* On the receiving machine, say, as root,
- ./on-dest.sh 1
- and leave it running.
+ ./on-dest.sh 1 [-i <interface>]
+ and leave it running. Also, in a nice big window, say
+ ./monitor.sh [-i <interface>]
+ and leave that running too. The default interface is
+ the one that tcpdump picks by default.
* On the sending machine, say, as root,
- tcpreplay -m 1 <send-1.pcap
- The -m 1 option makes tcpreplay send the packets at one a
- second (they are generated as if they were captured at one
- a second); this avoids flooding the network, which causes
- congestion, packet loss and maybe other randomness.
- This will take (by default) 100 seconds.
- * When it has finished, kill on-dest.sh. Copy the
- file recv-1.pcap back to your analysis machine, and
- there say `make analyse' (or `make anal' if you prefer).
- * This will generate `recv-1.log' and `recv-1.diff'.
- Read the diff and see if it's by and large working.
+ tcpreplay -m 1 <send-1.pcap [-i <interface>]
+ You should see the results in your monitoring window.
+ This will take (by default) 100 seconds. The -m 1 option
+ makes tcpreplay send the packets at one a second (they are
+ generated as if they were captured at one a second); this
+ avoids flooding the network, which causes congestion,
+ packet loss and maybe other randomness.
+ * When it has finished, kill on-dest.sh and monitor.sh.
+ Copy the file recv-1.pcap back to your analysis machine, and
+ there say `make anal'.
+ * This will generate
+ recv-1.log recv-1.diff recv-1.mdiff recv-1.summary
+ Read the diffs and see if it's by and large working.
See below for information about interpreting the various files.
3. Run the full test
send-X.why The generator's explanations (ha ha) of
what the test data is
on-dest.sh Script for running tcpdump on the destination
+ to capture the packets as they come in
+ monitor.sh Script for running tcpdump on either end
+ for monitoring how it's going
You really want to be paying attention to the ones where
- X is `1' and `all'. The others, 2 onwards, are all in
- `all' and it'll be easier to take them all at once.
+ X is `1' and `all'. `all' contains all the numbered parts,
+ and it'll be easier to do them all at once.
Those supposedly captured at the destination
recv-X.pcap `pcap' format raw received packets
INTERPRETATION OF THE TEXT FILES - EXAMPLE
+
+You probably want to start with the recv-*.summary files. Here's an
+example line (folded and indented here to make it easier to read:
+
+-7 80.4.4.56 > 212.22.195.1: 6.115.30.33.50 > 158.55.15.27.50: \
+ udp 37 (DF) [tos 0xaf] (ttl 255, id 55590) [tos 0x62] (ttl ###, id 21803)
+
+This means that packet no.7 either the packet didn't arrive, or
+tcpdump produced different a summary line for the second packet.
+The *.summary file is sorted crudely by the type of packet.
+
+The recv-*.summary and recv-*.mdiff files DO NOT contain information
+about packets whose bodies changed, unless tcpdump reported the change
+in its summary. recv-*.diff contains ALL changes, even to meaningless
+parts of packets, except changes to the IP TTL and IP header checksum
+(which are expected to change).
+
+So, you can then look in recv-1.mdiff and recv-1.diff for more
+information about packet no.7, if you're interested. See below for
+help on interpreting the diffs.
+
+
Here is an example of a diff you might see:
@@ -23,12 +15,7 @@
packet numbers. You can use the numbers marked with `-' to find the
corresponding packet in the other files. Ignore the numbers marked
with `+', they aren't useful. In this case, it's packet 5 that's
-missing. So, we can look in send-1.why or send-rest.why, as
+missing. So, we can look in send-1.why or send-all.why, as
appropriate, and see this:
+batch packet within batch
+ | /
1 5 tos=0xe7 id=30130 df (!any) proto=icmp[1] \
(any) type=75 (junk) l=11 code=140
45e7002375b24000ff0152f2ac122d23ac122d064b8c34ba4844ce2d1bde5caf0ab9e6
-In send-all.why, these are prepended by another line number, which is
-the one you should use, so it would look like this:
+or this:
+ batch packet within batch
+ | /
5 1 5 tos=0xe7 id=30130 df (!any) proto=icmp[1] \
- (any) type=75 (junk) l=11 code=140
- 45e7002375b24000ff0152f2ac122d23ac122d064b8c34ba4844ce2d\
- 1bde5caf0ab9e6
-
-(The other two numbers are the batch and line within the batch.
-I have wrapped this here with \ and some indentation for ease of
-reading.)
+ / (any) type=75 (junk) l=11 code=140
+ overall 45e7002375b24000ff0152f2ac122d23ac122d064b8c34ba4844ce2d\
+ packet no. 1bde5caf0ab9e6
You can see the hex dump of the packet, which is the same as the one
in the tcpdump output, except that the tcpdump one has some extra
~ianmdlvl / vinegar-ip.git / blobdiff