1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
/*
* Copyright (c) 2002 - 2005 NetGroup, Politecnico di Torino (Italy)
* Copyright (c) 2005 - 2008 CACE Technologies, Davis (California)
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the Politecnico di Torino, CACE Technologies
* nor the names of its contributors may be used to endorse or promote
* products derived from this software without specific prior written
* permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/
/* Default port on which the client workstation is waiting for connections in case of active mode. */
/*
* Minimum and maximum supported versions of the protocol.
*
* If new message types are added, the protocol version MUST be changed,
* so that a client knows, from the negotiated protocol version, what
* messages can be sent to the server.
*
* If the format of an existing message type is changed, the protocol
* version MUST be changed, so that each side knows, from the negotiated
* protocol version, what format should be used.
*
* The RPCAP_MSG_ERROR format MUST not change, as it's used to, among
* other things, report "incorrect version number" errors, where, if
* the format changed, the sender of the message might not know what
* versions the recipient would understand, or might know a version
* they support (the version number they sent) but might not know
* the format of the message in that version.
*
* Other message versions SHOULD not change, as that would complicate
* the process of interpreting the message, making it version-dependent.
* Introducing a new message with a new format is preferable.
*
* Version negotiation is done as part of the authentication process:
*
* The client sends an authentication request, with the version number
* in the request being the maximum version it supports.
*
* If the server supports that version, it attempts to authenticate the
* client, and replies as appropriate, with the version number in the
* reply being that version.
*
* If the server doesn't support that version because it's too large,
* it replies with a RPCAP_MSG_ERROR message, with the maximum version
* they support as the version number in the reply, and with the error
* code being PCAP_ERR_WRONGVER.
*
* If the server doesn't support that version because it's too small,
* it replies with a RPCAP_MSG_ERROR message, with that version as
* the version number in the reply, and with the error code being
* PCAP_ERR_WRONGVER.
*
* If the client supports that version, it retries the authentication
* with that version and, if that fails for any reason, including
* PCAP_ERR_WRONGVER, fails. Otherwise, it fails, telling its caller
* that there's no version that both support.
*
* This requires that the set of versions supported by a client or
* server be a range of integers, with no gaps. Thus:
*
* the client's version set is [Cmin, Cmax], with Cmin <= Cmax;
*
* the server's version set is [Smin, Smax], with Smin <= Smax;
*
* the client sends Cmax as the version number in the initial
* authentication request;
*
* if the server doesn't support the version sent by the client,
* either Smax < Cmax or Smin > Cmax (because the client sent Cmax
* to the server, and the server doesn't support it);
*
* if Smax < Cmax:
*
* the server sends Smax as the version number in the RPCAP_MSG_ERROR/
* PCAP_ERR_WRONGVER message - the client will accept this because
* Cmax != 0, as these numbers are unsigned, and this means that
* this isn't an old client that rejects all messages with a non-zero
* version number, it's a new client that accepts RPCAP_MSG_ERROR
* messages no matter what the version is;
*
* if Smax >= Cmin, both the client and the server can use it, and
* the client retries with Smax;
*
* if Smax < Cmin, there is no version the client and server can
* both support.
*
* if Smin > Cmax:
*
* the server sends Cmax as the version number in the RPCAP_MSG_ERROR/
* PCAP_ERR_WRONGVER message - the client will accept this because
* Cmax is a valid client version number.
*
* the client will retry with Cmax, get the same version failure,
* and report that there is no version the client and server can
* both support (as the version sets are disjoint).
*
* Old negotiation-unaware clients just send version 0 and, if they
* get back PCAP_ERR_WRONGVER, treat it as a fatal error. This
* means they'll fail to talk to any server that can't handle
* version 0, which is the appropriate thing to do, as they can
* only use version 0.
*
* Old negotiation-unaware servers fail if they get a version other
* than 0, sending back PCAP_ERR_WRONGVER with version 0, which is
* the only version, and thus both the minimum and maximum version,
* they support. The client will either fail if it doesn't support
* version 0, or will retry with version 0 and succeed, so it will
* fail with servers that can't handle version 0 or will negotiate
* version 0 with servers that can handle version 0.
*/
/*
* Version numbers are unsigned, so if RPCAP_MIN_VERSION is 0, they
* are >= the minimum version, by definition; don't check against
* RPCAP_MIN_VERSION, as you may get compiler warnings that the
* comparison will always succeed.
*/
/*
* Separators used for the host list.
*
* It is used:
* - by the rpcapd daemon, when you types a list of allowed connecting hosts
* - by the rpcap client in active mode, when the client waits for incoming
* connections from other hosts
*/
/*********************************************************
* *
* Protocol messages formats *
* *
*********************************************************/
/*
* WARNING: This file defines some structures that are used to transfer
* data on the network.
* Note that your compiler MUST not insert padding into these structures
* for better alignment.
* These structures have been created in order to be correctly aligned to
* a 32-bit boundary, but be careful in any case.
*/
/*
* WARNING: These typedefs MUST be of a specific size.
* You might have to change them on your platform.
*
* XXX - use the C99 types? Microsoft's newer versions of Visual Studio
* support them.
*/
typedef unsigned char uint8; /* 8-bit unsigned integer */
typedef unsigned short uint16; /* 16-bit unsigned integer */
typedef unsigned int uint32; /* 32-bit unsigned integer */
typedef int int32; /* 32-bit signed integer */
/* Common header for all the RPCAP messages */
;
/* Format of the message for the interface description (findalldevs command) */
;
/*
* Format of an address as sent over the wire.
*
* Do *NOT* use struct sockaddr_storage, as the layout for that is
* machine-dependent.
*
* RFC 2553 gives two sample layouts, both of which are 128 bytes long,
* both of which are aligned on an 8-byte boundary, and both of which
* have 2 bytes before the address data.
*
* However, one has a 2-byte address family value at the beginning
* and the other has a 1-byte address length value and a 1-byte
* address family value; this reflects the fact that the original
* BSD sockaddr structure had a 2-byte address family value, which
* was later changed to a 1-byte address length value and a 1-byte
* address family value, when support for variable-length OSI
* network-layer addresses was added.
*
* Furthermore, Solaris's struct sockaddr_storage is 256 bytes
* long.
*
* This structure is supposed to be aligned on an 8-byte boundary;
* the message header is 8 bytes long, so we don't have to do
* anything to ensure it's aligned on that boundary within a packet,
* so we just define it as 128 bytes long, with a 2-byte address
* family. (We only support IPv4 and IPv6 addresses, which are fixed-
* length.) That way, it's the same size as sockaddr_storage on
* Windows, and it'll look like what an older Windows client will
* expect.
*
* In addition, do *NOT* use the host's AF_ value for an address,
* as the value for AF_INET6 is machine-dependent. We use the
* Windows value, so it'll look like what an older Windows client
* will expect.
*
* (The Windows client is the only one that has been distributed
* as a standard part of *pcap; UN*X clients are probably built
* from source by the user or administrator, so they're in a
* better position to upgrade an old client. Therefore, we
* try to make what goes over the wire look like what comes
* from a Windows server.)
*/
;
/*
* Format of an IPv4 address as sent over the wire.
*/
;
/*
* Format of an IPv6 address as sent over the wire.
*/
;
/* Format of the message for the address listing (findalldevs command) */
;
/*
* \brief Format of the message of the connection opening reply (open command).
*
* This structure transfers over the network some of the values useful on the client side.
*/
;
/* Format of the message that starts a remote capture (startcap command) */
;
/* Format of the reply message that devoted to start a remote capture (startcap reply command) */
;
/*
* \brief Format of the header which encapsulates captured packets when transmitted on the network.
*
* This message requires the general header as well, since we want to be able to exchange
* more information across the network in the future (for example statistics, and kind like that).
*/
;
/* General header used for the pcap_setfilter() command; keeps just the number of BPF instructions */
;
/* Structure that keeps a single BPF instuction; it is repeated 'ninsn' times according to the 'rpcap_filterbpf' header */
;
/* Structure that keeps the data required for the authentication on the remote host */
;
/* Structure that keeps the statistics about the number of packets captured, dropped, etc. */
;
/* Structure that is needed to set sampling parameters */
;
/* Messages field coding */
/* Network error codes */
/*
* \brief Buffer used by socket functions to send-receive packets.
* In case you plan to have messages larger than this value, you have to increase it.
*/
/*********************************************************
* *
* Routines used by the rpcap client and rpcap daemon *
* *
*********************************************************/
extern void ;
extern const char *;
extern int ;