chiark / gitweb /
Templates for scripts. Monitoring script. Do not depend on time of generation at...
[vinegar-ip.git] / README
diff --git a/README b/README
index 2072a74d335072fb9f69e8f5abec1c2c7003c877..dc5a83bf77bb445b3414592cf27c9bed14bdecfe 100644 (file)
--- a/README
+++ b/README
@@ -48,22 +48,26 @@ WHAT TO DO
            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).
+               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' and `recv-1.diff'.
            Read the diff and see if it's by and large working.
            See below for information about interpreting the various files.
@@ -82,9 +86,12 @@ FILES INVOLVED
        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
@@ -118,7 +125,7 @@ lines marked with `-'.  The changed numbers at the left are just the
 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:
 
    1 5  tos=0xe7 id=30130 df (!any) proto=icmp[1] \