1 VINEGAR-IP - INSTRUCTIONS
3 This is a tool for IP transparency testing. It allows you to send a
4 wide variety of `interesting' packets from one nominated machine to
5 another, and then examine what arrived to see if there are any
8 Up to 3 hosts are involved: one to do the test dataset generation and
9 analysis, as well as of course the sender and receiver.
14 * On the machine you generate and analyse the test data
15 This Makefile and corresponding scripts
17 Tcl (as /usr/bin/tclsh)
18 Perl (as /usr/bin/perl)
19 OpenSSL (as `openssl' on PATH)
20 tcpdump for converting trace files only, no root privilege
21 GNU diff to look at the output
22 Lots of CPU ! (the generation script is rather slow)
24 * On the sending machine
25 tcpreplay (http://www.subterrain.net/tools/tcpreplay/,
26 or from Debian testing 3.5.2002. I used 1.0.1-1.1)
27 and root privilege to run it
29 * On the receiving machine
30 tcpdump for packet capture, and root privilege to run it
31 The `on-dest.sh' script that this Makefile creates
33 It will be much better if the source and destination machines do not
34 have any other traffic. If they do the tests may disrupt it, and
35 it'll get in the way of your analysis too.
40 1. Generate the test data.
42 You /must/ change SOURCE and DEST (or override them on
43 the `make' command line, if you prefer); they must be
44 <IPv4-address>/<ethernet-address>
45 You may also change PARTS, PERPART or MTU if you like.
46 * Say `make -j2 all'. This will generate the test data sets.
47 This will take a while. Vary the -j for your system.
48 If you want to do a quick test first, you can say
49 `make few' first, instead.
50 * Copy send-1.pcap and send-all.pcap to the sending machine.
51 * Copy on-dest.sh and monitor.sh to the to the receiving machine.
53 2. Run the first, small test
54 * On the receiving machine, say, as root,
55 ./on-dest.sh 1 [-i <interface>]
56 and leave it running. Also, in a nice big window, say
57 ./monitor.sh [-i <interface>]
58 and leave that running too. The default interface is
59 the one that tcpdump picks by default.
60 * On the sending machine, say, as root,
61 tcpreplay -m 1 <send-1.pcap [-i <interface>]
62 You should see the results in your monitoring window.
63 This will take (by default) 100 seconds. The -m 1 option
64 makes tcpreplay send the packets at one a second (they are
65 generated as if they were captured at one a second); this
66 avoids flooding the network, which causes congestion,
67 packet loss and maybe other randomness.
68 * When it has finished, kill on-dest.sh and monitor.sh.
69 Copy the file recv-1.pcap back to your analysis machine, and
70 there say `make anal'.
71 * This will generate `recv-1.log' and `recv-1.diff'.
72 Read the diff and see if it's by and large working.
73 See below for information about interpreting the various files.
76 Do the same as step 2, but instead of `1', say `all'
81 Those made by `make generate':
82 send-X.pcap `pcap' format raw test data files
83 (feed this to tcpreplay -m 1)
84 send-X.log tcpdump's interpretation of the test data
85 with line numbers added
86 send-X.why The generator's explanations (ha ha) of
88 on-dest.sh Script for running tcpdump on the destination
89 to capture the packets as they come in
90 monitor.sh Script for running tcpdump on either end
91 for monitoring how it's going
92 You really want to be paying attention to the ones where
93 X is `1' and `all'. `all' contains all the numbered parts,
94 and it'll be easier to do them all at once.
96 Those supposedly captured at the destination
97 recv-X.pcap `pcap' format raw received packets
99 Those made during the analysis:
100 recv-X.log tcpdump's interpretation of the received packets
101 recv-X.diff difference between send-*.log and recv-*.log
104 INTERPRETATION OF THE TEXT FILES - EXAMPLE
106 Here is an example of a diff you might see:
109 453e 001c f194 0000 ff02 17bf ac12 2d23
110 ac12 2d06 1029 36f1 7daa 3b3b 0000 0000
111 0000 0000 0000 0000 0000 0000 0000
113 - 172.18.45.35 > 172.18.45.6: icmp: type-#75 (DF) [tos 0xe7] (ttl 255, id 30130)
114 - 45e7 0023 75b2 4000 ff01 52f2 ac12 2d23
115 - ac12 2d06 4b8c 34ba 4844 ce2d 1bde 5caf
116 - 0ab9 e600 0000 0000 0000 0000 0000
119 172.18.45.35.21814 > 172.18.45.6.21814: udp 12 (ttl 255, id 26421)
120 4500 0028 6735 0000 ff11 a241 ac12 2d23
122 This means that a packet which was sent, was not received. You can
123 see the actual hex contents, and tcpdump's interpretation, in the
124 lines marked with `-'. The changed numbers at the left are just the
125 packet numbers. You can use the numbers marked with `-' to find the
126 corresponding packet in the other files. Ignore the numbers marked
127 with `+', they aren't useful. In this case, it's packet 5 that's
128 missing. So, we can look in send-1.why or send-all.why, as
129 appropriate, and see this:
131 1 5 tos=0xe7 id=30130 df (!any) proto=icmp[1] \
132 (any) type=75 (junk) l=11 code=140
133 45e7002375b24000ff0152f2ac122d23ac122d064b8c34ba4844ce2d1bde5caf0ab9e6
135 In send-all.why, these are prepended by another line number, which is
136 the one you should use, so it would look like this:
138 5 1 5 tos=0xe7 id=30130 df (!any) proto=icmp[1] \
139 (any) type=75 (junk) l=11 code=140
140 45e7002375b24000ff0152f2ac122d23ac122d064b8c34ba4844ce2d\
143 (The other two numbers are the batch and line within the batch.
144 I have wrapped this here with \ and some indentation for ease of
147 You can see the hex dump of the packet, which is the same as the one
148 in the tcpdump output, except that the tcpdump one has some extra
149 padding with zeroes to bring it to the minimum ethernet frame size.
150 You can also see some notes that the generator made:
152 tos=0xe7 id=30130 The IP TOS and ID
153 df The Don't Fragment flag was set (there would
154 be `frag' here if it was fragmented)
155 (!any) It picked a known next layer up [`(!any)']
156 proto=icmp[1] and the one it picked was protocol 1, icmp
157 (any) type=75 It picked an unknown next layer up, icmp type no.75
158 (junk) l=11 and gave it 11 bytes of junk payload
159 code=140 and an icmp code value of 140
162 Some more examples from send-*.why and send-*.log files:
164 17 2 7 tos=0x14 id=56320 !df (!any) proto=tcp[6] source_port=37365 \
165 dest_port=52759 (connect) seq=0xab57703f ack=0x6c55ec70 \
166 window=0xdd21 !p u urg=0xce6c (noopt) (!optxpad) !unexpdata \
169 172.18.45.35.37365 > 172.18.45.6.52759: S 2874634303:2874634303(0) \
170 win 56609 urg 52844 [tos 0x14] (ttl 255, id 56320)
172 This is a TCP SYN packet with urgent data, . However, it has been
173 generated with an invalid checksum: the checksum in the packet has
174 been XOR'd with 0x9a18.
176 59 6 9 tos=0x2f id=15886 !df (!any) proto=tcp[6] source_port=52650 \
177 dest_port=37162 (data) seq=0xec912ceb ack=0x8cd28874 \
178 window=1 !p !u urg=0xe427 (badopt) l=30 l=12
180 172.18.45.35.52650 > 172.18.45.6.37162: . 3968937195:3968937207(12) \
181 ack 2362607732 win 1 <[bad opt]> [tos 0x2f] (ttl 255, id 15886)
183 More TCP. This time it's a data packet. The urgent flag isn't set
184 (though the urgent pointer value is nonzero), and it has 30 bytes of
185 invalid option data and 12 bytes of actual data.
187 134 7 14 tos=0x4e id=12035 df (!any) proto=ip[4] \
188 source=206.78.180.32 dest=252.75.191.229 \
189 tos=0x94 id=14197 df (!any) proto=udp[17] (reply) \
190 port=remailck[50] port=20463 (resp-auth) auth=0xabcf
192 172.18.45.35 > 172.18.45.6: 206.78.180.32.50 > 252.75.191.229.20463: \
193 udp 12 (DF) [tos 0x94] (ttl 255, id 14197) (DF) \
194 [tos 0x4e] (ttl 255, id 12035)
196 IPv4 tunnelling. The outer packet has TOS 4e and ID 12035. Both The
197 inner packet is a reply from a UDP service `(reply)' from a well-known
198 port to a random port. The packet is according to the RFC1339 mail
199 check service on port 50, requesting authorisation from the client;
200 the server's authorisations' supported bitmap is allegedly 0xabcf.
202 15 1 15 tos=0x5b id=61344 df (!any) proto=udp[17] (random) \
203 port=20500 port=11701 l=2
205 172.18.45.35.20500 > 172.18.45.6.11701: udp 2 (DF) [tos 0x5b] \
208 This is a generic UDP packet from one random port (20500 in this case)
209 to another (11701). It has 2 bytes of data.
211 59 3 19 tos=0xa0 id=36385 !df (!any) proto=udp[17] (servers) \
212 port=dhcpserv[67] (!any) op=reply[2] (!any) htype=ethernet[1] \
213 hops=88 xid=0xd31e0dfe secs=149 flags=0x80 \
214 ciaddr=70.114.113.11 yiaddr=38.225.152.221 \
215 siaddr=98.91.71.52 giaddr=128.20.46.24 \
216 sname="yc3g27vvukig44qsx8lpud4e1.dbxxidju2ok3kipebqkd.pd2x\
217 89rdmrfz1dr" file="/o.h22gsn7s44yq2llx.v_-a+s_f421_iijnroam\
218 krpm7b674t7w.y3lfw8immrjaqpsu7.a.x.nev+j3hi/" (nocsum)
220 This is a UDP packet between well-known ports `(servers)'; the
221 generator only generates such packets with identical source and
222 destination ports, in this case the DHCP server port. (Usually DHCP
223 servers would talk to clients, not to each oehter.) There is a DHCP
224 packet whose details you can see. `(nocsum)' indicates that the UDP
225 checksum field in the UDP header is set to 0, indicating that no
226 checksum is to be performed.
229 # This file is part of vinegar-ip, tools for IP transparency testing.
230 # vinegar-ip is Copyright (C) 2002 Ian Jackson
232 # This program is free software; you can redistribute it and/or modify
233 # it under the terms of the GNU General Public License as published by
234 # the Free Software Foundation; either version 2, or (at your option)
237 # This program is distributed in the hope that it will be useful,
238 # but WITHOUT ANY WARRANTY; without even the implied warranty of
239 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
240 # GNU General Public License for more details.
242 # You should have received a copy of the GNU General Public License
243 # along with this program; if not, write to the Free Software Foundation,
244 # Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.