1This file is a HOWTO for Wireshark developers. It describes general development
2and coding practices for contributing to Wireshark no matter which part of
3Wireshark you want to work on.
4
5To learn how to write a dissector, read this first, then read the file
6README.dissector.
7
8This file is compiled to give in depth information on Wireshark.
9It is by no means all inclusive and complete. Please feel free to send
10remarks and patches to the developer mailing list.
11
120. Prerequisites.
13
14Before starting to develop a new dissector, a "running" Wireshark build
15environment is required - there's no such thing as a standalone "dissector
16build toolkit".
17
18How to setup such an environment is platform dependent; detailed
19information about these steps can be found in the "Developer's Guide"
20(available from: https://www.wireshark.org) and in the INSTALL and
21README.md files of the sources root dir.
22
230.1. General README files.
24
25You'll find additional information in the following README files:
26
27- README.capture - the capture engine internals
28- README.design - Wireshark software design - incomplete
29- README.developer - this file
30- README.dissector - How to dissect a packet
31- README.display_filter - Display Filter Engine
32- README.idl2wrs - CORBA IDL converter
33- README.packaging - how to distribute a software package containing WS
34- README.regression - regression testing of WS and TS
35- README.stats_tree - a tree statistics counting specific packets
36- README.tapping - "tap" a dissector to get protocol specific events
37- README.xml-output - how to work with the PDML exported output
38- wiretap/README.developer - how to add additional capture file types to
39 Wiretap
40
410.2. Dissector related README files.
42
43You'll find additional dissector related information in the file
44README.dissector as well as the following README files:
45
46- README.heuristic - what are heuristic dissectors and how to write them
47- README.plugins - how to "pluginize" a dissector
48- README.request_response_tracking - how to track req./resp. times and such
49- README.wmem - how to obtain "memory leak free" memory
50
510.3 Contributors
52
53James Coe <jammer[AT]cin.net>
54Gilbert Ramirez <gram[AT]alumni.rice.edu>
55Jeff Foster <jfoste[AT]woodward.com>
56Olivier Abad <oabad[AT]cybercable.fr>
57Laurent Deniel <laurent.deniel[AT]free.fr>
58Gerald Combs <gerald[AT]wireshark.org>
59Guy Harris <guy[AT]alum.mit.edu>
60Ulf Lamping <ulf.lamping[AT]web.de>
61
621. Portability.
63
64Wireshark runs on many platforms, and can be compiled with a number of
65different compilers; here are some rules for writing code that will work
66on multiple platforms.
67
68In general, not all C99 features can be used since some C compilers used to
69compile Wireshark, such as Microsoft's C compiler, don't support all C99
70features. The C99 features that can be used are:
71
72 - flexible array members
73 - compound literals
74 - designated initializers
75 - "//" comments
76 - mixed declarations and code
77 - new block scopes for selection and iteration statements (that is, declaring
78 the type in a for-loop like: for (int i = 0; i < n; i++) ;)
79 - macros with a variable number of arguments (variadic macros)
80 - trailing comma in enum declarations
81 - inline functions (guaranteed only by use of glib.h)
82
83Don't initialize global or static variables (variables with static
84storage duration) in their declaration with non-constant values. Not
85all compilers support this. E.g., if "i" is a static or global
86variable, don't declare "i" as
87
88 guint32 i = somearray[2];
89
90outside a function, or as
91
92 static guint32 i = somearray[2];
93
94inside or outside a function, declare it as just
95
96 guint32 i;
97
98or
99
100 static guint32 i;
101
102and later, in code, initialize it with
103
104 i = somearray[2];
105
106instead. Initializations of variables with automatic storage duration -
107i.e., local variables - with non-constant values is permitted, so,
108within a function
109
110 guint32 i = somearray[2];
111
112is allowed.
113
114Don't use zero-length arrays as structure members, use flexible array members
115instead.
116
117Don't use anonymous unions; not all compilers support them.
118Example:
119
120 typedef struct foo {
121 guint32 foo;
122 union {
123 guint32 foo_l;
124 guint16 foo_s;
125 } u; /* have a name here */
126 } foo_t;
127
128Don't use "uchar", "u_char", "ushort", "u_short", "uint", "u_int",
129"ulong", "u_long" or "boolean"; they aren't defined on all platforms.
130If you want an 8-bit unsigned quantity, use "guint8"; if you want an
1318-bit character value with the 8th bit not interpreted as a sign bit,
132use "guchar"; if you want a 16-bit unsigned quantity, use "guint16";
133if you want a 32-bit unsigned quantity, use "guint32"; and if you want
134an "int-sized" unsigned quantity, use "guint"; if you want a boolean,
135use "gboolean". Use "%d", "%u", "%x", and "%o" to print those types;
136don't use "%ld", "%lu", "%lx", or "%lo", as longs are 64 bits long on
137many platforms, but "guint32" is 32 bits long.
138
139Don't use "long" to mean "signed 32-bit integer", and don't use
140"unsigned long" to mean "unsigned 32-bit integer"; "long"s are 64 bits
141long on many platforms. Use "gint32" for signed 32-bit integers and use
142"guint32" for unsigned 32-bit integers.
143
144Don't use "long" to mean "signed 64-bit integer" and don't use "unsigned
145long" to mean "unsigned 64-bit integer"; "long"s are 32 bits long on
146many other platforms. Don't use "long long" or "unsigned long long",
147either, as not all platforms support them; use "gint64" or "guint64",
148which will be defined as the appropriate types for 64-bit signed and
149unsigned integers.
150
151On LLP64 data model systems (notably 64-bit Windows), "int" and "long"
152are 32 bits while "size_t" and "ptrdiff_t" are 64 bits. This means that
153the following will generate a compiler warning:
154
155 int i;
156 i = strlen("hello, sailor"); /* Compiler warning */
157
158Normally, you'd just make "i" a size_t. However, many GLib and Wireshark
159functions won't accept a size_t on LLP64:
160
161 size_t i;
162 char greeting[] = "hello, sailor";
163 guint byte_after_greet;
164
165 i = strlen(greeting);
166 byte_after_greet = tvb_get_guint8(tvb, i); /* Compiler warning */
167
168Try to use the appropriate data type when you can. When you can't, you
169will have to cast to a compatible data type, e.g.
170
171 size_t i;
172 char greeting[] = "hello, sailor";
173 guint byte_after_greet;
174
175 i = strlen(greeting);
176 byte_after_greet = tvb_get_guint8(tvb, (gint) i); /* OK */
177
178or
179
180 gint i;
181 char greeting[] = "hello, sailor";
182 guint byte_after_greet;
183
184 i = (gint) strlen(greeting);
185 byte_after_greet = tvb_get_guint8(tvb, i); /* OK */
186
187See http://www.unix.org/version2/whatsnew/lp64_wp.html for more
188information on the sizes of common types in different data models.
189
190When printing or displaying the values of 64-bit integral data types,
191don't use "%lld", "%llu", "%llx", or "%llo" - not all platforms
192support "%ll" for printing 64-bit integral data types. Instead, for
193GLib routines, and routines that use them, such as all the routines in
194Wireshark that take format arguments, use G_GINT64_MODIFIER, for example:
195
196 proto_tree_add_uint64_format_value(tree, hf_uint64, tvb, offset, len,
197 val, "%" G_GINT64_MODIFIER "u", val);
198
199When specifying an integral constant that doesn't fit in 32 bits, don't
200use "LL" at the end of the constant - not all compilers use "LL" for
201that. Instead, put the constant in a call to the "G_GINT64_CONSTANT()"
202macro, e.g.
203
204 G_GINT64_CONSTANT(-11644473600), G_GUINT64_CONSTANT(11644473600)
205
206rather than
207
208 -11644473600LL, 11644473600ULL
209
210Don't assume that you can scan through a va_list initialized by va_start
211more than once without closing it with va_end and re-initializing it with
212va_start. This applies even if you're not scanning through it yourself,
213but are calling a routine that scans through it, such as vfprintf() or
214one of the routines in Wireshark that takes a format and a va_list as an
215argument. You must do
216
217 va_start(ap, format);
218 call_routine1(xxx, format, ap);
219 va_end(ap);
220 va_start(ap, format);
221 call_routine2(xxx, format, ap);
222 va_end(ap);
223
224rather
225 va_start(ap, format);
226 call_routine1(xxx, format, ap);
227 call_routine2(xxx, format, ap);
228 va_end(ap);
229
230Don't use a label without a statement following it. For example,
231something such as
232
233 if (...) {
234
235 ...
236
237 done:
238 }
239
240will not work with all compilers - you have to do
241
242 if (...) {
243
244 ...
245
246 done:
247 ;
248 }
249
250with some statement, even if it's a null statement, after the label.
251
252Don't use "bzero()", "bcopy()", or "bcmp()"; instead, use the ANSI C
253routines
254
255 "memset()" (with zero as the second argument, so that it sets
256 all the bytes to zero);
257
258 "memcpy()" or "memmove()" (note that the first and second
259 arguments to "memcpy()" are in the reverse order to the
260 arguments to "bcopy()"; note also that "bcopy()" is typically
261 guaranteed to work on overlapping memory regions, while
262 "memcpy()" isn't, so if you may be copying from one region to a
263 region that overlaps it, use "memmove()", not "memcpy()" - but
264 "memcpy()" might be faster as a result of not guaranteeing
265 correct operation on overlapping memory regions);
266
267 and "memcmp()" (note that "memcmp()" returns 0, 1, or -1, doing
268 an ordered comparison, rather than just returning 0 for "equal"
269 and 1 for "not equal", as "bcmp()" does).
270
271Not all platforms necessarily have "bzero()"/"bcopy()"/"bcmp()", and
272those that do might not declare them in the header file on which they're
273declared on your platform.
274
275Don't use "index()" or "rindex()"; instead, use the ANSI C equivalents,
276"strchr()" and "strrchr()". Not all platforms necessarily have
277"index()" or "rindex()", and those that do might not declare them in the
278header file on which they're declared on your platform.
279
280Don't use "tvb_get_ptr()". If you must use it, keep in mind that the pointer
281returned by a call to "tvb_get_ptr()" is not guaranteed to be aligned on any
282particular byte boundary; this means that you cannot safely cast it to any
283data type other than a pointer to "char", "unsigned char", "guint8", or other
284one-byte data types. Casting a pointer returned by tvb_get_ptr() into any
285multi-byte data type or structure may cause crashes on some platforms (even
286if it does not crash on x86-based PCs). Even if such mis-aligned accesses
287don't crash on your platform they will be slower than properly aligned
288accesses would be. Furthermore, the data in a packet is not necessarily in
289the byte order of the machine on which Wireshark is running. Use the tvbuff
290routines to extract individual items from the packet, or, better yet, use
291"proto_tree_add_item()" and let it extract the items for you.
292
293Don't use structures that overlay packet data, or into which you copy
294packet data; the C programming language does not guarantee any
295particular alignment of fields within a structure, and even the
296extensions that try to guarantee that are compiler-specific and not
297necessarily supported by all compilers used to build Wireshark. Using
298bitfields in those structures is even worse; the order of bitfields
299is not guaranteed.
300
301Don't use "ntohs()", "ntohl()", "htons()", or "htonl()"; the header
302files required to define or declare them differ between platforms, and
303you might be able to get away with not including the appropriate header
304file on your platform but that might not work on other platforms.
305Instead, use "g_ntohs()", "g_ntohl()", "g_htons()", and "g_htonl()";
306those are declared by <glib.h>, and you'll need to include that anyway,
307as Wireshark header files that all dissectors must include use stuff from
308<glib.h>.
309
310Don't fetch a little-endian value using "tvb_get_ntohs() or
311"tvb_get_ntohl()" and then using "g_ntohs()", "g_htons()", "g_ntohl()",
312or "g_htonl()" on the resulting value - the g_ routines in question
313convert between network byte order (big-endian) and *host* byte order,
314not *little-endian* byte order; not all machines on which Wireshark runs
315are little-endian, even though PCs are. Fetch those values using
316"tvb_get_letohs()" and "tvb_get_letohl()".
317
318Do not use "open()", "rename()", "mkdir()", "stat()", "unlink()", "remove()",
319"fopen()", "freopen()" directly. Instead use "ws_open()", "ws_rename()",
320"ws_mkdir()", "ws_stat()", "ws_unlink()", "ws_remove()", "ws_fopen()",
321"ws_freopen()": these wrapper functions change the path and file name from
322UTF8 to UTF16 on Windows allowing the functions to work correctly when the
323path or file name contain non-ASCII characters.
324
325Also, use ws_read(), ws_write(), ws_lseek(), ws_dup(), ws_fstat(), and
326ws_fdopen(), rather than read(), write(), lseek(), dup(), fstat(), and
327fdopen() on descriptors returned by ws_open().
328
329Those functions are declared in <wsutil/file_util.h>; include that
330header in any code that uses any of those routines.
331
332When opening a file with "ws_fopen()", "ws_freopen()", or "ws_fdopen()", if
333the file contains ASCII text, use "r", "w", "a", and so on as the open mode
334- but if it contains binary data, use "rb", "wb", and so on. On
335Windows, if a file is opened in a text mode, writing a byte with the
336value of octal 12 (newline) to the file causes two bytes, one with the
337value octal 15 (carriage return) and one with the value octal 12, to be
338written to the file, and causes bytes with the value octal 15 to be
339discarded when reading the file (to translate between C's UNIX-style
340lines that end with newline and Windows' DEC-style lines that end with
341carriage return/line feed).
342
343In addition, that also means that when opening or creating a binary
344file, you must use "ws_open()" (with O_CREAT and possibly O_TRUNC if the
345file is to be created if it doesn't exist), and OR in the O_BINARY flag,
346even on UN*X - O_BINARY is defined by <wsutil/file_util.h> as 0 on UN*X.
347
348Do not include <unistd.h>, <fcntl.h>, or <io.h> to declare any of the
349routines listed as replaced by routines in <wsutil/file_util.h>;
350instead, just include <wsutil/file_util.h>.
351
352If you need the declarations of other functions defined by <unistd.h>,
353don't include it without protecting it with
354
355 #ifdef HAVE_UNISTD_H
356
357 ...
358
359 #endif
360
361Don't use forward declarations of static arrays without a specified size
362in a fashion such as this:
363
364 static const value_string foo_vals[];
365
366 ...
367
368 static const value_string foo_vals[] = {
369 { 0, "Red" },
370 { 1, "Green" },
371 { 2, "Blue" },
372 { 0, NULL }
373 };
374
375as some compilers will reject the first of those statements. Instead,
376initialize the array at the point at which it's first declared, so that
377the size is known.
378
379For #define names and enum member names, prefix the names with a tag so
380as to avoid collisions with other names - this might be more of an issue
381on Windows, as it appears to #define names such as DELETE and
382OPTIONAL.
383
384Don't use the "positional parameters" extension that many UNIX printf's
385implement, e.g.:
386
387 snprintf(add_string, 30, " - (%1$d) (0x%1$04x)", value);
388
389as not all UNIX printf's implement it, and Windows printf doesn't appear
390to implement it. Use something like
391
392 snprintf(add_string, 30, " - (%d) (0x%04x)", value, value);
393
394instead.
395
396Don't use
397
398 case N ... M:
399
400as that's not supported by all compilers.
401
402Prefer the C99 output functions from <stdio.h> instead of their GLib
403replacements (note that positional format parameters are not part of C99).
404In the past we used to recommend using g_snprintf() and g_vsnprintf()
405instead but since Visual Studio 2015 native C99 implementations are
406available on all platforms we support. These are optimized better than
407the gnulib (GLib) implementation and on hot codepaths that can be a
408noticeable difference in execution speed.
409
410tmpnam() -> mkstemp()
411tmpnam is insecure and should not be used any more. Wireshark brings its
412own mkstemp implementation for use on platforms that lack mkstemp.
413Note: mkstemp does not accept NULL as a parameter.
414
415Wireshark requires minimum versions of each of the libraries it uses, in
416particular GLib 2.32.0 and Qt 5.3.0 or newer. If you require a mechanism
417that is available only in a newer version of a library then use its
418version detection macros, e.g. "#if GLIB_CHECK_VERSION(...)" and "#if
419QT_VERSION_CHECK(...)" to conditionally compile code using that
420mechanism.
421
422When different code must be used on UN*X and Win32, use a #if or #ifdef
423that tests _WIN32, not WIN32. Try to write code portably whenever
424possible, however; note that there are some routines in Wireshark with
425platform-dependent implementations and platform-independent APIs, such
426as the routines in epan/filesystem.c, allowing the code that calls it to
427be written portably without #ifdefs.
428
429Wireshark uses Libgcrypt as general-purpose crypto library. To use it from
430your dissector, do not include gcrypt.h directly, but use the wrapper file
431wsutil/wsgcrypt.h instead.
432
4332. String handling
434
435Do not use functions such as strcat() or strcpy().
436A lot of work has been done to remove the existing calls to these functions and
437we do not want any new callers of these functions.
438
439Instead use snprintf() since that function will if used correctly prevent
440buffer overflows for large strings.
441
442Be sure that all pointers passed to %s specifiers in format strings are non-
443NULL. Some implementations will automatically replace NULL pointers with the
444string "(NULL)", but most will not.
445
446When using a buffer to create a string, do not use a buffer stored on the stack.
447I.e. do not use a buffer declared as
448
449 char buffer[1024];
450
451instead allocate a buffer dynamically using the string-specific or plain wmem
452routines (see README.wmem) such as
453
454 wmem_strbuf_t *strbuf;
455 strbuf = wmem_strbuf_new(pinfo->pool, "");
456 wmem_strbuf_append_printf(strbuf, ...
457
458or
459
460 char *buffer=NULL;
461 ...
462 #define MAX_BUFFER 1024
463 buffer=wmem_alloc(pinfo->pool, MAX_BUFFER);
464 buffer[0]='\0';
465 ...
466 snprintf(buffer, MAX_BUFFER, ...
467
468This avoids the stack from being corrupted in case there is a bug in your code
469that accidentally writes beyond the end of the buffer.
470
471
472If you write a routine that will create and return a pointer to a filled in
473string and if that buffer will not be further processed or appended to after
474the routine returns (except being added to the proto tree),
475do not preallocate the buffer to fill in and pass as a parameter instead
476pass a pointer to a pointer to the function and return a pointer to a
477wmem-allocated buffer that will be automatically freed. (see README.wmem)
478
479I.e. do not write code such as
480 static void
481 foo_to_str(char *string, ... ){
482 <fill in string>
483 }
484 ...
485 char buffer[1024];
486 ...
487 foo_to_str(buffer, ...
488 proto_tree_add_string(... buffer ...
489
490instead write the code as
491 static void
492 foo_to_str(char **buffer, ...
493 #define MAX_BUFFER x
494 *buffer=wmem_alloc(pinfo->pool, MAX_BUFFER);
495 <fill in *buffer>
496 }
497 ...
498 char *buffer;
499 ...
500 foo_to_str(&buffer, ...
501 proto_tree_add_string(... *buffer ...
502
503Use wmem_ allocated buffers. They are very fast and nice. These buffers are all
504automatically free()d when the dissection of the current packet ends so you
505don't have to worry about free()ing them explicitly in order to not leak memory.
506Please read README.wmem.
507
508Source files can use UTF-8 encoding, but characters outside the ASCII
509range should be used sparingly. It should be safe to use non-ASCII
510characters in comments and strings, but some compilers (such as GCC
511versions prior to 10) may not support extended identifiers very well.
512There is also no guarantee that a developer's text editor will interpret
513the characters the way you intend them to be interpreted.
514
515The majority of Wireshark encodes strings as UTF-8. The main exception
516is the code that uses the Qt API, which uses UTF-16. Console output is
517UTF-8, but as with the source code extended characters should be used
518sparingly since some consoles (most notably Windows' cmd.exe) have
519limited support for UTF-8.
520
5213. Robustness.
522
523Wireshark is not guaranteed to read only network traces that contain correctly-
524formed packets. Wireshark is commonly used to track down networking
525problems, and the problems might be due to a buggy protocol implementation
526sending out bad packets.
527
528Therefore, code does not only have to be able to handle
529correctly-formed packets without, for example, crashing or looping
530infinitely, they also have to be able to handle *incorrectly*-formed
531packets without crashing or looping infinitely.
532
533Here are some suggestions for making code more robust in the face
534of incorrectly-formed packets:
535
536Do *NOT* use "ws_assert()" or "ws_assert_not_reached()" with input data in dissectors.
537*NO* value in a packet's data should be considered "wrong" in the sense
538that it's a problem with the dissector if found; if it cannot do
539anything else with a particular value from a packet's data, the
540dissector should put into the protocol tree an indication that the
541value is invalid, and should return. The "expert" mechanism should be
542used for that purpose.
543
544Use assertions to catch logic errors in your program. A failed assertion
545indicates a bug in the code. Use ws_assert() instead of g_assert() to
546test a logic condition. Note that ws_assert() will be removed with
547WS_DISABLE_ASSERT. Therefore assertions should not have any side-effects,
548otherwise the program may behave inconsistently.
549
550Use ws_assert_not_reached() instead of g_assert_not_reached() for
551unreachable error conditions. For example if (and only if) you know
552'myvar' can only have the values 1 and 2 do:
553 switch(myvar) {
554 case 1:
555 (...)
556 break;
557 case 2:
558 (...)
559 break;
560 default:
561 ws_assert_not_reached();
562 break;
563 }
564
565For dissectors use DISSECTOR_ASSERT() and DISSECTOR_ASSERT_NOT_REACHED()
566instead, with the same caveats as above.
567
568You should continue to use g_assert_true(), g_assert_cmpstr(), etc for
569"test code", such as unit testing. These assertions are always active.
570See the GLib Testing API documentation for the details on each of those
571functions.
572
573If there is a case where you are checking not for an invalid data item
574in the packet, but for a bug in the dissector (for example, an
575assumption being made at a particular point in the code about the
576internal state of the dissector), use the DISSECTOR_ASSERT macro for
577that purpose; this will put into the protocol tree an indication that
578the dissector has a bug in it, and will not crash the application.
579
580If you are allocating a chunk of memory to contain data from a packet,
581or to contain information derived from data in a packet, and the size of
582the chunk of memory is derived from a size field in the packet, make
583sure all the data is present in the packet before allocating the buffer.
584Doing so means that:
585
586 1) Wireshark won't leak that chunk of memory if an attempt to
587 fetch data not present in the packet throws an exception.
588
589and
590
591 2) it won't crash trying to allocate an absurdly-large chunk of
592 memory if the size field has a bogus large value.
593
594If you're fetching into such a chunk of memory a string from the buffer,
595and the string has a specified size, you can use "tvb_get_*_string()",
596which will check whether the entire string is present before allocating
597a buffer for the string, and will also put a trailing '\0' at the end of
598the buffer.
599
600If you're fetching into such a chunk of memory a 2-byte Unicode string
601from the buffer, and the string has a specified size, you can use
602"tvb_get_faked_unicode()", which will check whether the entire string
603is present before allocating a buffer for the string, and will also
604put a trailing '\0' at the end of the buffer. The resulting string will be
605a sequence of single-byte characters; the only Unicode characters that
606will be handled correctly are those in the ASCII range. (Wireshark's
607ability to handle non-ASCII strings is limited; it needs to be
608improved.)
609
610If you're fetching into such a chunk of memory a sequence of bytes from
611the buffer, and the sequence has a specified size, you can use
612"tvb_memdup()", which will check whether the entire sequence is present
613before allocating a buffer for it.
614
615Otherwise, you can check whether the data is present by using
616"tvb_ensure_bytes_exist()" although this frequently is not needed: the
617TVB-accessor routines can handle requests to read data beyond the end of
618the TVB (by throwing an exception which will either mark the frame as
619truncated--not all the data was captured--or as malformed).
620
621Note also that you should only fetch string data into a fixed-length
622buffer if the code ensures that no more bytes than will fit into the
623buffer are fetched ("the protocol ensures" isn't good enough, as
624protocol specifications can't ensure only packets that conform to the
625specification will be transmitted or that only packets for the protocol
626in question will be interpreted as packets for that protocol by
627Wireshark). If there's no maximum length of string data to be fetched,
628routines such as "tvb_get_*_string()" are safer, as they allocate a buffer
629large enough to hold the string. (Note that some variants of this call
630require you to free the string once you're finished with it.)
631
632If you have gotten a pointer using "tvb_get_ptr()" (which you should not
633have: you should seriously consider a better alternative to this function),
634you must make sure that you do not refer to any data past the length passed
635as the last argument to "tvb_get_ptr()"; while the various "tvb_get"
636routines perform bounds checking and throw an exception if you refer to data
637not available in the tvbuff, direct references through a pointer gotten from
638"tvb_get_ptr()" do not do any bounds checking.
639
640If you have a loop that dissects a sequence of items, each of which has
641a length field, with the offset in the tvbuff advanced by the length of
642the item, then, if the length field is the total length of the item, and
643thus can be zero, you *MUST* check for a zero-length item and abort the
644loop if you see one. Otherwise, a zero-length item could cause the
645dissector to loop infinitely. You should also check that the offset,
646after having the length added to it, is greater than the offset before
647the length was added to it, if the length field is greater than 24 bits
648long, so that, if the length value is *very* large and adding it to the
649offset causes an overflow, that overflow is detected.
650
651If you have a
652
653 for (i = {start}; i < {end}; i++)
654
655loop, make sure that the type of the loop index variable is large enough
656to hold the maximum {end} value plus 1; otherwise, the loop index
657variable can overflow before it ever reaches its maximum value. In
658particular, be very careful when using gint8, guint8, gint16, or guint16
659variables as loop indices; you almost always want to use an "int"/"gint"
660or "unsigned int"/"guint" as the loop index rather than a shorter type.
661
662If you are fetching a length field from the buffer, corresponding to the
663length of a portion of the packet, and subtracting from that length a
664value corresponding to the length of, for example, a header in the
665packet portion in question, *ALWAYS* check that the value of the length
666field is greater than or equal to the length you're subtracting from it,
667and report an error in the packet and stop dissecting the packet if it's
668less than the length you're subtracting from it. Otherwise, the
669resulting length value will be negative, which will either cause errors
670in the dissector or routines called by the dissector, or, if the value
671is interpreted as an unsigned integer, will cause the value to be
672interpreted as a very large positive value.
673
674Any tvbuff offset that is added to as processing is done on a packet
675should be stored in a 32-bit variable, such as an "int"; if you store it
676in an 8-bit or 16-bit variable, you run the risk of the variable
677overflowing.
678
679sprintf() -> snprintf()
680Prevent yourself from using the sprintf() function, as it does not test the
681length of the given output buffer and might be writing into unintended memory
682areas. This function is one of the main causes of security problems like buffer
683exploits and many other bugs that are very hard to find. It's much better to
684use the snprintf() function declared by <stdio.h> instead.
685
686You should test your dissector against incorrectly-formed packets. This
687can be done using the randpkt and editcap utilities that come with the
688Wireshark distribution. Testing using randpkt can be done by generating
689output at the same layer as your protocol, and forcing Wireshark/TShark
690to decode it as your protocol, e.g. if your protocol sits on top of UDP:
691
692 randpkt -c 50000 -t dns randpkt.pcap
693 tshark -nVr randpkt.pcap -d udp.port==53,<myproto>
694
695Testing using editcap can be done using preexisting capture files and the
696"-E" flag, which introduces errors in a capture file. E.g.:
697
698 editcap -E 0.03 infile.pcap outfile.pcap
699 tshark -nVr outfile.pcap
700
701The script fuzz-test.sh is available to help automate these tests.
702
7034. Name convention.
704
705Wireshark uses the underscore_convention rather than the InterCapConvention for
706function names, so new code should probably use underscores rather than
707intercaps for functions and variable names. This is especially important if you
708are writing code that will be called from outside your code. We are just
709trying to keep things consistent for other developers.
710
711C symbols exported from libraries shipped with Wireshark should start with a
712prefix that helps avoiding name collision with public symbols from other shared
713libraries. The current suggested prefixes for newly added symbols are
714ws_, wslua_, wmem_ and wtap_.
715
7165. White space convention.
717
718Most of the C and C++ files in Wireshark use 4-space or 2-space indentation.
719When creating new files you are you are strongly encouraged to use 4-space
720indentation for source code in order to ensure consistency between files.
721
722Please avoid using tab expansions different from 8 column widths, as not all
723text editors in use by the developers support this. For a detailed discussion
724of tabs, spaces, and indentation, see
725
726 http://www.jwz.org/doc/tabs-vs-spaces.html
727
728We use EditorConfig (http://editorconfig.org) files to provide formatting
729hints. Most editors and IDEs support EditorConfig, either directly or via
730a plugin. If yours requires a plugin we encourage you to install it. Our
731default EditorConfig indentation style for C and C++ files is 4 spaces.
732
733Many files also have a short comment (modelines) on the indentation logic at
734the end of the file. This was required in the past but has been superseded by
735EditorConfig. See
736
737 https://www.wireshark.org/tools/modelines.html
738
739for more information.
740
741Please do not leave trailing whitespace (spaces/tabs) on lines.
742
743Quite a bit of our source code has varying indentation styles. When editing an
744existing file, try following the existing indentation logic. If you wish to
745convert a file to 4 space indentation, please do so in its own commit and be
746sure to remove its .editorconfig entry so that the default setting takes
747effect.
748
7496. Compiler warnings
750
751You should write code that is free of compiler warnings. Such warnings will
752often indicate questionable code and sometimes even real bugs, so it's best
753to avoid warnings at all.
754
755The compiler flags in the Makefiles are set to "treat warnings as errors",
756so your code won't even compile when warnings occur.
757
7587. General observations about architecture
759
760One day we might conceivably wish to load dissectors on demand and do other
761more sophisticated kinds of unit test. Plus other scenarios not immediately
762obvious. For this to be possible it is important that the code in epan/ does
763not depend on code in epan/dissectors, i.e it is possible to compile epan
764without linking with dissector code. It helps to view dissectors as clients
765of an API provided by epan (libwireshark being constituted by two distinct
766components "epan" and "dissectors" bundled together, plus other bits and
767pieces). The reverse is not* true; epan should not be the client of an API
768provided by dissectors.
769
770The main way this separation of concerns is achieved is by using runtime
771registration interfaces in epan for dissectors, preferences, etc. that are
772dynamic and do not have any dissector routines hard coded. Naturally this
773is also an essential component of a plugin system (libwireshark has plugins
774for taps, dissectors and an experimental interface to augment dissection with
775new extension languages).
776
7778. Miscellaneous notes
778
779Each commit in your branch corresponds to a different VCSVERSION string
780automatically defined in the header 'vcs_version.h' during the build. If you happen
781to find it convenient to disable this feature it can be done using:
782
783 touch .git/wireshark-disable-versioning
784
785i.e., the file 'wireshark-disable-versioning' must exist in the git repo dir.
786
787/*
788 * Editor modelines - https://www.wireshark.org/tools/modelines.html
789 *
790 * Local variables:
791 * c-basic-offset: 4
792 * tab-width: 8
793 * indent-tabs-mode: nil
794 * End:
795 *
796 * vi: set shiftwidth=4 tabstop=8 expandtab:
797 * :indentSize=4:tabSize=8:noTabs=true:
798 */
799
1This file is a HOWTO for Wireshark developers interested in writing or working
2on Wireshark protocol dissectors. It describes expected code patterns and the
3use of some of the important functions and variables.
4
5This file is compiled to give in depth information on Wireshark.
6It is by no means all inclusive and complete. Please feel free to send
7remarks and patches to the developer mailing list.
8
9If you haven't read README.developer, read that first!
10
110. Prerequisites.
12
13Before starting to develop a new dissector, a "running" Wireshark build
14environment is required - there's no such thing as a standalone "dissector
15build toolkit".
16
17How to setup such an environment is platform dependent; detailed
18information about these steps can be found in the "Developer's Guide"
19(available from: https://www.wireshark.org) and in the INSTALL and
20README.md files of the sources root dir.
21
220.1. Dissector related README files.
23
24You'll find additional dissector related information in the following README
25files:
26
27- README.heuristic - what are heuristic dissectors and how to write them
28- README.plugins - how to "pluginize" a dissector
29- README.request_response_tracking - how to track req./resp. times and such
30- README.wmem - how to obtain "memory leak free" memory
31
320.2 Contributors
33
34James Coe <jammer[AT]cin.net>
35Gilbert Ramirez <gram[AT]alumni.rice.edu>
36Jeff Foster <jfoste[AT]woodward.com>
37Olivier Abad <oabad[AT]cybercable.fr>
38Laurent Deniel <laurent.deniel[AT]free.fr>
39Gerald Combs <gerald[AT]wireshark.org>
40Guy Harris <guy[AT]alum.mit.edu>
41Ulf Lamping <ulf.lamping[AT]web.de>
42Barbu Paul - Gheorghe <barbu.paul.gheorghe[AT]gmail.com>
43
441. Setting up your protocol dissector code.
45
46This section provides skeleton code for a protocol dissector. It also explains
47the basic functions needed to enter values in the traffic summary columns,
48add to the protocol tree, and work with registered header fields.
49
501.1 Skeleton code.
51
52Wireshark requires certain things when setting up a protocol dissector.
53We provide basic skeleton code for a dissector that you can copy to a new file
54and fill in. Your dissector should follow the naming convention of "packet-"
55followed by the abbreviated name for the protocol. It is recommended that where
56possible you keep to the IANA abbreviated name for the protocol, if there is
57one, or a commonly-used abbreviation for the protocol, if any.
58
59The skeleton code lives in the file "packet-PROTOABBREV.c" in the same source
60directory as this README.
61
62If instead of using the skeleton you base your dissector on an existing real
63dissector, please put a little note in the copyright header indicating which
64dissector you started with.
65
66Usually, you will put your newly created dissector file into the directory
67epan/dissectors/, just like all the other packet-*.c files already in there.
68
69Also, please add your dissector file to the corresponding makefiles,
70described in section "1.8 Editing CMakeLists.txt to add your dissector" below.
71
72Dissectors that use the dissector registration API to register with a lower
73level protocol (this is the vast majority) don't need to define a prototype in
74their .h file. For other dissectors the main dissector routine should have a
75prototype in a header file whose name is "packet-", followed by the abbreviated
76name for the protocol, followed by ".h"; any dissector file that calls your
77dissector should be changed to include that file.
78
79You may not need to include all the headers listed in the skeleton, and you may
80need to include additional headers.
81
821.2 Explanation of needed substitutions in code skeleton.
83
84In the skeleton sample code the following strings should be substituted with
85your information.
86
87YOUR_NAME Your name, of course. You do want credit, don't you?
88 It's the only payment you will receive....
89YOUR_EMAIL_ADDRESS Keep those cards and letters coming.
90PROTONAME The name of the protocol; this is displayed in the
91 top-level protocol tree item for that protocol.
92PROTOSHORTNAME An abbreviated name for the protocol; this is displayed
93 in the "Preferences" dialog box if your dissector has
94 any preferences, in the dialog box of enabled protocols,
95 and in the dialog box for filter fields when constructing
96 a filter expression.
97PROTOABBREV A name for the protocol for use in filter expressions;
98 it may contain only lower-case letters, digits, and hyphens,
99 underscores, and periods.
100LICENSE The license this dissector is under. Please use a SPDX License
101 identifier.
102YEARS The years the above license is valid for.
103FIELDNAME The displayed name for the header field.
104FIELDABBREV The abbreviated name for the header field; it may contain
105 only letters, digits, hyphens, underscores, and periods.
106FIELDTYPE FT_NONE, FT_BOOLEAN, FT_CHAR, FT_UINT8, FT_UINT16, FT_UINT24,
107 FT_UINT32, FT_UINT40, FT_UINT48, FT_UINT56, FT_UINT64,
108 FT_INT8, FT_INT16, FT_INT24, FT_INT32, FT_INT40, FT_INT48,
109 FT_INT56, FT_INT64, FT_FLOAT, FT_DOUBLE, FT_ABSOLUTE_TIME,
110 FT_RELATIVE_TIME, FT_STRING, FT_STRINGZ, FT_EUI64,
111 FT_UINT_STRING, FT_ETHER, FT_BYTES, FT_UINT_BYTES, FT_IPv4,
112 FT_IPv6, FT_IPXNET, FT_FRAMENUM, FT_PROTOCOL, FT_GUID, FT_OID,
113 FT_REL_OID, FT_AX25, FT_VINES, FT_SYSTEM_ID, FT_FC, FT_FCWWN
114FIELDDISPLAY --For FT_UINT{8,16,24,32,40,48,56,64} and
115 FT_INT{8,16,24,32,40,48,56,64):
116
117 BASE_DEC, BASE_HEX, BASE_OCT, BASE_DEC_HEX, BASE_HEX_DEC,
118 BASE_CUSTOM, or BASE_NONE, possibly ORed with
119 BASE_RANGE_STRING, BASE_EXT_STRING, BASE_VAL64_STRING,
120 BASE_ALLOW_ZERO, BASE_UNIT_STRING, BASE_SPECIAL_VALS,
121 BASE_NO_DISPLAY_VALUE, or BASE_SHOW_ASCII_PRINTABLE
122
123 BASE_NONE may be used with a non-NULL FIELDCONVERT when the
124 numeric value of the field itself is not of significance to
125 the user (for example, the number is a generated field).
126 When this is the case the numeric value is not shown to the
127 user in the protocol decode nor is it used when preparing
128 filters for the field in question.
129
130 BASE_NO_DISPLAY_VALUE will just display the field name with
131 no value. It is intended for byte arrays (FT_BYTES or
132 FT_UINT_BYTES) or header fields above a subtree. The
133 value will still be filterable, just not displayed.
134
135 --For FT_UINT16:
136
137 BASE_PT_UDP, BASE_PT_TCP, BASE_PT_DCCP or BASE_PT_SCTP
138
139 --For FT_UINT24:
140
141 BASE_OUI
142
143 --For FT_CHAR:
144 BASE_HEX, BASE_OCT, BASE_CUSTOM, or BASE_NONE, possibly
145 ORed with BASE_RANGE_STRING, BASE_EXT_STRING or
146 BASE_VAL64_STRING.
147
148 BASE_NONE can be used in the same way as with FT_UINT8.
149
150 --For FT_ABSOLUTE_TIME:
151
152 ABSOLUTE_TIME_LOCAL, ABSOLUTE_TIME_UTC, or
153 ABSOLUTE_TIME_DOY_UTC
154
155 --For FT_BOOLEAN:
156
157 if BITMASK is non-zero:
158 Number of bits in the field containing the FT_BOOLEAN
159 bitfield.
160 otherwise:
161 (must be) BASE_NONE
162
163 --For FT_STRING, FT_STRINGZ and FT_UINT_STRING:
164
165 STR_ASCII or STR_UNICODE
166
167 --For FT_BYTES and FT_UINT_BYTES:
168
169 SEP_DOT, SEP_DASH, SEP_COLON, or SEP_SPACE to provide
170 a separator between bytes; BASE_NONE has no separator
171 between bytes. These can be ORed with BASE_ALLOW_ZERO
172 and BASE_SHOW_ASCII_PRINTABLE.
173
174 BASE_ALLOW_ZERO displays <none> instead of <MISSING>
175 for a zero-sized byte array.
176 BASE_SHOW_ASCII_PRINTABLE will check whether the
177 field's value consists entirely of printable ASCII
178 characters and, if so, will display the field's value
179 as a string, in quotes. The value will still be
180 filterable as a byte value.
181
182 --For FT_IPv4:
183
184 BASE_NETMASK - Used for IPv4 address that should never
185 attempted to be resolved (like netmasks)
186 otherwise:
187 (must be) BASE_NONE
188
189 --For all other types:
190
191 BASE_NONE
192FIELDCONVERT VALS(x), VALS64(x), RVALS(x), TFS(x), CF_FUNC(x), NULL
193BITMASK Used to mask a field not 8-bit aligned or with a size other
194 than a multiple of 8 bits
195FIELDDESCR A brief description of the field, or NULL. [Please do not use ""].
196
197If, for example, PROTONAME is "Internet Bogosity Discovery Protocol",
198PROTOSHORTNAME would be "IBDP", and PROTOABBREV would be "ibdp". Try to
199conform with IANA names.
200
2011.2.1 Automatic substitution in code skeleton
202
203Instead of manual substitutions in the code skeleton, a tool to automate it can
204be found under the tools directory. The script is called tools/generate-dissector.py
205and takes all the needed options to generate a compilable dissector. Look at the
206above fields to know how to set them. Some assumptions have been made in the
207generation to shorten the list of required options. The script patches the
208CMakeLists.txt file adding the new dissector in the proper list, alphabetically
209sorted.
210
2111.3 The dissector and the data it receives.
212
213
2141.3.1 Header file.
215
216This is only needed if the dissector doesn't use self-registration to
217register itself with the lower level dissector, or if the protocol dissector
218wants/needs to expose code to other subdissectors.
219
220The dissector must be declared exactly as follows in the file
221packet-PROTOABBREV.h:
222
223int
224dissect_PROTOABBREV(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree);
225
226
2271.3.2 Extracting data from packets.
228
229NOTE: See the file /epan/tvbuff.h for more details.
230
231The "tvb" argument to a dissector points to a buffer containing the raw
232data to be analyzed by the dissector; for example, for a protocol
233running atop UDP, it contains the UDP payload (but not the UDP header,
234or any protocol headers above it). A tvbuffer is an opaque data
235structure, the internal data structures are hidden and the data must be
236accessed via the tvbuffer accessors.
237
238The accessors are:
239
240Bit accessors for a maximum of 8-bits, 16-bits 32-bits and 64-bits:
241
242guint8 tvb_get_bits8(tvbuff_t *tvb, gint bit_offset, const gint no_of_bits);
243guint16 tvb_get_bits16(tvbuff_t *tvb, guint bit_offset, const gint no_of_bits, const guint encoding);
244guint32 tvb_get_bits32(tvbuff_t *tvb, guint bit_offset, const gint no_of_bits, const guint encoding);
245guint64 tvb_get_bits64(tvbuff_t *tvb, guint bit_offset, const gint no_of_bits, const guint encoding);
246
247Single-byte accessors for 8-bit unsigned integers (guint8) and 8-bit
248signed integers (gint8):
249
250guint8 tvb_get_guint8(tvbuff_t *tvb, const gint offset);
251gint8 tvb_get_gint8(tvbuff_t *tvb, const gint offset);
252
253Network-to-host-order accessors:
254
25516-bit unsigned (guint16) and signed (gint16) integers:
256
257guint16 tvb_get_ntohs(tvbuff_t *tvb, const gint offset);
258gint16 tvb_get_ntohis(tvbuff_t *tvb, const gint offset);
259
26024-bit unsigned and signed integers:
261
262guint32 tvb_get_ntoh24(tvbuff_t *tvb, const gint offset);
263gint32 tvb_get_ntohi24(tvbuff_t *tvb, const gint offset);
264
26532-bit unsigned (guint32) and signed (gint32) integers:
266
267guint32 tvb_get_ntohl(tvbuff_t *tvb, const gint offset);
268gint32 tvb_get_ntohil(tvbuff_t *tvb, const gint offset);
269
27040-bit unsigned and signed integers:
271
272guint64 tvb_get_ntoh40(tvbuff_t *tvb, const gint offset);
273gint64 tvb_get_ntohi40(tvbuff_t *tvb, const gint offset);
274
27548-bit unsigned and signed integers:
276
277guint64 tvb_get_ntoh48(tvbuff_t *tvb, const gint offset);
278gint64 tvb_get_ntohi48(tvbuff_t *tvb, const gint offset);
279
28056-bit unsigned and signed integers:
281
282guint64 tvb_get_ntoh56(tvbuff_t *tvb, const gint offset);
283gint64 tvb_get_ntohi56(tvbuff_t *tvb, const gint offset);
284
28564-bit unsigned (guint64) and signed (gint64) integers:
286
287guint64 tvb_get_ntoh64(tvbuff_t *tvb, const gint offset);
288gint64 tvb_get_ntohi64(tvbuff_t *tvb, const gint offset);
289
290Single-precision and double-precision IEEE floating-point numbers:
291
292gfloat tvb_get_ntohieee_float(tvbuff_t *tvb, const gint offset);
293gdouble tvb_get_ntohieee_double(tvbuff_t *tvb, const gint offset);
294
295Little-Endian-to-host-order accessors:
296
29716-bit unsigned (guint16) and signed (gint16) integers:
298
299guint16 tvb_get_letohs(tvbuff_t *tvb, const gint offset);
300gint16 tvb_get_letohis(tvbuff_t *tvb, const gint offset);
301
30224-bit unsigned and signed integers:
303
304guint32 tvb_get_letoh24(tvbuff_t *tvb, const gint offset);
305gint32 tvb_get_letohi24(tvbuff_t *tvb, const gint offset);
306
30732-bit unsigned (guint32) and signed (gint32) integers:
308
309guint32 tvb_get_letohl(tvbuff_t *tvb, const gint offset);
310gint32 tvb_get_letohil(tvbuff_t *tvb, const gint offset);
311
31240-bit unsigned and signed integers:
313
314guint64 tvb_get_letoh40(tvbuff_t *tvb, const gint offset);
315gint64 tvb_get_letohi40(tvbuff_t *tvb, const gint offset);
316
31748-bit unsigned and signed integers:
318
319guint64 tvb_get_letoh48(tvbuff_t *tvb, const gint offset);
320gint64 tvb_get_letohi48(tvbuff_t *tvb, const gint offset);
321
32256-bit unsigned and signed integers:
323
324guint64 tvb_get_letoh56(tvbuff_t *tvb, const gint offset);
325gint64 tvb_get_letohi56(tvbuff_t *tvb, const gint offset);
326
32764-bit unsigned (guint64) and signed (gint64) integers:
328
329guint64 tvb_get_letoh64(tvbuff_t *tvb, const gint offset);
330gint64 tvb_get_letohi64(tvbuff_t *tvb, const gint offset);
331
332NOTE: Although each of the integer accessors above return types with
333specific sizes, the returned values are subject to C's integer promotion
334rules. It's often safer and more useful to use int or guint for 32-bit
335and smaller types, and gint64 or guint64 for 40-bit and larger types.
336Just because a value occupied 16 bits on the wire or over the air
337doesn't mean it will within Wireshark.
338
339Single-precision and double-precision IEEE floating-point numbers:
340
341gfloat tvb_get_letohieee_float(tvbuff_t *tvb, const gint offset);
342gdouble tvb_get_letohieee_double(tvbuff_t *tvb, const gint offset);
343
344Encoding-to_host-order accessors:
345
34616-bit unsigned (guint16) and signed (gint16) integers:
347
348guint16 tvb_get_guint16(tvbuff_t *tvb, const gint offset, const guint encoding);
349gint16 tvb_get_gint16(tvbuff_t *tvb, const gint offset, const guint encoding);
350
35124-bit unsigned and signed integers:
352
353guint32 tvb_get_guint24(tvbuff_t *tvb, const gint offset, const guint encoding);
354gint32 tvb_get_gint24(tvbuff_t *tvb, const gint offset, const guint encoding);
355
35632-bit unsigned (guint32) and signed (gint32) integers:
357
358guint32 tvb_get_guint32(tvbuff_t *tvb, const gint offset, const guint encoding);
359gint32 tvb_get_gint32(tvbuff_t *tvb, const gint offset, const guint encoding);
360
36140-bit unsigned and signed integers:
362
363guint64 tvb_get_guint40(tvbuff_t *tvb, const gint offset, const guint encoding);
364gint64 tvb_get_gint40(tvbuff_t *tvb, const gint offset, const guint encoding);
365
36648-bit unsigned and signed integers:
367
368guint64 tvb_get_guint48(tvbuff_t *tvb, const gint offset, const guint encoding);
369gint64 tvb_get_gint48(tvbuff_t *tvb, const gint offset, const guint encoding);
370
37156-bit unsigned and signed integers:
372
373guint64 tvb_get_guint56(tvbuff_t *tvb, const gint offset, const guint encoding);
374gint64 tvb_get_gint56(tvbuff_t *tvb, const gint offset, const guint encoding);
375
37664-bit unsigned (guint64) and signed (gint64) integers:
377
378guint64 tvb_get_guint64(tvbuff_t *tvb, const gint offset, const guint encoding);
379gint64 tvb_get_gint64(tvbuff_t *tvb, const gint offset, const guint encoding);
380
381Single-precision and double-precision IEEE floating-point numbers:
382
383gfloat tvb_get_ieee_float(tvbuff_t *tvb, const gint offset, const guint encoding);
384gdouble tvb_get_ieee_double(tvbuff_t *tvb, const gint offset, const guint encoding);
385
386"encoding" should be ENC_BIG_ENDIAN for Network-to-host-order,
387ENC_LITTLE_ENDIAN for Little-Endian-to-host-order, or ENC_HOST_ENDIAN
388for host order.
389
390Accessors for IPv4 and IPv6 addresses:
391
392guint32 tvb_get_ipv4(tvbuff_t *tvb, const gint offset);
393void tvb_get_ipv6(tvbuff_t *tvb, const gint offset, ws_in6_addr *addr);
394
395NOTE: IPv4 addresses are not to be converted to host byte order before
396being passed to "proto_tree_add_ipv4()". You should use "tvb_get_ipv4()"
397to fetch them, not "tvb_get_ntohl()" *OR* "tvb_get_letohl()" - don't,
398for example, try to use "tvb_get_ntohl()", find that it gives you the
399wrong answer on the PC on which you're doing development, and try
400"tvb_get_letohl()" instead, as "tvb_get_letohl()" will give the wrong
401answer on big-endian machines.
402
403gchar *tvb_ip_to_str(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset)
404gchar *tvb_ip6_to_str(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset)
405
406Returns a null-terminated buffer containing a string with IPv4 or IPv6 Address
407from the specified tvbuff, starting at the specified offset.
408
409Accessors for GUID:
410
411void tvb_get_ntohguid(tvbuff_t *tvb, const gint offset, e_guid_t *guid);
412void tvb_get_letohguid(tvbuff_t *tvb, const gint offset, e_guid_t *guid);
413void tvb_get_guid(tvbuff_t *tvb, const gint offset, e_guid_t *guid, const guint encoding);
414
415String accessors:
416
417guint8 *tvb_get_string_enc(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset, const gint length, const guint encoding);
418
419Returns a null-terminated buffer allocated from the specified scope, containing
420data from the specified tvbuff, starting at the specified offset, and containing
421the specified length worth of characters. Reads data in the specified encoding
422and produces UTF-8 in the buffer. See below for a list of input encoding values.
423
424The buffer is allocated in the given wmem scope (see README.wmem for more
425information).
426
427guint8 *tvb_get_stringz_enc(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset, gint *lengthp, const guint encoding);
428
429Returns a null-terminated buffer allocated from the specified scope,
430containing data from the specified tvbuff, starting at the specified
431offset, and containing all characters from the tvbuff up to and
432including a terminating null character in the tvbuff. Reads data in the
433specified encoding and produces UTF-8 in the buffer. See below for a
434list of input encoding values. "*lengthp" will be set to the length of
435the string, including the terminating null.
436
437The buffer is allocated in the given wmem scope (see README.wmem for more
438information).
439
440const guint8 *tvb_get_const_stringz(tvbuff_t *tvb, const gint offset, gint *lengthp);
441
442Returns a null-terminated const buffer containing data from the
443specified tvbuff, starting at the specified offset, and containing all
444bytes from the tvbuff up to and including a terminating null character
445in the tvbuff. "*lengthp" will be set to the length of the string,
446including the terminating null.
447
448You do not need to free() this buffer; it will happen automatically once
449the next packet is dissected. This function is slightly more efficient
450than the others because it does not allocate memory and copy the string,
451but it does not do any mapping to UTF-8 or checks for valid octet
452sequences.
453
454gint tvb_get_nstringz(tvbuff_t *tvb, const gint offset, const guint bufsize, guint8* buffer);
455gint tvb_get_nstringz0(tvbuff_t *tvb, const gint offset, const guint bufsize, guint8* buffer);
456
457Copies bufsize bytes, including the terminating NULL, to buffer. If a NULL
458terminator is found before reaching bufsize, only the bytes up to and including
459the NULL are copied. Returns the number of bytes copied (not including
460terminating NULL), or -1 if the string was truncated in the buffer due to
461not having reached the terminating NULL. In this case, the resulting
462buffer is not NULL-terminated.
463tvb_get_nstringz0() works like tvb_get_nstringz(), but never returns -1 since
464the string is guaranteed to have a terminating NULL. If the string was truncated
465when copied into buffer, a NULL is placed at the end of buffer to terminate it.
466
467gchar *tvb_get_ts_23_038_7bits_string(wmem_allocator_t *scope, tvbuff_t *tvb,
468 const gint bit_offset, gint no_of_chars);
469
470tvb_get_ts_23_038_7bits_string() returns a string of a given number of
471characters and encoded according to 3GPP TS 23.038 7 bits alphabet.
472
473The buffer is allocated in the given wmem scope (see README.wmem for more
474information).
475
476Byte Array Accessors:
477
478gchar *tvb_bytes_to_str(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset, const gint len);
479
480Formats a bunch of data from a tvbuff as bytes, returning a pointer
481to the string with the data formatted as two hex digits for each byte.
482The string pointed to is stored in an "wmem_alloc'd" buffer which will be freed
483depending on its scope (typically wmem_packet_scope which is freed after the frame).
484The formatted string will contain the hex digits for at most the first 16 bytes of
485the data. If len is greater than 16 bytes, a trailing "..." will be added to the string.
486
487gchar *tvb_bytes_to_str_punct(wmem_allocator_t *scope, tvbuff_t *tvb,
488 const gint offset, const gint len, const gchar punct);
489
490This function is similar to tvb_bytes_to_str(...) except that 'punct' is inserted
491between the hex representation of each byte.
492
493GByteArray *tvb_get_string_bytes(tvbuff_t *tvb, const gint offset, const gint length,
494 const guint encoding, GByteArray* bytes, gint *endoff)
495
496Given a tvbuff, an offset into the tvbuff, and a length that starts
497at that offset (which may be -1 for "all the way to the end of the
498tvbuff"), fetch the hex-decoded byte values of the tvbuff into the
499passed-in 'bytes' array, based on the passed-in encoding. In other
500words, convert from a hex-ascii string in tvbuff, into the supplied
501GByteArray.
502
503gchar *tvb_bcd_dig_to_wmem_packet_str(tvbuff_t *tvb, const gint offset, const gint len, dgt_set_t *dgt, gboolean skip_first);
504
505Given a tvbuff, an offset into the tvbuff, and a length that starts
506at that offset (which may be -1 for "all the way to the end of the
507tvbuff"), fetch BCD encoded digits from a tvbuff starting from either
508the low or high half byte, formatting the digits according to an input digit set,
509if NUll a default digit set of 0-9 returning "?" for overdecadic digits will be used.
510A pointer to the packet scope allocated string will be returned.
511Note: a tvbuff content of 0xf is considered a 'filler' and will end the conversion.
512
513Copying memory:
514void* tvb_memcpy(tvbuff_t *tvb, void* target, const gint offset, size_t length);
515
516Copies into the specified target the specified length's worth of data
517from the specified tvbuff, starting at the specified offset.
518
519void *tvb_memdup(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset, size_t length);
520
521Returns a buffer containing a copy of the given TVB bytes. The buffer is
522allocated in the given wmem scope (see README.wmem for more information).
523
524Pointer-retrieval:
525/* WARNING! Don't use this function. There is almost always a better way.
526 * It's dangerous because once this pointer is given to the user, there's
527 * no guarantee that the user will honor the 'length' and not overstep the
528 * boundaries of the buffer. Also see the warning in the Portability section.
529 */
530const guint8* tvb_get_ptr(tvbuff_t *tvb, const gint offset, const gint length);
531
532Length query:
533Get amount of captured data in the buffer (which is *NOT* necessarily the
534length of the packet). You probably want tvb_reported_length instead:
535
536 guint tvb_captured_length(const tvbuff_t *tvb);
537
538Get reported length of buffer:
539
540 guint tvb_reported_length(const tvbuff_t *tvb);
541
542
5431.4 Functions to handle columns in the traffic summary window.
544
545The topmost pane of the main window is a list of the packets in the
546capture, possibly filtered by a display filter.
547
548Each line corresponds to a packet, and has one or more columns, as
549configured by the user.
550
551Many of the columns are handled by code outside individual dissectors;
552most dissectors need only specify the value to put in the "Protocol" and
553"Info" columns.
554
555Columns are specified by COL_ values; the COL_ value for the "Protocol"
556field, typically giving an abbreviated name for the protocol (but not
557the all-lower-case abbreviation used elsewhere) is COL_PROTOCOL, and the
558COL_ value for the "Info" field, giving a summary of the contents of the
559packet for that protocol, is COL_INFO.
560
561The value for a column can be specified with one of several functions,
562all of which take the 'fd' argument to the dissector as their first
563argument, and the COL_ value for the column as their second argument.
564
5651.4.1 The col_set_str function.
566
567'col_set_str' takes a string as its third argument, and sets the value
568for the column to that value. It assumes that the pointer passed to it
569points to a string constant or a static "const" array, not to a
570variable, as it doesn't copy the string, it merely saves the pointer
571value; the argument can itself be a variable, as long as it always
572points to a string constant or a static "const" array.
573
574It is more efficient than 'col_add_str' or 'col_add_fstr'; however, if
575the dissector will be using 'col_append_str' or 'col_append_fstr" to
576append more information to the column, the string will have to be copied
577anyway, so it's best to use 'col_add_str' rather than 'col_set_str' in
578that case.
579
580For example, to set the "Protocol" column
581to "PROTOABBREV":
582
583 col_set_str(pinfo->cinfo, COL_PROTOCOL, "PROTOABBREV");
584
585
5861.4.2 The col_add_str function.
587
588'col_add_str' takes a string as its third argument, and sets the value
589for the column to that value. It takes the same arguments as
590'col_set_str', but copies the string, so that if the string is, for
591example, an automatic variable that won't remain in scope when the
592dissector returns, it's safe to use.
593
594
5951.4.3 The col_add_fstr function.
596
597'col_add_fstr' takes a 'printf'-style format string as its third
598argument, and 'printf'-style arguments corresponding to '%' format
599items in that string as its subsequent arguments. For example, to set
600the "Info" field to "<XXX> request, <N> bytes", where "reqtype" is a
601string containing the type of the request in the packet and "n" is an
602unsigned integer containing the number of bytes in the request:
603
604 col_add_fstr(pinfo->cinfo, COL_INFO, "%s request, %u bytes",
605 reqtype, n);
606
607Don't use 'col_add_fstr' with a format argument of just "%s" -
608'col_add_str', or possibly even 'col_set_str' if the string that matches
609the "%s" is a static constant string, will do the same job more
610efficiently.
611
612
6131.4.4 The col_clear function.
614
615If the Info column will be filled with information from the packet, that
616means that some data will be fetched from the packet before the Info
617column is filled in. If the packet is so small that the data in
618question cannot be fetched, the routines to fetch the data will throw an
619exception (see the comment at the beginning about tvbuffers improving
620the handling of short packets - the tvbuffers keep track of how much
621data is in the packet, and throw an exception on an attempt to fetch
622data past the end of the packet, so that the dissector won't process
623bogus data), causing the Info column not to be filled in.
624
625This means that the Info column will have data for the previous
626protocol, which would be confusing if, for example, the Protocol column
627had data for this protocol.
628
629Therefore, before a dissector fetches any data whatsoever from the
630packet (unless it's a heuristic dissector fetching data to determine
631whether the packet is one that it should dissect, in which case it
632should check, before fetching the data, whether there's any data to
633fetch; if there isn't, it should return FALSE), it should set the
634Protocol column and the Info column.
635
636If the Protocol column will ultimately be set to, for example, a value
637containing a protocol version number, with the version number being a
638field in the packet, the dissector should, before fetching the version
639number field or any other field from the packet, set it to a value
640without a version number, using 'col_set_str', and should later set it
641to a value with the version number after it's fetched the version
642number.
643
644If the Info column will ultimately be set to a value containing
645information from the packet, the dissector should, before fetching any
646fields from the packet, clear the column using 'col_clear' (which is
647more efficient than clearing it by calling 'col_set_str' or
648'col_add_str' with a null string), and should later set it to the real
649string after it's fetched the data to use when doing that.
650
651
6521.4.5 The col_append_str function.
653
654Sometimes the value of a column, especially the "Info" column, can't be
655conveniently constructed at a single point in the dissection process;
656for example, it might contain small bits of information from many of the
657fields in the packet. 'col_append_str' takes, as arguments, the same
658arguments as 'col_add_str', but the string is appended to the end of the
659current value for the column, rather than replacing the value for that
660column. (Note that no blank separates the appended string from the
661string to which it is appended; if you want a blank there, you must add
662it yourself as part of the string being appended.)
663
664
6651.4.6 The col_append_fstr function.
666
667'col_append_fstr' is to 'col_add_fstr' as 'col_append_str' is to
668'col_add_str' - it takes, as arguments, the same arguments as
669'col_add_fstr', but the formatted string is appended to the end of the
670current value for the column, rather than replacing the value for that
671column.
672
6731.4.7 The col_append_sep_str and col_append_sep_fstr functions.
674
675In specific situations the developer knows that a column's value will be
676created in a stepwise manner, where the appended values are listed. Both
677'col_append_sep_str' and 'col_append_sep_fstr' functions will add an item
678separator between two consecutive items, and will not add the separator at the
679beginning of the column. The remainder of the work both functions do is
680identical to what 'col_append_str' and 'col_append_fstr' do.
681
6821.4.8 The col_set_fence and col_prepend_fence_fstr functions.
683
684Sometimes a dissector may be called multiple times for different PDUs in the
685same frame (for example in the case of SCTP chunk bundling: several upper
686layer data packets may be contained in one SCTP packet). If the upper layer
687dissector calls 'col_set_str()' or 'col_clear()' on the Info column when it
688begins dissecting each of those PDUs then when the frame is fully dissected
689the Info column would contain only the string from the last PDU in the frame.
690The 'col_set_fence' function erects a "fence" in the column that prevents
691subsequent 'col_...' calls from clearing the data currently in that column.
692For example, the SCTP dissector calls 'col_set_fence' on the Info column
693after it has called any subdissectors for that chunk so that subdissectors
694of any subsequent chunks may only append to the Info column.
695'col_prepend_fence_fstr' prepends data before a fence (moving it if
696necessary). It will create a fence at the end of the prepended data if the
697fence does not already exist.
698
699
7001.4.9 The col_set_time function.
701
702The 'col_set_time' function takes an nstime value as its third argument.
703This nstime value is a relative value and will be added as such to the
704column. The fourth argument is the filtername holding this value. This
705way, rightclicking on the column makes it possible to build a filter
706based on the time-value.
707
708For example:
709
710 col_set_time(pinfo->cinfo, COL_REL_TIME, &ts, "s4607.ploc.time");
711
712
7131.5 Constructing the protocol tree.
714
715The middle pane of the main window, and the topmost pane of a packet
716popup window, are constructed from the "protocol tree" for a packet.
717
718The protocol tree, or proto_tree, is a GNode, the N-way tree structure
719available within GLIB. Of course the protocol dissectors don't care
720what a proto_tree really is; they just pass the proto_tree pointer as an
721argument to the routines which allow them to add items and new branches
722to the tree.
723
724When a packet is selected in the packet-list pane, or a packet popup
725window is created, a new logical protocol tree (proto_tree) is created.
726The pointer to the proto_tree (in this case, 'protocol tree'), is passed
727to the top-level protocol dissector, and then to all subsequent protocol
728dissectors for that packet, and then the GUI tree is drawn via
729proto_tree_draw().
730
731The logical proto_tree needs to know detailed information about the protocols
732and fields about which information will be collected from the dissection
733routines. By strictly defining (or "typing") the data that can be attached to a
734proto tree, searching and filtering becomes possible. This means that for
735every protocol and field (which I also call "header fields", since they are
736fields in the protocol headers) which might be attached to a tree, some
737information is needed.
738
739Every dissector routine will need to register its protocols and fields
740with the central protocol routines (in proto.c). At first I thought I
741might keep all the protocol and field information about all the
742dissectors in one file, but decentralization seemed like a better idea.
743That one file would have gotten very large; one small change would have
744required a re-compilation of the entire file. Also, by allowing
745registration of protocols and fields at run-time, loadable modules of
746protocol dissectors (perhaps even user-supplied) is feasible.
747
748To do this, each protocol should have a register routine, which will be
749called when Wireshark starts. The code to call the register routines is
750generated automatically; to arrange that a protocol's register routine
751be called at startup:
752
753 the file containing a dissector's "register" routine must be
754 added to "DISSECTOR_SRC" in "epan/dissectors/CMakeLists.txt";
755
756 the "register" routine must have a name of the form
757 "proto_register_XXX";
758
759 the "register" routine must take no argument, and return no
760 value;
761
762 the "register" routine's name must appear in the source file
763 either at the beginning of the line, or preceded only by "void "
764 at the beginning of the line (that would typically be the
765 definition) - other white space shouldn't cause a problem, e.g.:
766
767void proto_register_XXX(void) {
768
769 ...
770
771}
772
773and
774
775void
776proto_register_XXX( void )
777{
778
779 ...
780
781}
782
783 and so on should work.
784
785For every protocol or field that a dissector wants to register, a variable of
786type int needs to be used to keep track of the protocol. The IDs are
787needed for establishing parent/child relationships between protocols and
788fields, as well as associating data with a particular field so that it
789can be stored in the logical tree and displayed in the GUI protocol
790tree.
791
792Some dissectors will need to create branches within their tree to help
793organize header fields. These branches should be registered as header
794fields. Only true protocols should be registered as protocols. This is
795so that a display filter user interface knows how to distinguish
796protocols from fields.
797
798A protocol is registered with the name of the protocol and its
799abbreviation.
800
801Here is how the frame "protocol" is registered.
802
803 int proto_frame;
804
805 proto_frame = proto_register_protocol (
806 /* name */ "Frame",
807 /* short name */ "Frame",
808 /* abbrev */ "frame" );
809
810A header field is also registered with its name and abbreviation, but
811information about its data type is needed. It helps to look at
812the header_field_info struct to see what information is expected:
813
814struct header_field_info {
815 const char *name;
816 const char *abbrev;
817 enum ftenum type;
818 int display;
819 const void *strings;
820 guint64 bitmask;
821 const char *blurb;
822 .....
823};
824
825name (FIELDNAME)
826----------------
827A string representing the name of the field. This is the name
828that will appear in the graphical protocol tree. It must be a non-empty
829string.
830
831abbrev (FIELDABBREV)
832--------------------
833A string with an abbreviation of the field. The abbreviation should start
834with the abbreviation of the parent protocol followed by a period as a
835separator. For example, the "src" field in an IP packet would have "ip.src"
836as an abbreviation. It is acceptable to have multiple levels of periods if,
837for example, you have fields in your protocol that are then subdivided into
838subfields. For example, TRMAC has multiple error fields, so the abbreviations
839follow this pattern: "trmac.errors.iso", "trmac.errors.noniso", etc.
840
841The abbreviation is the identifier used in a display filter. As such it
842cannot be an empty string.
843
844type (FIELDTYPE)
845----------------
846The type of value this field holds. The current field types are:
847
848 FT_NONE No field type. Used for fields that
849 aren't given a value, and that can only
850 be tested for presence or absence; a
851 field that represents a data structure,
852 with a subtree below it containing
853 fields for the members of the structure,
854 or that represents an array with a
855 subtree below it containing fields for
856 the members of the array, might be an
857 FT_NONE field.
858 FT_PROTOCOL Used for protocols which will be placing
859 themselves as top-level items in the
860 "Packet Details" pane of the UI.
861 FT_BOOLEAN 0 means "false", any other value means
862 "true".
863 FT_FRAMENUM A frame number; if this is used, the "Go
864 To Corresponding Frame" menu item can
865 work on that field.
866 FT_CHAR An 8-bit ASCII character. It's treated similarly to an
867 FT_UINT8, but is displayed as a C-style character
868 constant.
869 FT_UINT8 An 8-bit unsigned integer.
870 FT_UINT16 A 16-bit unsigned integer.
871 FT_UINT24 A 24-bit unsigned integer.
872 FT_UINT32 A 32-bit unsigned integer.
873 FT_UINT40 A 40-bit unsigned integer.
874 FT_UINT48 A 48-bit unsigned integer.
875 FT_UINT56 A 56-bit unsigned integer.
876 FT_UINT64 A 64-bit unsigned integer.
877 FT_INT8 An 8-bit signed integer.
878 FT_INT16 A 16-bit signed integer.
879 FT_INT24 A 24-bit signed integer.
880 FT_INT32 A 32-bit signed integer.
881 FT_INT40 A 40-bit signed integer.
882 FT_INT48 A 48-bit signed integer.
883 FT_INT56 A 56-bit signed integer.
884 FT_INT64 A 64-bit signed integer.
885 FT_FLOAT A single-precision floating point number.
886 FT_DOUBLE A double-precision floating point number.
887 FT_ABSOLUTE_TIME An absolute time from some fixed point in time,
888 displayed as the date, followed by the time, as
889 hours, minutes, and seconds with 9 digits after
890 the decimal point.
891 FT_RELATIVE_TIME Seconds (4 bytes) and nanoseconds (4 bytes)
892 of time relative to an arbitrary time.
893 displayed as seconds and 9 digits
894 after the decimal point.
895 FT_STRING A string of characters, not necessarily
896 NULL-terminated, but possibly NULL-padded.
897 This, and the other string-of-characters
898 types, are to be used for text strings,
899 not raw binary data.
900 FT_STRINGZ A NULL-terminated string of characters.
901 The string length is normally the length
902 given in the proto_tree_add_item() call.
903 However if the length given in the call
904 is -1, then the length used is that
905 returned by calling tvb_strsize().
906 This should only be used if the string,
907 in the packet, is always terminated with
908 a NULL character, either because the length
909 isn't otherwise specified or because a
910 character count *and* a NULL terminator are
911 both used.
912 FT_STRINGZPAD A NULL-padded string of characters.
913 The length is given in the proto_tree_add_item()
914 call, but may be larger than the length of
915 the string, with extra bytes being NULL padding.
916 This is typically used for fixed-length fields
917 that contain a string value that might be shorter
918 than the fixed length.
919 FT_STRINGZTRUNC A NULL-truncated string of characters.
920 The length is given in the proto_tree_add_item()
921 call, but may be larger than the length of
922 the string, with a NULL character after the last
923 character of the string, and the remaining bytes
924 being padding with unspecified contents. This is
925 typically used for fixed-length fields that contain
926 a string value that might be shorter than the fixed
927 length.
928 FT_UINT_STRING A counted string of characters, consisting
929 of a count (represented as an integral value,
930 of width given in the proto_tree_add_item()
931 call) followed immediately by that number of
932 characters.
933 FT_ETHER A six octet string displayed in
934 Ethernet-address format.
935 FT_BYTES A string of bytes with arbitrary values;
936 used for raw binary data.
937 FT_UINT_BYTES A counted string of bytes, consisting
938 of a count (represented as an integral value,
939 of width given in the proto_tree_add_item()
940 call) followed immediately by that number of
941 arbitrary values; used for raw binary data.
942 FT_IPv4 A version 4 IP address (4 bytes) displayed
943 in dotted-quad IP address format (4
944 decimal numbers separated by dots).
945 FT_IPv6 A version 6 IP address (16 bytes) displayed
946 in standard IPv6 address format.
947 FT_IPXNET An IPX address displayed in hex as a 6-byte
948 network number followed by a 6-byte station
949 address.
950 FT_GUID A Globally Unique Identifier
951 FT_OID An ASN.1 Object Identifier
952 FT_REL_OID An ASN.1 Relative Object Identifier
953 FT_EUI64 A EUI-64 Address
954 FT_AX25 A AX-25 Address
955 FT_VINES A Vines Address
956 FT_SYSTEM_ID An OSI System-ID
957 FT_FCWWN A Fibre Channel WWN Address
958
959Some of these field types are still not handled in the display filter
960routines, but the most common ones are. The FT_UINT* variables all
961represent unsigned integers, and the FT_INT* variables all represent
962signed integers; the number on the end represent how many bits are used
963to represent the number.
964
965Some constraints are imposed on the header fields depending on the type
966(e.g. FT_BYTES) of the field. Fields of type FT_ABSOLUTE_TIME must use
967'ABSOLUTE_TIME_{LOCAL,UTC,DOY_UTC}, NULL, 0x0' as values for the
968'display, 'strings', and 'bitmask' fields, and all other non-integral
969types (i.e.. types that are _not_ FT_INT* and FT_UINT*) must use
970'BASE_NONE, NULL, 0x0' as values for the 'display', 'strings', 'bitmask'
971fields. The reason is simply that the type itself implicitly defines the
972nature of 'display', 'strings', 'bitmask'.
973
974display (FIELDDISPLAY)
975----------------------
976The display field has a couple of overloaded uses. This is unfortunate,
977but since we're using C as an application programming language, this sometimes
978makes for cleaner programs. Right now I still think that overloading
979this variable was okay.
980
981For integer fields (FT_UINT* and FT_INT*), this variable represents the
982base in which you would like the value displayed. The acceptable bases
983are:
984
985 BASE_DEC,
986 BASE_HEX,
987 BASE_OCT,
988 BASE_DEC_HEX,
989 BASE_HEX_DEC,
990 BASE_CUSTOM
991
992BASE_DEC, BASE_HEX, and BASE_OCT are decimal, hexadecimal, and octal,
993respectively. BASE_DEC_HEX and BASE_HEX_DEC display value in two bases
994(the 1st representation followed by the 2nd in parenthesis).
995
996BASE_CUSTOM allows one to specify a callback function pointer that will
997format the value.
998
999For 32-bit and smaller values, custom_fmt_func_t can be used to declare
1000the callback function pointer. Specifically, this is defined as:
1001
1002 void func(gchar *, guint32);
1003
1004For values larger than 32-bits, custom_fmt_func_64_t can be used to declare
1005the callback function pointer. Specifically, this is defined as:
1006
1007 void func(gchar *, guint64);
1008
1009The first argument is a pointer to a buffer of the ITEM_LABEL_LENGTH size
1010and the second argument is the value to be formatted.
1011
1012Both custom_fmt_func_t and custom_fmt_func_64_t are defined in epan/proto.h.
1013
1014For FT_UINT16 'display' can be used to select a transport layer protocol using one
1015of BASE_PT_UDP, BASE_PT_TCP, BASE_PT_DCCP or BASE_PT_SCTP. If transport name
1016resolution is enabled the port field label is displayed in decimal and as a well-known
1017service name (if one is available).
1018
1019For FT_BOOLEAN fields that are also bitfields (i.e., 'bitmask' is non-zero),
1020'display' is used specify a "field-width" (i.e., tell the proto_tree how
1021wide the parent bitfield is). (If the FT_BOOLEAN 'bitmask' is zero, then
1022'display' must be BASE_NONE).
1023
1024For integer fields a "field-width" is not needed since the type of
1025integer itself (FT_UINT8, FT_UINT16, FT_UINT24, FT_UINT32, FT_UINT40,
1026FT_UINT48, FT_UINT56, FT_UINT64, etc) tells the proto_tree how wide the
1027parent bitfield is. The same is true of FT_CHAR, as it's an 8-bit
1028character.
1029
1030For FT_ABSOLUTE_TIME fields, 'display' is used to indicate whether the
1031time is to be displayed as a time in the time zone for the machine on
1032which Wireshark/TShark is running or as UTC and, for UTC, whether the
1033date should be displayed as "{monthname} {day_of_month}, {year}" or as
1034"{year/day_of_year}".
1035
1036Additionally, BASE_NONE is used for 'display' as a NULL-value. That is, for
1037non-integers other than FT_ABSOLUTE_TIME fields, and non-bitfield
1038FT_BOOLEANs, you'll want to use BASE_NONE in the 'display' field. You may
1039not use BASE_NONE for integers.
1040
1041It is possible that in the future we will record the endianness of
1042integers. If so, it is likely that we'll use a bitmask on the display field
1043so that integers would be represented as BEND|BASE_DEC or LEND|BASE_HEX.
1044But that has not happened yet; note that there are protocols for which
1045no endianness is specified, such as the X11 protocol and the DCE RPC
1046protocol, so it would not be possible to record the endianness of all
1047integral fields.
1048
1049strings (FIELDCONVERT)
1050----------------------
1051-- value_string
1052Some integer fields, of type FT_UINT*, need labels to represent the true
1053value of a field. You could think of those fields as having an
1054enumerated data type, rather than an integral data type.
1055
1056A 'value_string' structure is a way to map values to strings.
1057
1058 typedef struct _value_string {
1059 guint32 value;
1060 gchar *strptr;
1061 } value_string;
1062
1063For fields of that type, you would declare an array of "value_string"s:
1064
1065 static const value_string valstringname[] = {
1066 { INTVAL1, "Descriptive String 1" },
1067 { INTVAL2, "Descriptive String 2" },
1068 { 0, NULL }
1069 };
1070
1071(the last entry in the array must have a NULL 'strptr' value, to
1072indicate the end of the array). The 'strings' field would be set to
1073'VALS(valstringname)'.
1074
1075If the field has a numeric rather than an enumerated type, the 'strings'
1076field would be set to NULL.
1077
1078If BASE_SPECIAL_VALS is also applied to the display bitmask, then if the
1079numeric value of a field doesn't match any values in the value_string
1080then just the numeric value is displayed (i.e. no "Unknown"). This is
1081intended for use when the value_string only gives special names for
1082certain field values and values not in the value_string are expected.
1083
1084-- Extended value strings
1085You can also use an extended version of the value_string for faster lookups.
1086It requires a value_string array as input.
1087If all of a contiguous range of values from min to max are present in the array
1088in ascending order the value will be used as a direct index into a value_string array.
1089
1090If the values in the array are not contiguous (ie: there are "gaps"), but are
1091in ascending order a binary search will be used.
1092
1093Note: "gaps" in a value_string array can be filled with "empty" entries eg:
1094{value, "Unknown"} so that direct access to the array is is possible.
1095
1096Note: the value_string array values are *unsigned*; IOW: -1 is greater than 0.
1097 So:
1098 { -2, -1, 1, 2 }; wrong: linear search will be used (note gap)
1099 { 1, 2, -2, -1 }; correct: binary search will be used
1100
1101 As a special case:
1102 { -2, -1, 0, 1, 2 }; OK: direct(indexed) access will be used (note no gap)
1103
1104The init macro (see below) will perform a check on the value string the first
1105time it is used to determine which search algorithm fits and fall back to a
1106linear search if the value_string does not meet the criteria above.
1107
1108Use this macro to initialize the extended value_string at compile time:
1109
1110static value_string_ext valstringname_ext = VALUE_STRING_EXT_INIT(valstringname);
1111
1112Extended value strings can be created at run time by calling
1113 value_string_ext_new(<ptr to value_string array>,
1114 <total number of entries in the value_string_array>, /* include {0, NULL} entry */
1115 <value_string_name>);
1116
1117For hf[] array FT_(U)INT* fields that need a 'valstringname_ext' struct, the
1118'strings' field would be set to '&valstringname_ext'. Furthermore, the 'display'
1119field must be ORed with 'BASE_EXT_STRING' (e.g. BASE_DEC|BASE_EXT_STRING).
1120
1121-- val64_string
1122
1123val64_strings are like value_strings, except that the integer type
1124used is a guint64 (instead of guint32). Instead of using the VALS()
1125macro for the 'strings' field in the header_field_info struct array,
1126'VALS64()' is used.
1127
1128BASE_SPECIAL_VALS can also be used for val64_string.
1129
1130-- val64_string_ext
1131
1132val64_string_ext is like value_string_ext, except that the integer type
1133used is a guint64 (instead of guint32).
1134
1135Use this macro to initialize the extended val64_string at compile time:
1136
1137static val64_string_ext val64stringname_ext = VAL64_STRING_EXT_INIT(val64stringname);
1138
1139Extended val64 strings can be created at run time by calling
1140 val64_string_ext_new(<ptr to val64_string array>,
1141 <total number of entries in the val64_string_array>, /* include {0, NULL} entry */
1142 <val64_string_name>);
1143
1144For hf[] array FT_(U)INT* fields that need a 'val64stringname_ext' struct, the
1145'strings' field would be set to '&val64stringname_ext'. Furthermore, the 'display'
1146field must be ORed with both 'BASE_EXT_STRING' and 'BASE_VAL64_STRING'
1147(e.g. BASE_DEC|BASE_EXT_STRING|BASE_VAL64_STRING).
1148
1149-- Unit string
1150Some integer fields, of type FT_UINT* and float fields, of type FT_FLOAT
1151or FT_DOUBLE, need units of measurement to help convey the field value.
1152
1153A 'unit_name_string' structure is a way to add a unit suffix to a field.
1154
1155 typedef struct unit_name_string {
1156 char *singular; /* name to use for 1 unit */
1157 char *plural; /* name to use for < 1 or > 1 units */
1158 } unit_name_string;
1159
1160For fields with that unit name, you would declare a "unit_name_string":
1161
1162 static const unit_name_string unitname[] =
1163 { "single item name" , "multiple item name" };
1164
1165(the second entry can be NULL if there is no plural form of the unit name.
1166This is typically the case when abbreviations are used instead of full words.)
1167
1168There are several "common" unit name structures already defined in
1169epan/unit_strings.h. Dissector authors may choose to add the unit name
1170structure there rather than locally in a dissector.
1171
1172For hf[] array FT_(U)INT*, FT_FlOAT and FT_DOUBLE fields that need a
1173'unit_name_string' struct, the 'strings' field would be set to
1174'&units_second_seconds'. Furthermore, the 'display' field must be ORed
1175with 'BASE_UNIT_STRING' (e.g. BASE_DEC|BASE_UNIT_STRING).
1176
1177-- Ranges
1178If the field has a numeric type that might logically fit in ranges of values
1179one can use a range_string struct.
1180
1181Thus a 'range_string' structure is a way to map ranges to strings.
1182
1183 typedef struct _range_string {
1184 guint32 value_min;
1185 guint32 value_max;
1186 const gchar *strptr;
1187 } range_string;
1188
1189For fields of that type, you would declare an array of "range_string"s:
1190
1191 static const range_string rvalstringname[] = {
1192 { INTVAL_MIN1, INTVALMAX1, "Descriptive String 1" },
1193 { INTVAL_MIN2, INTVALMAX2, "Descriptive String 2" },
1194 { 0, 0, NULL }
1195 };
1196
1197If INTVAL_MIN equals INTVAL_MAX for a given entry the range_string
1198behavior collapses to the one of value_string. Note that each range_string
1199within the array is tested in order, so any 'catch-all' entries need to come
1200after specific individual entries.
1201
1202For FT_(U)INT* fields that need a 'range_string' struct, the 'strings' field
1203would be set to 'RVALS(rvalstringname)'. Furthermore, 'display' field must be
1204ORed with 'BASE_RANGE_STRING' (e.g. BASE_DEC|BASE_RANGE_STRING).
1205
1206-- Booleans
1207FT_BOOLEANs have a default map of 0 = "False", 1 (or anything else) = "True".
1208Sometimes it is useful to change the labels for boolean values (e.g.,
1209to "Yes"/"No", "Fast"/"Slow", etc.). For these mappings, a struct called
1210true_false_string is used.
1211
1212 typedef struct true_false_string {
1213 char *true_string;
1214 char *false_string;
1215 } true_false_string;
1216
1217For Boolean fields for which "False" and "True" aren't the desired
1218labels, you would declare a "true_false_string"s:
1219
1220 static const true_false_string boolstringname = {
1221 "String for True",
1222 "String for False"
1223 };
1224
1225Its two fields are pointers to the string representing truth, and the
1226string representing falsehood. For FT_BOOLEAN fields that need a
1227'true_false_string' struct, the 'strings' field would be set to
1228'TFS(&boolstringname)'.
1229
1230If the Boolean field is to be displayed as "False" or "True", the
1231'strings' field would be set to NULL.
1232
1233Wireshark predefines a whole range of ready made "true_false_string"s
1234in tfs.h, included via packet.h.
1235
1236-- Custom
1237Custom fields (BASE_CUSTOM) should use CF_FUNC(&custom_format_func) for the
1238'strings' field.
1239
1240-- Note to plugin authors
1241Data cannot get exported from DLLs. For this reason plugin authors cannot use
1242existing fieldconvert strings (e.g. from existing dissectors or those from
1243epan/unit_strings.h). Plugins must define value_strings, unit_name_strings,
1244range_strings and true_false_strings locally.
1245
1246bitmask (BITMASK)
1247-----------------
1248If the field is a bitfield, then the bitmask is the mask which will
1249leave only the bits needed to make the field when ANDed with a value.
1250The proto_tree routines will calculate 'bitshift' automatically
1251from 'bitmask', by finding the rightmost set bit in the bitmask.
1252This shift is applied before applying string mapping functions or
1253filtering.
1254
1255If the field is not a bitfield, then bitmask should be set to 0.
1256
1257blurb (FIELDDESCR)
1258------------------
1259This is a string giving a proper description of the field. It should be
1260at least one grammatically complete sentence, or NULL in which case the
1261name field is used. (Please do not use "").
1262
1263It is meant to provide a more detailed description of the field than the
1264name alone provides. This information will be used in the man page, and
1265in a future GUI display-filter creation tool. We might also add tooltips
1266to the labels in the GUI protocol tree, in which case the blurb would
1267be used as the tooltip text.
1268
1269
12701.5.1 Field Registration.
1271
1272Protocol registration is handled by creating an instance of the
1273header_field_info struct (or an array of such structs), and
1274calling the registration function along with the registration ID of
1275the protocol that is the parent of the fields. Here is a complete example:
1276
1277 static int proto_eg = -1;
1278 static int hf_field_a = -1;
1279 static int hf_field_b = -1;
1280
1281 static hf_register_info hf[] = {
1282
1283 { &hf_field_a,
1284 { "Field A", "proto.field_a", FT_UINT8, BASE_HEX, NULL,
1285 0xf0, "Field A represents Apples", HFILL }},
1286
1287 { &hf_field_b,
1288 { "Field B", "proto.field_b", FT_UINT16, BASE_DEC, VALS(vs),
1289 0x0, "Field B represents Bananas", HFILL }}
1290 };
1291
1292 proto_eg = proto_register_protocol("Example Protocol",
1293 "PROTO", "proto");
1294 proto_register_field_array(proto_eg, hf, array_length(hf));
1295
1296Be sure that your array of hf_register_info structs is declared 'static',
1297since the proto_register_field_array() function does not create a copy
1298of the information in the array... it uses that static copy of the
1299information that the compiler created inside your array. Here's the
1300layout of the hf_register_info struct:
1301
1302typedef struct hf_register_info {
1303 int *p_id; /* pointer to parent variable */
1304 header_field_info hfinfo;
1305} hf_register_info;
1306
1307Also be sure to use the handy array_length() macro found in packet.h
1308to have the compiler compute the array length for you at compile time.
1309
1310If you don't have any fields to register, do *NOT* create a zero-length
1311"hf" array; not all compilers used to compile Wireshark support them.
1312Just omit the "hf" array, and the "proto_register_field_array()" call,
1313entirely.
1314
1315It is OK to have header fields with a different format be registered with
1316the same abbreviation. For instance, the following is valid:
1317
1318 static hf_register_info hf[] = {
1319
1320 { &hf_field_8bit, /* 8-bit version of proto.field */
1321 { "Field (8 bit)", "proto.field", FT_UINT8, BASE_DEC, NULL,
1322 0x00, "Field represents FOO", HFILL }},
1323
1324 { &hf_field_32bit, /* 32-bit version of proto.field */
1325 { "Field (32 bit)", "proto.field", FT_UINT32, BASE_DEC, NULL,
1326 0x00, "Field represents FOO", HFILL }}
1327 };
1328
1329This way a filter expression can match a header field, irrespective of the
1330representation of it in the specific protocol context. This is interesting
1331for protocols with variable-width header fields.
1332
1333Note that the formats used must all belong to the same group as defined below:
1334- FT_INT8, FT_INT16, FT_INT24 and FT_INT32
1335- FT_CHAR, FT_UINT8, FT_UINT16, FT_UINT24, FT_UINT32, FT_IPXNET and FT_FRAMENUM
1336- FT_INT40, FT_INT48, FT_INT56 and FT_INT64
1337- FT_UINT40, FT_UINT48, FT_UINT56, FT_UINT64 and FT_EUI64
1338- FT_ABSOLUTE_TIME and FT_RELATIVE_TIME
1339- FT_STRING, FT_STRINGZ, FT_UINT_STRING, FT_STRINGZPAD, and FT_STRINGZTRUNC
1340- FT_FLOAT and FT_DOUBLE
1341- FT_BYTES, FT_UINT_BYTES, FT_ETHER, FT_AX25, FT_VINES and FT_FCWWN
1342- FT_OID, FT_REL_OID and FT_SYSTEM_ID
1343
1344Any field not in a grouping above should *NOT* be used in duplicate field
1345abbreviations. The current code does not prevent it, but someday in the future
1346it might.
1347
1348The HFILL macro at the end of the struct will set reasonable default values
1349for internally used fields.
1350
13511.5.2 Adding Items and Values to the Protocol Tree.
1352
1353A protocol item is added to an existing protocol tree with one of a
1354handful of proto_XXX_DO_YYY() functions.
1355
1356Subtrees can be made with the proto_item_add_subtree() function:
1357
1358 item = proto_tree_add_item(....);
1359 new_tree = proto_item_add_subtree(item, tree_type);
1360
1361This will add a subtree under the item in question; a subtree can be
1362created under an item made by any of the "proto_tree_add_XXX" functions,
1363so that the tree can be given an arbitrary depth.
1364
1365Subtree types are integers, assigned by
1366"proto_register_subtree_array()". To register subtree types, pass an
1367array of pointers to "gint" variables to hold the subtree type values to
1368"proto_register_subtree_array()":
1369
1370 static gint ett_eg = -1;
1371 static gint ett_field_a = -1;
1372
1373 static gint *ett[] = {
1374 &ett_eg,
1375 &ett_field_a
1376 };
1377
1378 proto_register_subtree_array(ett, array_length(ett));
1379
1380in your "register" routine, just as you register the protocol and the
1381fields for that protocol.
1382
1383The ett_ variables identify particular type of subtree so that if you expand
1384one of them, Wireshark keeps track of that and, when you click on
1385another packet, it automatically opens all subtrees of that type.
1386If you close one of them, all subtrees of that type will be closed when
1387you move to another packet.
1388
1389There are many functions that the programmer can use to add either
1390protocol or field labels to the proto_tree, for example:
1391
1392 proto_item*
1393 proto_tree_add_item(tree, id, tvb, start, length, encoding);
1394
1395 proto_item*
1396 proto_tree_add_item_ret_int(tree, id, tvb, start, length, encoding,
1397 *retval);
1398
1399 proto_item*
1400 proto_tree_add_subtree(tree, tvb, start, length, idx, tree_item,
1401 text);
1402
1403 proto_item *
1404 proto_tree_add_int_format_value(tree, id, tvb, start, length,
1405 value, format, ...);
1406
1407 proto_item *
1408 proto_tree_add_checksum(proto_tree *tree, tvbuff_t *tvb, const guint offset,
1409 const int hf_checksum, const int hf_checksum_status,
1410 struct expert_field* bad_checksum_expert, packet_info *pinfo,
1411 guint32 computed_checksum, const guint encoding, const guint flags);
1412
1413 proto_item *
1414 proto_tree_add_bitmask(tree, tvb, start, header, ett, fields,
1415 encoding);
1416
1417 proto_item *
1418 proto_tree_add_bits_item(tree, id, tvb, bit_offset, no_of_bits,
1419 encoding);
1420
1421The 'tree' argument is the tree to which the item is to be added. The
1422'tvb' argument is the tvbuff from which the item's value is being
1423extracted; the 'start' argument is the offset from the beginning of that
1424tvbuff of the item being added, and the 'length' argument is the length,
1425in bytes, of the item, bit_offset is the offset in bits and no_of_bits
1426is the length in bits.
1427
1428The length of some items cannot be determined until the item has been
1429dissected; to add such an item, add it with a length of -1, and, when the
1430dissection is complete, set the length with 'proto_item_set_len()':
1431
1432 void
1433 proto_item_set_len(ti, length);
1434
1435The "ti" argument is the value returned by the call that added the item
1436to the tree, and the "length" argument is the length of the item.
1437
1438All available protocol tree functions are declared in epan/proto.h, with
1439their documentation. The details of these functions and their parameters
1440are described below.
1441
1442proto_tree_add_item()
1443---------------------
1444proto_tree_add_item is used when you wish to do no special formatting.
1445The item added to the GUI tree will contain the name (as passed in the
1446proto_register_*() function) and a value. The value will be fetched
1447from the tvbuff by proto_tree_add_item(), based on the type of the field
1448and the encoding of the value as specified by the "encoding" argument.
1449
1450For FT_NONE, FT_BYTES, FT_ETHER, FT_IPv6, FT_IPXNET, FT_OID, FT_REL_OID,
1451FT_AX25, FT_VINES, FT_SYSTEM_ID, FT_FCWWN fields, and 'protocol' fields
1452the encoding is not relevant; the 'encoding' argument should be
1453ENC_NA (Not Applicable).
1454
1455For FT_UINT_BYTES fields, the byte order of the count must be specified
1456as well as the 'encoding' for bytes which should be ENC_NA,
1457i.e. ENC_LITTLE_ENDIAN|ENC_NA
1458
1459For integral, floating-point, Boolean, FT_GUID, and FT_EUI64 fields,
1460the encoding specifies the byte order of the value; the 'encoding'
1461argument should be ENC_LITTLE_ENDIAN if the value is little-endian
1462and ENC_BIG_ENDIAN if it is big-endian.
1463
1464For FT_IPv4 fields, the encoding also specifies the byte order of the
1465value. In almost all cases, the encoding is in network byte order,
1466hence big-endian, but in at least one protocol dissected by Wireshark,
1467at least one IPv4 address is byte-swapped, so it's in little-endian
1468order.
1469
1470For string fields, the encoding specifies the character set used for the
1471string and the way individual code points in that character set are
1472encoded. For FT_UINT_STRING fields, the byte order of the count must be
1473specified; for UCS-2 and UTF-16, the byte order of the encoding must be
1474specified (for counted UCS-2 and UTF-16 strings, the byte order of the
1475count and the 16-bit values in the string must be the same). In other
1476cases, ENC_NA should be used. The character encodings that are
1477currently supported are:
1478
1479 ENC_ASCII - ASCII (currently treated as UTF-8; in the future,
1480 all bytes with the 8th bit set will be treated as
1481 errors)
1482 ENC_UTF_8 - UTF-8-encoded Unicode
1483 ENC_UTF_16 - UTF-16-encoded Unicode, with surrogate pairs
1484 ENC_UCS_2 - UCS-2-encoded subset of Unicode, with no surrogate pairs
1485 and thus no code points above 0xFFFF
1486 ENC_UCS_4 - UCS-4-encoded Unicode
1487 ENC_WINDOWS_1250 - Windows-1250 code page
1488 ENC_WINDOWS_1251 - Windows-1251 code page
1489 ENC_WINDOWS_1252 - Windows-1252 code page
1490 ENC_ISO_646_BASIC - ISO 646 "basic code table"
1491 ENC_ISO_8859_1 - ISO 8859-1
1492 ENC_ISO_8859_2 - ISO 8859-2
1493 ENC_ISO_8859_3 - ISO 8859-3
1494 ENC_ISO_8859_4 - ISO 8859-4
1495 ENC_ISO_8859_5 - ISO 8859-5
1496 ENC_ISO_8859_6 - ISO 8859-6
1497 ENC_ISO_8859_7 - ISO 8859-7
1498 ENC_ISO_8859_8 - ISO 8859-8
1499 ENC_ISO_8859_9 - ISO 8859-9
1500 ENC_ISO_8859_10 - ISO 8859-10
1501 ENC_ISO_8859_11 - ISO 8859-11
1502 ENC_ISO_8859_13 - ISO 8859-13
1503 ENC_ISO_8859_14 - ISO 8859-14
1504 ENC_ISO_8859_15 - ISO 8859-15
1505 ENC_ISO_8859_16 - ISO 8859-16
1506 ENC_3GPP_TS_23_038_7BITS - GSM 7 bits alphabet as described
1507 in 3GPP TS 23.038
1508 ENC_3GPP_TS_23_038_7BITS_UNPACKED - GSM 7 bits alphabet where each
1509 7 bit character occupies a distinct octet
1510 ENC_ETSI_TS_102_221_ANNEX_A - Coding scheme for SIM cards with GSM 7 bit
1511 alphabet, UCS-2 characters, or a mixture of the two as described
1512 in ETSI TS 102 221 Annex A
1513 ENC_EBCDIC - EBCDIC
1514 ENC_EBCDIC_CP037 - EBCDIC code page 037
1515 ENC_MAC_ROMAN - MAC ROMAN
1516 ENC_CP437 - DOS code page 437
1517 ENC_CP855 - DOS code page 855
1518 ENC_CP866 - DOS code page 866
1519 ENC_ASCII_7BITS - 7 bits ASCII
1520 ENC_T61 - ITU T.61
1521 ENC_BCD_DIGITS_0_9 - packed BCD (one digit per nibble), digits 0-9
1522 ENC_KEYPAD_ABC_TBCD - keypad-with-a/b/c "telephony packed BCD" = 0-9, *, #, a, b, c
1523 ENC_KEYPAD_BC_TBCD - keypad-with-B/C "telephony packed BCD" = 0-9, B, C, *, #
1524 ENC_GB18030 - GB 18030
1525 ENC_EUC_KR - EUC-KR
1526
1527Other encodings will be added in the future.
1528
1529For FT_ABSOLUTE_TIME fields, the encoding specifies the form in which
1530the time stamp is specified, as well as its byte order. The time stamp
1531encodings that are currently supported are:
1532
1533 ENC_TIME_SECS_NSECS - 8, 12, or 16 bytes. For 8 bytes, the first 4
1534 bytes are seconds and the next 4 bytes are nanoseconds; for 12
1535 bytes, the first 8 bytes are seconds and the next 4 bytes are
1536 nanoseconds; for 16 bytes, the first 8 bytes are seconds and
1537 the next 8 bytes are nanoseconds. The seconds are seconds
1538 since the UN*X epoch (1970-01-01 00:00:00 UTC). (I.e., a UN*X
1539 struct timespec with a 4-byte or 8-byte time_t or a structure
1540 with an 8-byte time_t and an 8-byte nanoseconds field.)
1541
1542 ENC_TIME_NTP - 8 bytes; the first 4 bytes are seconds since the NTP
1543 epoch (1900-01-01 00:00:00 GMT) and the next 4 bytes are 1/2^32's of
1544 a second since that second. (I.e., a 64-bit count of 1/2^32's of a
1545 second since the NTP epoch, with the upper 32 bits first and the
1546 lower 32 bits second, even when little-endian.)
1547
1548 ENC_TIME_TOD - 8 bytes, as a count of microseconds since the System/3x0
1549 and z/Architecture epoch (1900-01-01 00:00:00 GMT).
1550
1551 ENC_TIME_RTPS - 8 bytes; the first 4 bytes are seconds since the UN*X
1552 epoch and the next 4 bytes are 1/2^32's of a second since that
1553 second. (I.e., it's the offspring of a mating between UN*X time and
1554 NTP time). It's used by the Object Management Group's Real-Time
1555 Publish-Subscribe Wire Protocol for the Data Distribution Service.
1556
1557 ENC_TIME_SECS_USECS - 8 bytes; the first 4 bytes are seconds since the
1558 UN*X epoch and the next 4 bytes are microseconds since that
1559 second. (I.e., a UN*X struct timeval with a 4-byte time_t.)
1560
1561 ENC_TIME_SECS - 4 to 8 bytes, representing a value in seconds since
1562 the UN*X epoch.
1563
1564 ENC_TIME_MSECS - 6 to 8 bytes, representing a value in milliseconds
1565 since the UN*X epoch.
1566
1567 ENC_TIME_NSECS - 8 bytes, representing a value in nanoseconds since
1568 the UN*X epoch.
1569
1570 ENC_TIME_SECS_NTP - 4 bytes, representing a count of seconds since
1571 the NTP epoch.
1572
1573 ENC_TIME_RFC_3971 - 8 bytes, representing a count of 1/64ths of a
1574 second since the UN*X epoch; see section 5.3.1 "Timestamp Option"
1575 in RFC 3971.
1576
1577 ENC_TIME_MSEC_NTP - 4-8 bytes, representing a count of milliseconds since
1578 the NTP epoch.
1579
1580 ENC_MIP6 - 8 bytes; the first 48 bits are seconds since the UN*X epoch
1581 and the remaining 16 bits indicate the number of 1/65536's of a second
1582 since that second.
1583
1584 ENC_TIME_CLASSIC_MAC_OS_SECS - 4-8 bytes, representing a count of seconds
1585 since January 1, 1904, 00:00:00 UTC.
1586
1587For FT_RELATIVE_TIME fields, the encoding specifies the form in which
1588the time stamp is specified, as well as its byte order. The time stamp
1589encodings that are currently supported are:
1590
1591 ENC_TIME_SECS_NSECS - 8, 12, or 16 bytes. For 8 bytes, the first 4
1592 bytes are seconds and the next 4 bytes are nanoseconds; for 12
1593 bytes, the first 8 bytes are seconds and the next 4 bytes are
1594 nanoseconds; for 16 bytes, the first 8 bytes are seconds and
1595 the next 8 bytes are nanoseconds.
1596
1597 ENC_TIME_SECS_USECS - 8 bytes; the first 4 bytes are seconds and the
1598 next 4 bytes are microseconds.
1599
1600 ENC_TIME_SECS - 4 to 8 bytes, representing a value in seconds.
1601
1602 ENC_TIME_MSECS - 6 to 8 bytes, representing a value in milliseconds.
1603
1604 ENC_TIME_NSECS - 8 bytes, representing a value in nanoseconds.
1605
1606For other types, there is no support for proto_tree_add_item().
1607
1608Now that definitions of fields have detailed information about bitfield
1609fields, you can use proto_tree_add_item() with no extra processing to
1610add bitfield values to your tree. Here's an example. Take the Format
1611Identifier (FID) field in the Transmission Header (TH) portion of the SNA
1612protocol. The FID is the high nibble of the first byte of the TH. The
1613FID would be registered like this:
1614
1615 name = "Format Identifier"
1616 abbrev = "sna.th.fid"
1617 type = FT_UINT8
1618 display = BASE_HEX
1619 strings = sna_th_fid_vals
1620 bitmask = 0xf0
1621
1622The bitmask contains the value which would leave only the FID if bitwise-ANDed
1623against the parent field, the first byte of the TH.
1624
1625The code to add the FID to the tree would be;
1626
1627 proto_tree_add_item(bf_tree, hf_sna_th_fid, tvb, offset, 1,
1628 ENC_BIG_ENDIAN);
1629
1630The definition of the field already has the information about bitmasking
1631and bitshifting, so it does the work of masking and shifting for us!
1632This also means that you no longer have to create value_string structs
1633with the values bitshifted. The value_string for FID looks like this,
1634even though the FID value is actually contained in the high nibble.
1635(You'd expect the values to be 0x0, 0x10, 0x20, etc.)
1636
1637/* Format Identifier */
1638static const value_string sna_th_fid_vals[] = {
1639 { 0x0, "SNA device <--> Non-SNA Device" },
1640 { 0x1, "Subarea Node <--> Subarea Node" },
1641 { 0x2, "Subarea Node <--> PU2" },
1642 { 0x3, "Subarea Node or SNA host <--> Subarea Node" },
1643 { 0x4, "?" },
1644 { 0x5, "?" },
1645 { 0xf, "Adjacent Subarea Nodes" },
1646 { 0, NULL }
1647};
1648
1649The final implication of this is that display filters work the way you'd
1650naturally expect them to. You'd type "sna.th.fid == 0xf" to find Adjacent
1651Subarea Nodes. The user does not have to shift the value of the FID to
1652the high nibble of the byte ("sna.th.fid == 0xf0") as was necessary
1653in the past.
1654
1655proto_tree_add_item_ret_XXX()
1656------------------------------
1657proto_tree_add_item_ret_XXX is used when you want the displayed value returned
1658for further processing only integer and unsigned integer types up to 32 bits are
1659supported usage of proper FT_ is checked.
1660
1661proto_tree_add_XXX_item()
1662---------------------
1663proto_tree_add_XXX_item is used when you wish to do no special formatting,
1664but also either wish for the retrieved value from the tvbuff to be handed
1665back (to avoid doing tvb_get_...), and/or wish to have the value be decoded
1666from the tvbuff in a string-encoded format.
1667
1668The item added to the GUI tree will contain the name (as passed in the
1669proto_register_*() function) and a value. The value will be fetched
1670from the tvbuff, based on the type of the XXX name and the encoding of
1671the value as specified by the "encoding" argument.
1672
1673This function retrieves the value even if the passed-in tree param is NULL,
1674so that it can be used by dissectors at all times to both get the value
1675and set the tree item to it.
1676
1677Like other proto_tree_add functions, if there is a tree and the value cannot
1678be decoded from the tvbuff, then an expert info error is reported. For string
1679encoding, this means that a failure to decode the hex value from the string
1680results in an expert info error being added to the tree.
1681
1682For string-decoding, the passed-in encoding argument needs to specify the
1683string encoding (e.g., ENC_ASCII, ENC_UTF_8) as well as the format. For
1684some XXX types, the format is constrained - for example for the encoding format
1685for proto_tree_add_time_item() can only be one of the ENC_ISO_8601_* ones
1686or ENC_RFC_822 or ENC_RFC_1123. For proto_tree_add_bytes_item() it can only
1687be ENC_STR_HEX bit-or'ed with one or more of the ENC_SEP_* separator types.
1688
1689proto_tree_add_protocol_format()
1690--------------------------------
1691proto_tree_add_protocol_format is used to add the top-level item for the
1692protocol when the dissector routine wants complete control over how the
1693field and value will be represented on the GUI tree. The ID value for
1694the protocol is passed in as the "id" argument; the rest of the
1695arguments are a "printf"-style format and any arguments for that format.
1696The caller must include the name of the protocol in the format; it is
1697not added automatically as in proto_tree_add_item().
1698
1699proto_tree_add_none_format()
1700----------------------------
1701proto_tree_add_none_format is used to add an item of type FT_NONE.
1702The caller must include the name of the field in the format; it is
1703not added automatically as in proto_tree_add_item().
1704
1705proto_tree_add_bytes()
1706proto_tree_add_time()
1707proto_tree_add_ipxnet()
1708proto_tree_add_ipv4()
1709proto_tree_add_ipv6()
1710proto_tree_add_ether()
1711proto_tree_add_string()
1712proto_tree_add_boolean()
1713proto_tree_add_float()
1714proto_tree_add_double()
1715proto_tree_add_uint()
1716proto_tree_add_uint64()
1717proto_tree_add_int()
1718proto_tree_add_int64()
1719proto_tree_add_guid()
1720proto_tree_add_oid()
1721proto_tree_add_eui64()
1722------------------------
1723These routines are used to add items to the protocol tree if either:
1724
1725 the value of the item to be added isn't just extracted from the
1726 packet data, but is computed from data in the packet;
1727
1728 the value was fetched into a variable.
1729
1730The 'value' argument has the value to be added to the tree.
1731
1732NOTE: in all cases where the 'value' argument is a pointer, a copy is
1733made of the object pointed to; if you have dynamically allocated a
1734buffer for the object, that buffer will not be freed when the protocol
1735tree is freed - you must free the buffer yourself when you don't need it
1736any more.
1737
1738For proto_tree_add_bytes(), the 'value_ptr' argument is a pointer to a
1739sequence of bytes.
1740
1741
1742proto_tree_add_bytes_with_length() is similar to proto_tree_add_bytes,
1743except that the length is not derived from the tvb length. Instead,
1744the displayed data size is controlled by 'ptr_length'.
1745
1746For proto_tree_add_bytes_format() and proto_tree_add_bytes_format_value(), the
1747'value_ptr' argument is a pointer to a sequence of bytes or NULL if the bytes
1748should be taken from the given TVB using the given offset and length.
1749
1750For proto_tree_add_time(), the 'value_ptr' argument is a pointer to an
1751"nstime_t", which is a structure containing the time to be added; it has
1752'secs' and 'nsecs' members, giving the integral part and the fractional
1753part of a time in units of seconds, with 'nsecs' being the number of
1754nanoseconds. For absolute times, "secs" is a UNIX-style seconds since
1755January 1, 1970, 00:00:00 GMT value.
1756
1757For proto_tree_add_ipxnet(), the 'value' argument is a 32-bit IPX
1758network address.
1759
1760For proto_tree_add_ipv4(), the 'value' argument is a 32-bit IPv4
1761address, in network byte order.
1762
1763For proto_tree_add_ipv6(), the 'value_ptr' argument is a pointer to a
1764128-bit IPv6 address.
1765
1766For proto_tree_add_ether(), the 'value_ptr' argument is a pointer to a
176748-bit MAC address.
1768
1769For proto_tree_add_string(), the 'value_ptr' argument is a pointer to a
1770text string; this string must be NULL terminated even if the string in the
1771TVB is not (as may be the case with FT_STRINGs).
1772
1773For proto_tree_add_boolean(), the 'value' argument is a 32-bit integer.
1774It is masked and shifted as defined by the field info after which zero
1775means "false", and non-zero means "true".
1776
1777For proto_tree_add_float(), the 'value' argument is a 'float' in the
1778host's floating-point format.
1779
1780For proto_tree_add_double(), the 'value' argument is a 'double' in the
1781host's floating-point format.
1782
1783For proto_tree_add_uint(), the 'value' argument is a 32-bit unsigned
1784integer value, in host byte order. (This routine cannot be used to add
178564-bit integers.)
1786
1787For proto_tree_add_uint64(), the 'value' argument is a 64-bit unsigned
1788integer value, in host byte order.
1789
1790For proto_tree_add_int(), the 'value' argument is a 32-bit signed
1791integer value, in host byte order. (This routine cannot be used to add
179264-bit integers.)
1793
1794For proto_tree_add_int64(), the 'value' argument is a 64-bit signed
1795integer value, in host byte order.
1796
1797For proto_tree_add_guid(), the 'value_ptr' argument is a pointer to an
1798e_guid_t structure.
1799
1800For proto_tree_add_oid(), the 'value_ptr' argument is a pointer to an
1801ASN.1 Object Identifier.
1802
1803For proto_tree_add_eui64(), the 'value' argument is a 64-bit integer
1804value
1805
1806proto_tree_add_bytes_format()
1807proto_tree_add_time_format()
1808proto_tree_add_ipxnet_format()
1809proto_tree_add_ipv4_format()
1810proto_tree_add_ipv6_format()
1811proto_tree_add_ether_format()
1812proto_tree_add_string_format()
1813proto_tree_add_boolean_format()
1814proto_tree_add_float_format()
1815proto_tree_add_double_format()
1816proto_tree_add_uint_format()
1817proto_tree_add_uint64_format()
1818proto_tree_add_int_format()
1819proto_tree_add_int64_format()
1820proto_tree_add_guid_format()
1821proto_tree_add_oid_format()
1822proto_tree_add_eui64_format()
1823----------------------------
1824These routines are used to add items to the protocol tree when the
1825dissector routine wants complete control over how the field and value
1826will be represented on the GUI tree. The argument giving the value is
1827the same as the corresponding proto_tree_add_XXX() function; the rest of
1828the arguments are a "printf"-style format and any arguments for that
1829format. The caller must include the name of the field in the format; it
1830is not added automatically as in the proto_tree_add_XXX() functions.
1831
1832proto_tree_add_bytes_format_value()
1833proto_tree_add_time_format_value()
1834proto_tree_add_ipxnet_format_value()
1835proto_tree_add_ipv4_format_value()
1836proto_tree_add_ipv6_format_value()
1837proto_tree_add_ether_format_value()
1838proto_tree_add_string_format_value()
1839proto_tree_add_boolean_format_value()
1840proto_tree_add_float_format_value()
1841proto_tree_add_double_format_value()
1842proto_tree_add_uint_format_value()
1843proto_tree_add_uint64_format_value()
1844proto_tree_add_int_format_value()
1845proto_tree_add_int64_format_value()
1846proto_tree_add_guid_format_value()
1847proto_tree_add_oid_format_value()
1848proto_tree_add_eui64_format_value()
1849------------------------------------
1850
1851These routines are used to add items to the protocol tree when the
1852dissector routine wants complete control over how the value will be
1853represented on the GUI tree. The argument giving the value is the same
1854as the corresponding proto_tree_add_XXX() function; the rest of the
1855arguments are a "printf"-style format and any arguments for that format.
1856With these routines, unlike the proto_tree_add_XXX_format() routines,
1857the name of the field is added automatically as in the
1858proto_tree_add_XXX() functions; only the value is added with the format.
1859One use case for this would be to add a unit of measurement string to
1860the value of the field, however using BASE_UNIT_STRING in the hf_
1861definition is now preferred.
1862
1863proto_tree_add_checksum()
1864----------------------------
1865proto_tree_add_checksum is used to add a checksum field. The hf field
1866provided must be the correct size of the checksum (FT_UINT, FT_UINT16,
1867FT_UINT32, etc). Additional parameters are there to provide "status"
1868and expert info depending on whether the checksum matches the provided
1869value. The "status" and expert info can be used in cases except
1870where PROTO_CHECKSUM_NO_FLAGS is used.
1871
1872proto_tree_add_subtree()
1873---------------------
1874proto_tree_add_subtree() is used to add a label to the GUI tree and create
1875a subtree for other fields. It will contain no value, so it is not searchable
1876in the display filter process.
1877
1878This should only be used for items with subtrees, which may not
1879have values themselves - the items in the subtree are the ones with values.
1880
1881For a subtree, the label on the subtree might reflect some of the items
1882in the subtree. This means the label can't be set until at least some
1883of the items in the subtree have been dissected. To do this, use
1884'proto_item_set_text()' or 'proto_item_append_text()':
1885
1886 void
1887 proto_item_set_text(proto_item *ti, ...);
1888
1889 void
1890 proto_item_append_text(proto_item *ti, ...);
1891
1892'proto_item_set_text()' takes as an argument the proto_item value returned by
1893one of the parameters in 'proto_tree_add_subtree()', a 'printf'-style format
1894string, and a set of arguments corresponding to '%' format items in that string,
1895and replaces the text for the item created by 'proto_tree_add_subtree()' with the result
1896of applying the arguments to the format string.
1897
1898'proto_item_append_text()' is similar, but it appends to the text for
1899the item the result of applying the arguments to the format string.
1900
1901For example, early in the dissection, one might do:
1902
1903 subtree = proto_tree_add_subtree(tree, tvb, offset, length, ett, &ti, <label>);
1904
1905and later do
1906
1907 proto_item_set_text(ti, "%s: %s", type, value);
1908
1909after the "type" and "value" fields have been extracted and dissected.
1910<label> would be a label giving what information about the subtree is
1911available without dissecting any of the data in the subtree.
1912
1913Note that an exception might be thrown when trying to extract the values of
1914the items used to set the label, if not all the bytes of the item are
1915available. Thus, one should create the item with text that is as
1916meaningful as possible, and set it or append additional information to
1917it as the values needed to supply that information are extracted.
1918
1919proto_tree_add_subtree_format()
1920----------------------------
1921This is like proto_tree_add_subtree(), but uses printf-style arguments to
1922create the label; it is used to allow routines that take a printf-like
1923variable-length list of arguments to add a text item to the protocol
1924tree.
1925
1926proto_tree_add_bits_item()
1927--------------------------
1928Adds a number of bits to the protocol tree which does not have to be byte
1929aligned. The offset and length is in bits.
1930Output format:
1931
1932..10 1010 10.. .... "value" (formatted as FT_ indicates).
1933
1934proto_tree_add_bits_ret_val()
1935-----------------------------
1936Works in the same way but also returns the value of the read bits.
1937
1938proto_tree_add_split_bits_item_ret_val()
1939-----------------------------------
1940Similar, but is used for items that are made of 2 or more smaller sets of bits (crumbs)
1941which are not contiguous, but are concatenated to form the actual value. The size of
1942the crumbs and the order of assembly are specified in an array of crumb_spec structures.
1943
1944proto_tree_add_split_bits_crumb()
1945---------------------------------
1946Helper function for the above, to add text for each crumb as it is encountered.
1947
1948proto_tree_add_ts_23_038_7bits_item()
1949-------------------------------------
1950Adds a string of a given number of characters and encoded according to 3GPP TS 23.038 7 bits
1951alphabet.
1952
1953proto_tree_add_bitmask() et al.
1954-------------------------------
1955These functions provide easy to use and convenient dissection of many types of common
1956bitmasks into individual fields.
1957
1958header is an integer type and must be of type FT_[U]INT{8|16|24|32||40|48|56|64} and
1959represents the entire dissectable width of the bitmask.
1960
1961'header' and 'ett' are the hf fields and ett field respectively to create an
1962expansion that covers the bytes of the bitmask.
1963
1964'fields' is a NULL terminated array of pointers to hf fields representing
1965the individual subfields of the bitmask. These fields must either be integers
1966(usually of the same byte width as 'header') or of the type FT_BOOLEAN.
1967Each of the entries in 'fields' will be dissected as an item under the
1968'header' expansion and also IF the field is a boolean and IF it is set to 1,
1969then the name of that boolean field will be printed on the 'header' expansion
1970line. For integer type subfields that have a value_string defined, the
1971matched string from that value_string will be printed on the expansion line
1972as well.
1973
1974Example: (from the SCSI dissector)
1975 static int hf_scsi_inq_peripheral = -1;
1976 static int hf_scsi_inq_qualifier = -1;
1977 static int hf_scsi_inq_devtype = -1;
1978 ...
1979 static gint ett_scsi_inq_peripheral = -1;
1980 ...
1981 static int * const peripheral_fields[] = {
1982 &hf_scsi_inq_qualifier,
1983 &hf_scsi_inq_devtype,
1984 NULL
1985 };
1986 ...
1987 /* Qualifier and DeviceType */
1988 proto_tree_add_bitmask(tree, tvb, offset, hf_scsi_inq_peripheral,
1989 ett_scsi_inq_peripheral, peripheral_fields, ENC_BIG_ENDIAN);
1990 offset+=1;
1991 ...
1992 { &hf_scsi_inq_peripheral,
1993 {"Peripheral", "scsi.inquiry.peripheral", FT_UINT8, BASE_HEX,
1994 NULL, 0, NULL, HFILL}},
1995 { &hf_scsi_inq_qualifier,
1996 {"Qualifier", "scsi.inquiry.qualifier", FT_UINT8, BASE_HEX,
1997 VALS (scsi_qualifier_val), 0xE0, NULL, HFILL}},
1998 { &hf_scsi_inq_devtype,
1999 {"Device Type", "scsi.inquiry.devtype", FT_UINT8, BASE_HEX,
2000 VALS (scsi_devtype_val), SCSI_DEV_BITS, NULL, HFILL}},
2001 ...
2002
2003Which provides very pretty dissection of this one byte bitmask.
2004
2005 Peripheral: 0x05, Qualifier: Device type is connected to logical unit, Device Type: CD-ROM
2006 000. .... = Qualifier: Device type is connected to logical unit (0x00)
2007 ...0 0101 = Device Type: CD-ROM (0x05)
2008
2009The proto_tree_add_bitmask_text() function is an extended version of
2010the proto_tree_add_bitmask() function. In addition, it allows to:
2011- Provide a leading text (e.g. "Flags: ") that will appear before
2012 the comma-separated list of field values
2013- Provide a fallback text (e.g. "None") that will be appended if
2014 no fields warranted a change to the top-level title.
2015- Using flags, specify which fields will affect the top-level title.
2016
2017There are the following flags defined:
2018
2019 BMT_NO_APPEND - the title is taken "as-is" from the 'name' argument.
2020 BMT_NO_INT - only boolean flags are added to the title.
2021 BMT_NO_FALSE - boolean flags are only added to the title if they are set.
2022 BMT_NO_TFS - only add flag name to the title, do not use true_false_string
2023
2024The proto_tree_add_bitmask_with_flags() function is an extended version
2025of the proto_tree_add_bitmask() function. It allows using flags to specify
2026which fields will affect the top-level title. The flags are the
2027same BMT_NO_* flags as used in the proto_tree_add_bitmask_text() function.
2028
2029The proto_tree_add_bitmask() behavior can be obtained by providing
2030both 'name' and 'fallback' arguments as NULL, and a flags of
2031(BMT_NO_FALSE|BMT_NO_TFS).
2032
2033The proto_tree_add_bitmask_len() function is intended for protocols where
2034bitmask length is permitted to vary, so a length is specified explicitly
2035along with the bitmask value. USB Video "bmControl" and "bControlSize"
2036fields follow this pattern. The primary intent of this is "forward
2037compatibility," enabling an interpreter coded for version M of a structure
2038to comprehend fields in version N of the structure, where N > M and
2039bControlSize increases from version M to version N.
2040
2041proto_tree_add_bitmask_len() is an extended version of proto_tree_add_bitmask()
2042that uses an explicitly specified (rather than inferred) length to control
2043dissection. Because of this, it may encounter two cases that
2044proto_tree_add_bitmask() and proto_tree_add_bitmask_text() may not:
2045- A length that exceeds that of the 'header' and bitmask subfields.
2046 In this case the least-significant bytes of the bitmask are dissected.
2047 An expert warning is generated in this case, because the dissection code
2048 likely needs to be updated for a new revision of the protocol.
2049- A length that is shorter than that of the 'header' and bitmask subfields.
2050 In this case, subfields whose data is fully present are dissected,
2051 and other subfields are not. No warning is generated in this case,
2052 because the dissection code is likely for a later revision of the protocol
2053 than the packet it was called to interpret.
2054
2055
2056proto_item_set_generated()
2057--------------------------
2058proto_item_set_generated is used to mark fields as not being read from the
2059captured data directly, but inferred from one or more values.
2060
2061One of the primary uses of this is the presentation of verification of
2062checksums. Every IP packet has a checksum line, which can present the result
2063of the checksum verification, if enabled in the preferences. The result is
2064presented as a subtree, where the result is enclosed in square brackets
2065indicating a generated field.
2066
2067 Header checksum: 0x3d42 [correct]
2068 [Checksum Status: Good (1)]
2069
2070proto_item_set_hidden()
2071-----------------------
2072proto_item_set_hidden is used to hide fields, which have already been added
2073to the tree, from being visible in the displayed tree.
2074
2075NOTE that creating hidden fields is actually quite a bad idea from a UI design
2076perspective because the user (someone who did not write nor has ever seen the
2077code) has no way of knowing that hidden fields are there to be filtered on
2078thus defeating the whole purpose of putting them there. A Better Way might
2079be to add the fields (that might otherwise be hidden) to a subtree where they
2080won't be seen unless the user opens the subtree--but they can be found if the
2081user wants.
2082
2083One use for hidden fields (which would be better implemented using visible
2084fields in a subtree) follows: The caller may want a value to be
2085included in a tree so that the packet can be filtered on this field, but
2086the representation of that field in the tree is not appropriate. An
2087example is the token-ring routing information field (RIF). The best way
2088to show the RIF in a GUI is by a sequence of ring and bridge numbers.
2089Rings are 3-digit hex numbers, and bridges are single hex digits:
2090
2091 RIF: 001-A-013-9-C0F-B-555
2092
2093In the case of RIF, the programmer should use a field with no value and
2094use proto_tree_add_none_format() to build the above representation. The
2095programmer can then add the ring and bridge values, one-by-one, with
2096proto_tree_add_item() and hide them with proto_item_set_hidden() so that the
2097user can then filter on or search for a particular ring or bridge. Here's a
2098skeleton of how the programmer might code this.
2099
2100 char *rif;
2101 rif = create_rif_string(...);
2102
2103 proto_tree_add_none_format(tree, hf_tr_rif_label, ..., "RIF: %s", rif);
2104
2105 for(i = 0; i < num_rings; i++) {
2106 proto_item *pi;
2107
2108 pi = proto_tree_add_item(tree, hf_tr_rif_ring, ...,
2109 ENC_BIG_ENDIAN);
2110 proto_item_set_hidden(pi);
2111 }
2112 for(i = 0; i < num_rings - 1; i++) {
2113 proto_item *pi;
2114
2115 pi = proto_tree_add_item(tree, hf_tr_rif_bridge, ...,
2116 ENC_BIG_ENDIAN);
2117 proto_item_set_hidden(pi);
2118 }
2119
2120The logical tree has these items:
2121
2122 hf_tr_rif_label, text="RIF: 001-A-013-9-C0F-B-555", value = NONE
2123 hf_tr_rif_ring, hidden, value=0x001
2124 hf_tr_rif_bridge, hidden, value=0xA
2125 hf_tr_rif_ring, hidden, value=0x013
2126 hf_tr_rif_bridge, hidden, value=0x9
2127 hf_tr_rif_ring, hidden, value=0xC0F
2128 hf_tr_rif_bridge, hidden, value=0xB
2129 hf_tr_rif_ring, hidden, value=0x555
2130
2131GUI or print code will not display the hidden fields, but a display
2132filter or "packet grep" routine will still see the values. The possible
2133filter is then possible:
2134
2135 tr.rif_ring eq 0x013
2136
2137proto_item_set_url
2138------------------
2139proto_item_set_url is used to mark fields as containing a URL. This can only
2140be done with fields of type FT_STRING(Z). If these fields are presented they
2141are underlined, as could be done in a browser. These fields are sensitive to
2142clicks as well, launching the configured browser with this URL as parameter.
2143
21441.6 Utility routines.
2145
21461.6.1 val_to_str, val_to_str_const, try_val_to_str and try_val_to_str_idx
2147
2148A dissector may need to convert a value to a string, using a
2149'value_string' structure, by hand, rather than by declaring a field with
2150an associated 'value_string' structure; this might be used, for example,
2151to generate a COL_INFO line for a frame.
2152
2153val_to_str() handles the most common case:
2154
2155 const gchar*
2156 val_to_str(guint32 val, const value_string *vs, const char *fmt)
2157
2158If the value 'val' is found in the 'value_string' table pointed to by
2159'vs', 'val_to_str' will return the corresponding string; otherwise, it
2160will use 'fmt' as an 'sprintf'-style format, with 'val' as an argument,
2161to generate a string, and will return a pointer to that string.
2162You can use it in a call to generate a COL_INFO line for a frame such as
2163
2164 col_add_fstr(COL_INFO, ", %s", val_to_str(val, table, "Unknown %d"));
2165
2166If you don't need to display 'val' in your fmt string, you can use
2167val_to_str_const() which just takes a string constant instead and returns it
2168unmodified when 'val' isn't found.
2169
2170If you need to handle the failure case in some custom way, try_val_to_str()
2171will return NULL if val isn't found:
2172
2173 const gchar*
2174 try_val_to_str(guint32 val, const value_string *vs)
2175
2176Note that, you must check whether 'try_val_to_str()' returns NULL, and arrange
2177that its return value not be dereferenced if it's NULL. 'try_val_to_str_idx()'
2178behaves similarly, except it also returns an index into the value_string array,
2179or -1 if 'val' was not found.
2180
2181The *_ext functions are "extended" versions of those already described. They
2182should be used for large value-string arrays which contain many entries. They
2183implement value to string conversions which will do either a direct access or
2184a binary search of the value string array if possible. See
2185"Extended Value Strings" under section 1.6 "Constructing the protocol tree" for
2186more information.
2187
2188See epan/value_string.h for detailed information on the various value_string
2189functions.
2190
2191To handle 64-bit values, there are an equivalent set of functions. These are:
2192
2193 const gchar *
2194 val64_to_str(const guint64 val, const val64_string *vs, const char *fmt)
2195
2196 const gchar *
2197 val64_to_str_const(const guint64 val, const val64_string *vs, const char *unknown_str);
2198
2199 const gchar *
2200 try_val64_to_str(const guint64 val, const val64_string *vs);
2201
2202 const gchar *
2203 try_val64_to_str_idx(const guint64 val, const val64_string *vs, gint *idx);
2204
2205
22061.6.2 rval_to_str, try_rval_to_str and try_rval_to_str_idx
2207
2208A dissector may need to convert a range of values to a string, using a
2209'range_string' structure.
2210
2211Most of the same functions exist as with regular value_strings (see section
22121.6.1) except with the names 'rval' instead of 'val'.
2213
2214
22151.7 Calling Other Dissectors.
2216
2217As each dissector completes its portion of the protocol analysis, it
2218is expected to create a new tvbuff of type TVBUFF_SUBSET which
2219contains the payload portion of the protocol (that is, the bytes
2220that are relevant to the next dissector).
2221
2222To create a new TVBUFF_SUBSET that begins at a specified offset in a
2223parent tvbuff, and runs to the end of the parent tvbuff, the routine
2224tvbuff_new_subset_remaining() is used:
2225
2226 next_tvb = tvb_new_subset_remaining(tvb, offset);
2227
2228Where:
2229 tvb is the tvbuff that the dissector has been working on. It
2230 can be a tvbuff of any type.
2231
2232 next_tvb is the new TVBUFF_SUBSET.
2233
2234 offset is the byte offset of 'tvb' at which the new tvbuff
2235 should start. The first byte is the byte at offset 0.
2236
2237To create a new TVBUFF_SUBSET that begins at a specified offset in a
2238parent tvbuff, with a specified number of bytes in the payload, the
2239routine tvbuff_new_subset_length() is used:
2240
2241 next_tvb = tvb_new_subset_length(tvb, offset, reported_length);
2242
2243Where:
2244 tvb is the tvbuff that the dissector has been working on. It
2245 can be a tvbuff of any type.
2246
2247 next_tvb is the new TVBUFF_SUBSET.
2248
2249 offset is the byte offset of 'tvb' at which the new tvbuff
2250 should start. The first byte is the byte at offset 0.
2251
2252 reported_length is the number of bytes that the current protocol
2253 says should be in the payload.
2254
2255In the few cases where the number of bytes available in the new subset
2256must be explicitly specified, rather than being calculated based on the
2257number of bytes in the payload, the routine tvb_new_subset_length_caplen()
2258is used:
2259
2260 next_tvb = tvb_new_subset_length_caplen(tvb, offset, length, reported_length);
2261
2262Where:
2263 tvb is the tvbuff that the dissector has been working on. It
2264 can be a tvbuff of any type.
2265
2266 next_tvb is the new TVBUFF_SUBSET.
2267
2268 offset is the byte offset of 'tvb' at which the new tvbuff
2269 should start. The first byte is the byte at offset 0.
2270
2271 length is the number of bytes in the new TVBUFF_SUBSET. A length
2272 argument of -1 says to use as many bytes as are available in
2273 'tvb'.
2274
2275 reported_length is the number of bytes that the current protocol
2276 says should be in the payload. A reported_length of -1 says that
2277 the protocol doesn't say anything about the size of its payload.
2278
2279To call a dissector you need to get the handle of the dissector using
2280find_dissector(), passing it the string name of the dissector. The setting
2281of the handle is usually done once at startup during the proto_reg_handoff
2282function within the calling dissector.
2283
22841.7.1 Dissector Tables
2285
2286Another way to call a subdissector is to setup a dissector table. A dissector
2287table is a list of subdissectors grouped by a common identifier (integer or
2288string) in a dissector. Subdissectors will register themselves with the dissector
2289table using their unique identifier using one of the following APIs:
2290
2291 void dissector_add_uint(const char *abbrev, const guint32 pattern,
2292 dissector_handle_t handle);
2293
2294 void dissector_add_uint_range(const char *abbrev, struct epan_range *range,
2295 dissector_handle_t handle);
2296
2297 void dissector_add_string(const char *name, const gchar *pattern,
2298 dissector_handle_t handle);
2299
2300 void dissector_add_for_decode_as(const char *name,
2301 dissector_handle_t handle);
2302
2303 dissector_add_for_decode_as doesn't add a unique identifier in the dissector
2304 table, but it lets the user add it from the command line or, in Wireshark,
2305 through the "Decode As" UI.
2306
2307Then when the dissector hits the common identifier field, it will use one of the
2308following APIs to invoke the subdissector:
2309
2310 int dissector_try_uint(dissector_table_t sub_dissectors,
2311 const guint32 uint_val, tvbuff_t *tvb, packet_info *pinfo,
2312 proto_tree *tree);
2313
2314 int dissector_try_uint_new(dissector_table_t sub_dissectors,
2315 const guint32 uint_val, tvbuff_t *tvb, packet_info *pinfo,
2316 proto_tree *tree, const gboolean add_proto_name, void *data);
2317
2318 int dissector_try_string(dissector_table_t sub_dissectors, const gchar *string,
2319 tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data);
2320
2321These pass a subset of the remaining packet (typically the rest of the
2322packet) for the dissector table to determine which subdissector is called.
2323This allows dissection of a packet to be expanded outside of dissector without
2324having to modify the dissector directly.
2325
2326
23271.8 Editing CMakeLists.txt to add your dissector.
2328
2329To arrange that your dissector will be built as part of Wireshark, you
2330must add the name of the source file for your dissector to the DISSECTOR_SRC
2331section of epan/dissectors/CMakeLists.txt
2332
2333
23341.9 Using the git source code tree.
2335
2336 See <https://www.wireshark.org/develop.html>
2337
2338
23391.10 Submitting code for your new dissector.
2340
2341 See <https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html>
2342 and <https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches>.
2343
2344 - VERIFY that your dissector code does not use prohibited or deprecated APIs
2345 as follows:
2346 perl <wireshark_root>/tools/checkAPIs.pl <source-filename(s)>
2347
2348 - VERIFY that your dissector code does not contain any header field related
2349 problems:
2350 perl <wireshark_root>/tools/checkhf.pl <source-filename(s)>
2351
2352 - VERIFY that your dissector code does not contain any display filter related
2353 problems:
2354 perl <wireshark_root>/tools/checkfiltername.pl <source-filename(s)>
2355
2356 - CHECK your dissector with CppCheck (http://cppcheck.sourceforge.net/) using
2357 Wireshark's customized configuration. This is particularly important on
2358 Windows, since Microsoft's compiler warnings are quite thin:
2359 ./tools/cppcheck/cppcheck.sh <source-filename(s)>
2360
2361 - TEST YOUR DISSECTOR BEFORE SUBMITTING IT.
2362 Use fuzz-test.sh and/or randpkt against your dissector. These are
2363 described at <https://gitlab.com/wireshark/wireshark/-/wikis/FuzzTesting>.
2364
2365 - Subscribe to <mailto:wireshark-dev[AT]wireshark.org> by sending an email to
2366 <mailto:wireshark-dev-request[AT]wireshark.org?body="help"> or visiting
2367 <https://www.wireshark.org/lists/>.
2368
2369 - 'git diff' to verify all your changes look good.
2370
2371 - 'git add' all the files you changed.
2372
2373 - 'git commit' to commit (locally) your changes. First line of commit message
2374 should be a summary of the changes followed by an empty line and a more
2375 verbose description.
2376
2377 - 'git push downstream HEAD' to push the changes to GitLab. (This assumes
2378 that you have a remote named "downstream" that points to a fork of
2379 https://gitlab.com/wireshark/wireshark.)
2380
2381 - Create a Wiki page on the protocol at <https://gitlab.com/wireshark/editor-wiki>.
2382 (You'll need to request access to https://gitlab.com/wireshark/wiki-editors.)
2383 A template is provided so it is easy to setup in a consistent style.
2384 See: <https://gitlab.com/wireshark/wireshark/-/wikis/HowToEdit>
2385 and <https://gitlab.com/wireshark/wireshark/-/wikis/ProtocolReference>
2386
2387 - If possible, add sample capture files to the sample captures page at
2388 <https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures>. These
2389 files are used by the automated build system for fuzz testing.
2390
2391 - If you don't think the wiki is the right place for your sample capture,
2392 submit a bug report to the Wireshark issue database, found at
2393 <https://gitlab.com/wireshark/wireshark/-/issues>, qualified as an
2394 enhancement and attach your sample capture there. Normally a new
2395 dissector won't be accepted without a sample capture! If you open a
2396 bug be sure to cross-link your GitLab merge request.
2397
23982. Advanced dissector topics.
2399
24002.1 Introduction.
2401
2402Some of the advanced features are being worked on constantly. When using them
2403it is wise to check the relevant header and source files for additional details.
2404
24052.2 Following "conversations".
2406
2407In Wireshark a conversation is defined as a series of data packets between two
2408address:port combinations. A conversation is not sensitive to the direction of
2409the packet. The same conversation will be returned for a packet bound from
2410ServerA:1000 to ClientA:2000 and the packet from ClientA:2000 to ServerA:1000.
2411
24122.2.1 Conversation Routines
2413
2414There are seven routines that you will use to work with a conversation:
2415conversation_new, find_conversation, find_or_create_conversation,
2416conversation_add_proto_data, conversation_get_proto_data,
2417conversation_delete_proto_data, and conversation_set_dissector.
2418
2419
24202.2.1.1 The conversation_init function.
2421
2422This is an internal routine for the conversation code. As such you
2423will not have to call this routine. Just be aware that this routine is
2424called at the start of each capture and before the packets are filtered
2425with a display filter. The routine will destroy all stored
2426conversations. This routine does NOT clean up any data pointers that are
2427passed in the conversation_add_proto_data 'data' variable. You are
2428responsible for this clean up if you pass a malloc'ed pointer
2429in this variable.
2430
2431See item 2.2.1.5 for more information about use of the 'data' pointer.
2432
2433
24342.2.1.2 The conversation_new function.
2435
2436This routine will create a new conversation based upon two address/port
2437pairs. If you want to associate with the conversation a pointer to a
2438private data structure you must use the conversation_add_proto_data
2439function. The ptype variable is used to differentiate between
2440conversations over different protocols, i.e. TCP and UDP. The options
2441variable is used to define a conversation that will accept any destination
2442address and/or port. Set options = 0 if the destination port and address
2443are known when conversation_new is called. See section 2.4 for more
2444information on usage of the options parameter.
2445
2446The conversation_new prototype:
2447 conversation_t *conversation_new(guint32 setup_frame, address *addr1,
2448 address *addr2, port_type ptype, guint32 port1, guint32 port2,
2449 guint options);
2450
2451Where:
2452 guint32 setup_frame = The lowest numbered frame for this conversation
2453 address* addr1 = first data packet address
2454 address* addr2 = second data packet address
2455 port_type ptype = port type, this is defined in packet.h
2456 guint32 port1 = first data packet port
2457 guint32 port2 = second data packet port
2458 guint options = conversation options, NO_ADDR2 and/or NO_PORT2
2459
2460setup_frame indicates the first frame for this conversation, and is used to
2461distinguish multiple conversations with the same addr1/port1 and addr2/port2
2462pair that occur within the same capture session.
2463
2464"addr1" and "port1" are the first address/port pair; "addr2" and "port2"
2465are the second address/port pair. A conversation doesn't have source
2466and destination address/port pairs - packets in a conversation go in
2467both directions - so "addr1"/"port1" may be the source or destination
2468address/port pair; "addr2"/"port2" would be the other pair.
2469
2470If NO_ADDR2 is specified, the conversation is set up so that a
2471conversation lookup will match only the "addr1" address; if NO_PORT2 is
2472specified, the conversation is set up so that a conversation lookup will
2473match only the "port1" port; if both are specified, i.e.
2474NO_ADDR2|NO_PORT2, the conversation is set up so that the lookup will
2475match only the "addr1"/"port1" address/port pair. This can be used if a
2476packet indicates that, later in the capture, a conversation will be
2477created using certain addresses and ports, in the case where the packet
2478doesn't specify the addresses and ports of both sides.
2479
24802.2.1.3 The find_conversation function.
2481
2482Call this routine to look up a conversation. If no conversation is found,
2483the routine will return a NULL value.
2484
2485The find_conversation prototype:
2486
2487 conversation_t *find_conversation(guint32 frame_num, address *addr_a,
2488 address *addr_b, port_type ptype, guint32 port_a, guint32 port_b,
2489 guint options);
2490
2491Where:
2492 guint32 frame_num = a frame number to match
2493 address* addr_a = first address
2494 address* addr_b = second address
2495 port_type ptype = port type
2496 guint32 port_a = first data packet port
2497 guint32 port_b = second data packet port
2498 guint options = conversation options, NO_ADDR_B and/or NO_PORT_B
2499
2500frame_num is a frame number to match. The conversation returned is where
2501 (frame_num >= conversation->setup_frame
2502 && frame_num < conversation->next->setup_frame)
2503Suppose there are a total of 3 conversations (A, B, and C) that match
2504addr_a/port_a and addr_b/port_b, where the setup_frame used in
2505conversation_new() for A, B and C are 10, 50, and 100 respectively. The
2506frame_num passed in find_conversation is compared to the setup_frame of each
2507conversation. So if (frame_num >= 10 && frame_num < 50), conversation A is
2508returned. If (frame_num >= 50 && frame_num < 100), conversation B is returned.
2509If (frame_num >= 100) conversation C is returned.
2510
2511"addr_a" and "port_a" are the first address/port pair; "addr_b" and
2512"port_b" are the second address/port pair. Again, as a conversation
2513doesn't have source and destination address/port pairs, so
2514"addr_a"/"port_a" may be the source or destination address/port pair;
2515"addr_b"/"port_b" would be the other pair. The search will match the
2516"a" address/port pair against both the "1" and "2" address/port pairs,
2517and match the "b" address/port pair against both the "2" and "1"
2518address/port pairs; you don't have to worry about which side the "a" or
2519"b" pairs correspond to.
2520
2521If the NO_ADDR_B flag was specified to "find_conversation()", the
2522"addr_b" address will be treated as matching any "wildcarded" address;
2523if the NO_PORT_B flag was specified, the "port_b" port will be treated
2524as matching any "wildcarded" port. If both flags are specified, i.e.
2525NO_ADDR_B|NO_PORT_B, the "addr_b" address will be treated as matching
2526any "wildcarded" address and the "port_b" port will be treated as
2527matching any "wildcarded" port.
2528
25292.2.1.4 The find_conversation_pinfo function.
2530
2531This convenience function will find an existing conversation (by calling
2532find_conversation())
2533
2534The find_conversation_pinfo prototype:
2535
2536 extern conversation_t *find_conversation_pinfo(packet_info *pinfo, const guint options);
2537
2538Where:
2539 packet_info *pinfo = the packet_info structure
2540 const guint options = conversation options, NO_ADDR_B and/or NO_PORT_B
2541
2542The frame number and the addresses necessary for find_conversation() are
2543taken from the pinfo structure (as is commonly done).
2544
25452.2.1.5 The find_or_create_conversation function.
2546
2547This convenience function will find an existing conversation (by calling
2548find_conversation()) and, if a conversation does not already exist, create a
2549new conversation by calling conversation_new().
2550
2551The find_or_create_conversation prototype:
2552
2553 extern conversation_t *find_or_create_conversation(packet_info *pinfo);
2554
2555Where:
2556 packet_info *pinfo = the packet_info structure
2557
2558The frame number and the addresses necessary for find_conversation() and
2559conversation_new() are taken from the pinfo structure (as is commonly done)
2560and no 'options' are used.
2561
2562
25632.2.1.6 The conversation_add_proto_data function.
2564
2565Once you have created a conversation with conversation_new, you can
2566associate data with it using this function.
2567
2568The conversation_add_proto_data prototype:
2569
2570 void conversation_add_proto_data(conversation_t *conv, int proto,
2571 void *proto_data);
2572
2573Where:
2574 conversation_t *conv = the conversation in question
2575 int proto = registered protocol number
2576 void *data = dissector data structure
2577
2578"conversation" is the value returned by conversation_new. "proto" is a
2579unique protocol number created with proto_register_protocol. Protocols
2580are typically registered in the proto_register_XXXX section of your
2581dissector. "data" is a pointer to the data you wish to associate with the
2582conversation. "data" usually points to "wmem_alloc'd" memory; the
2583memory will be automatically freed each time a new dissection begins
2584and thus need not be managed (freed) by the dissector.
2585Using the protocol number allows several dissectors to
2586associate data with a given conversation.
2587
2588
25892.2.1.7 The conversation_get_proto_data function.
2590
2591After you have located a conversation with find_conversation, you can use
2592this function to retrieve any data associated with it.
2593
2594The conversation_get_proto_data prototype:
2595
2596 void *conversation_get_proto_data(conversation_t *conv, int proto);
2597
2598Where:
2599 conversation_t *conv = the conversation in question
2600 int proto = registered protocol number
2601
2602"conversation" is the conversation created with conversation_new. "proto"
2603is a unique protocol number created with proto_register_protocol,
2604typically in the proto_register_XXXX portion of a dissector. The function
2605returns a pointer to the data requested, or NULL if no data was found.
2606
2607
26082.2.1.8 The conversation_delete_proto_data function.
2609
2610After you are finished with a conversation, you can remove your association
2611with this function. Please note that ONLY the conversation entry is
2612removed. If you have allocated any memory for your data (other than with wmem_alloc),
2613 you must free it as well.
2614
2615The conversation_delete_proto_data prototype:
2616
2617 void conversation_delete_proto_data(conversation_t *conv, int proto);
2618
2619Where:
2620 conversation_t *conv = the conversation in question
2621 int proto = registered protocol number
2622
2623"conversation" is the conversation created with conversation_new. "proto"
2624is a unique protocol number created with proto_register_protocol,
2625typically in the proto_register_XXXX portion of a dissector.
2626
26272.2.1.9 The conversation_set_dissector function
2628
2629This function sets the protocol dissector to be invoked whenever
2630conversation parameters (addresses, port_types, ports, etc) are matched
2631during the dissection of a packet.
2632
2633The conversation_set_dissector prototype:
2634
2635 void conversation_set_dissector(conversation_t *conversation, const dissector_handle_t handle);
2636
2637Where:
2638 conversation_t *conv = the conversation in question
2639 const dissector_handle_t handle = the dissector handle.
2640
2641
26422.2.2 Using timestamps relative to the conversation
2643
2644There is a framework to calculate timestamps relative to the start of the
2645conversation. First of all the timestamp of the first packet that has been
2646seen in the conversation must be kept in the protocol data to be able
2647to calculate the timestamp of the current packet relative to the start
2648of the conversation. The timestamp of the last packet that was seen in the
2649conversation should also be kept in the protocol data. This way the
2650delta time between the current packet and the previous packet in the
2651conversation can be calculated.
2652
2653So add the following items to the struct that is used for the protocol data:
2654
2655 nstime_t ts_first;
2656 nstime_t ts_prev;
2657
2658The ts_prev value should only be set during the first run through the
2659packets (ie PINFO_FD_VISITED(pinfo) is false).
2660
2661Next step is to use the per-packet information (described in section 2.5)
2662to keep the calculated delta timestamp, as it can only be calculated
2663on the first run through the packets. This is because a packet can be
2664selected in random order once the whole file has been read.
2665
2666After calculating the conversation timestamps, it is time to put them in
2667the appropriate columns with the function 'col_set_time' (described in
2668section 1.5.9). The column used for relative timestamps is:
2669
2670COL_REL_TIME, /* Delta time to last frame in conversation */
2671
2672Last but not least, there MUST be a preference in each dissector that
2673uses conversation timestamps that makes it possible to enable and
2674disable the calculation of conversation timestamps. The main argument
2675for this is that a higher level conversation is able to overwrite
2676the values of lower level conversations in these two columns. Being
2677able to actively select which protocols may overwrite the conversation
2678timestamp columns gives the user the power to control these columns.
2679(A second reason is that conversation timestamps use the per-packet
2680data structure which uses additional memory, which should be avoided
2681if these timestamps are not needed)
2682
2683Have a look at the differences to packet-tcp.[ch] in SVN 22966 and
2684SVN 23058 to see the implementation of conversation timestamps for
2685the tcp-dissector.
2686
2687
26882.2.3 The example conversation code using wmem_file_scope memory.
2689
2690For a conversation between two IP addresses and ports you can use this as an
2691example. This example uses wmem_alloc() with wmem_file_scope() to allocate
2692memory and stores the data pointer in the conversation 'data' variable.
2693
2694/************************ Global values ************************/
2695
2696/* define your structure here */
2697typedef struct {
2698
2699} my_entry_t;
2700
2701/* Registered protocol number */
2702static int my_proto = -1;
2703
2704/********************* in the dissector routine *********************/
2705
2706/* the local variables in the dissector */
2707
2708conversation_t *conversation;
2709my_entry_t *data_ptr;
2710
2711
2712/* look up the conversation */
2713
2714conversation = find_conversation(pinfo->num, &pinfo->src, &pinfo->dst,
2715 pinfo->ptype, pinfo->srcport, pinfo->destport, 0);
2716
2717/* if conversation found get the data pointer that you stored */
2718if (conversation)
2719 data_ptr = (my_entry_t*)conversation_get_proto_data(conversation, my_proto);
2720else {
2721
2722 /* new conversation create local data structure */
2723
2724 data_ptr = wmem_alloc(wmem_file_scope(), sizeof(my_entry_t));
2725
2726 /*** add your code here to setup the new data structure ***/
2727
2728 /* create the conversation with your data pointer */
2729
2730 conversation = conversation_new(pinfo->num, &pinfo->src, &pinfo->dst, pinfo->ptype,
2731 pinfo->srcport, pinfo->destport, 0);
2732 conversation_add_proto_data(conversation, my_proto, (void *)data_ptr);
2733}
2734
2735/* at this point the conversation data is ready */
2736
2737/***************** in the protocol register routine *****************/
2738
2739my_proto = proto_register_protocol("My Protocol", "My Protocol", "my_proto");
2740
2741
27422.2.4 An example conversation code that starts at a specific frame number.
2743
2744Sometimes a dissector has determined that a new conversation is needed that
2745starts at a specific frame number, when a capture session encompasses multiple
2746conversation that reuse the same src/dest ip/port pairs. You can use the
2747conversation->setup_frame returned by find_conversation with
2748pinfo->num to determine whether or not there already exists a conversation
2749that starts at the specific frame number.
2750
2751/* in the dissector routine */
2752
2753 conversation = find_conversation(pinfo->num, &pinfo->src, &pinfo->dst,
2754 pinfo->ptype, pinfo->srcport, pinfo->destport, 0);
2755 if (conversation == NULL || (conversation->setup_frame != pinfo->num)) {
2756 /* It's not part of any conversation or the returned
2757 * conversation->setup_frame doesn't match the current frame
2758 * create a new one.
2759 */
2760 conversation = conversation_new(pinfo->num, &pinfo->src,
2761 &pinfo->dst, pinfo->ptype, pinfo->srcport, pinfo->destport,
2762 NULL, 0);
2763 }
2764
2765
27662.2.5 The example conversation code using conversation index field.
2767
2768Sometimes the conversation isn't enough to define a unique data storage
2769value for the network traffic. For example if you are storing information
2770about requests carried in a conversation, the request may have an
2771identifier that is used to define the request. In this case the
2772conversation and the identifier are required to find the data storage
2773pointer. You can use the conversation data structure index value to
2774uniquely define the conversation.
2775
2776See packet-afs.c for an example of how to use the conversation index. In
2777this dissector multiple requests are sent in the same conversation. To store
2778information for each request the dissector has an internal hash table based
2779upon the conversation index and values inside the request packets.
2780
2781
2782 /* in the dissector routine */
2783
2784 /* to find a request value, first lookup conversation to get index */
2785 /* then used the conversation index, and request data to find data */
2786 /* in the local hash table */
2787
2788 conversation = find_or_create_conversation(pinfo);
2789
2790 request_key.conversation = conversation->index;
2791 request_key.service = pntoh16(&rxh->serviceId);
2792 request_key.callnumber = pntoh32(&rxh->callNumber);
2793
2794 request_val = (struct afs_request_val *)g_hash_table_lookup(
2795 afs_request_hash, &request_key);
2796
2797 /* only allocate a new hash element when it's a request */
2798 opcode = 0;
2799 if (!request_val && !reply)
2800 {
2801 new_request_key = wmem_alloc(wmem_file_scope(), sizeof(struct afs_request_key));
2802 *new_request_key = request_key;
2803
2804 request_val = wmem_alloc(wmem_file_scope(), sizeof(struct afs_request_val));
2805 request_val -> opcode = pntoh32(&afsh->opcode);
2806 opcode = request_val->opcode;
2807
2808 g_hash_table_insert(afs_request_hash, new_request_key,
2809 request_val);
2810 }
2811
2812
2813
28142.3 Dynamic conversation dissector registration.
2815
2816
2817NOTE: This sections assumes that all information is available to
2818 create a complete conversation, source port/address and
2819 destination port/address. If either the destination port or
2820 address is known, see section 2.4 Dynamic server port dissector
2821 registration.
2822
2823For protocols that negotiate a secondary port connection, for example
2824packet-msproxy.c, a conversation can install a dissector to handle
2825the secondary protocol dissection. After the conversation is created
2826for the negotiated ports use the conversation_set_dissector to define
2827the dissection routine.
2828Before we create these conversations or assign a dissector to them we should
2829first check that the conversation does not already exist and if it exists
2830whether it is registered to our protocol or not.
2831We should do this because it is uncommon but it does happen that multiple
2832different protocols can use the same socketpair during different stages of
2833an application cycle. By keeping track of the frame number a conversation
2834was started in Wireshark can still tell these different protocols apart.
2835
2836The second argument to conversation_set_dissector is a dissector handle,
2837which is created with a call to create_dissector_handle or
2838register_dissector.
2839
2840create_dissector_handle takes as arguments a pointer to the dissector
2841function and a protocol ID as returned by proto_register_protocol;
2842register_dissector takes as arguments a string giving a name for the
2843dissector, a pointer to the dissector function, and a protocol ID.
2844
2845The protocol ID is the ID for the protocol dissected by the function.
2846The function will not be called if the protocol has been disabled by the
2847user; instead, the data for the protocol will be dissected as raw data.
2848
2849An example -
2850
2851/* the handle for the dynamic dissector *
2852static dissector_handle_t sub_dissector_handle;
2853
2854/* prototype for the dynamic dissector */
2855static void sub_dissector(tvbuff_t *tvb, packet_info *pinfo,
2856 proto_tree *tree);
2857
2858/* in the main protocol dissector, where the next dissector is setup */
2859
2860/* if conversation has a data field, create it and load structure */
2861
2862/* First check if a conversation already exists for this
2863 socketpair
2864*/
2865 conversation = find_conversation(pinfo->num,
2866 &pinfo->src, &pinfo->dst, protocol,
2867 src_port, dst_port, 0);
2868
2869/* If there is no such conversation, or if there is one but for
2870 someone else's protocol then we just create a new conversation
2871 and assign our protocol to it.
2872*/
2873 if ( (conversation == NULL) ||
2874 (conversation->dissector_handle != sub_dissector_handle) ) {
2875 new_conv_info = wmem_alloc(wmem_file_scope(), sizeof(struct _new_conv_info));
2876 new_conv_info->data1 = value1;
2877
2878/* create the conversation for the dynamic port */
2879 conversation = conversation_new(pinfo->num,
2880 &pinfo->src, &pinfo->dst, protocol,
2881 src_port, dst_port, new_conv_info, 0);
2882
2883/* set the dissector for the new conversation */
2884 conversation_set_dissector(conversation, sub_dissector_handle);
2885 }
2886 ...
2887
2888void
2889proto_register_PROTOABBREV(void)
2890{
2891 ...
2892
2893 sub_dissector_handle = create_dissector_handle(sub_dissector,
2894 proto);
2895
2896 ...
2897}
2898
28992.4 Dynamic server port dissector registration.
2900
2901NOTE: While this example used both NO_ADDR2 and NO_PORT2 to create a
2902conversation with only one port and address set, this isn't a
2903requirement. Either the second port or the second address can be set
2904when the conversation is created.
2905
2906For protocols that define a server address and port for a secondary
2907protocol, a conversation can be used to link a protocol dissector to
2908the server port and address. The key is to create the new
2909conversation with the second address and port set to the "accept
2910any" values.
2911
2912Some server applications can use the same port for different protocols during
2913different stages of a transaction. For example it might initially use SNMP
2914to perform some discovery and later switch to use TFTP using the same port.
2915In order to handle this properly we must first check whether such a
2916conversation already exists or not and if it exists we also check whether the
2917registered dissector_handle for that conversation is "our" dissector or not.
2918If not we create a new conversation on top of the previous one and set this new
2919conversation to use our protocol.
2920Since Wireshark keeps track of the frame number where a conversation started
2921wireshark will still be able to keep the packets apart even though they do use
2922the same socketpair.
2923 (See packet-tftp.c and packet-snmp.c for examples of this)
2924
2925There are two support routines that will allow the second port and/or
2926address to be set later.
2927
2928conversation_set_port2( conversation_t *conv, guint32 port);
2929conversation_set_addr2( conversation_t *conv, address addr);
2930
2931These routines will change the second address or port for the
2932conversation. So, the server port conversation will be converted into a
2933more complete conversation definition. Don't use these routines if you
2934want to create a conversation between the server and client and retain the
2935server port definition, you must create a new conversation.
2936
2937
2938An example -
2939
2940/* the handle for the dynamic dissector *
2941static dissector_handle_t sub_dissector_handle;
2942
2943 ...
2944
2945/* in the main protocol dissector, where the next dissector is setup */
2946
2947/* if conversation has a data field, create it and load structure */
2948
2949 new_conv_info = wmem_alloc(wmem_file_scope(), sizeof(struct _new_conv_info));
2950 new_conv_info->data1 = value1;
2951
2952/* create the conversation for the dynamic server address and port */
2953/* NOTE: The second address and port values don't matter because the */
2954/* NO_ADDR2 and NO_PORT2 options are set. */
2955
2956/* First check if a conversation already exists for this
2957 IP/protocol/port
2958*/
2959 conversation = find_conversation(pinfo->num,
2960 &server_src_addr, 0, protocol,
2961 server_src_port, 0, NO_ADDR2 | NO_PORT_B);
2962/* If there is no such conversation, or if there is one but for
2963 someone else's protocol then we just create a new conversation
2964 and assign our protocol to it.
2965*/
2966 if ( (conversation == NULL) ||
2967 (conversation->dissector_handle != sub_dissector_handle) ) {
2968 conversation = conversation_new(pinfo->num,
2969 &server_src_addr, 0, protocol,
2970 server_src_port, 0, new_conv_info, NO_ADDR2 | NO_PORT2);
2971
2972/* set the dissector for the new conversation */
2973 conversation_set_dissector(conversation, sub_dissector_handle);
2974 }
2975
29762.5 Per-packet information.
2977
2978Information can be stored for each data packet that is processed by the
2979dissector. The information is added with the p_add_proto_data function and
2980retrieved with the p_get_proto_data function. The data pointers passed into
2981the p_add_proto_data are not managed by the proto_data routines, however the
2982data pointer memory scope must match that of the scope parameter.
2983The two most common use cases for p_add_proto_data/p_get_proto_data are for
2984persistent data about the packet for the lifetime of the capture (file scope)
2985and to exchange data between dissectors across a single packet (packet scope).
2986It is also used to provide packet data for Decode As dialog (packet scope).
2987
2988These functions are declared in <epan/proto_data.h>.
2989
2990void
2991p_add_proto_data(wmem_allocator_t *scope, packet_info *pinfo, int proto, guint32 key, void *proto_data)
2992void *
2993p_get_proto_data(wmem_allocator_t *scope, packet_info *pinfo, int proto, guint32 key)
2994
2995Where:
2996 scope - Lifetime of the data to be stored, typically wmem_file_scope()
2997 or pinfo->pool (packet scope). Must match scope of data
2998 allocated.
2999 pinfo - The packet info pointer.
3000 proto - Protocol id returned by the proto_register_protocol call
3001 during initialization
3002 key - key associated with 'proto_data'
3003 proto_data - pointer to the dissector data.
3004
3005
30062.6 User Preferences.
3007
3008If the dissector has user options, there is support for adding these preferences
3009to a configuration dialog.
3010
3011You must register the module with the preferences routine with -
3012
3013 module_t *prefs_register_protocol(proto_id, void (*apply_cb)(void))
3014 or
3015 module_t *prefs_register_protocol_subtree(const char *subtree, int id,
3016 void (*apply_cb)(void));
3017
3018
3019Where: proto_id - the value returned by "proto_register_protocol()" when
3020 the protocol was registered.
3021 apply_cb - Callback routine that is called when preferences are
3022 applied. It may be NULL, which inhibits the callback.
3023 subtree - grouping preferences tree node name (several protocols can
3024 be grouped under one preferences subtree)
3025
3026Then you can register the fields that can be configured by the user with these
3027routines -
3028
3029 /* Register a preference with an unsigned integral value. */
3030 void prefs_register_uint_preference(module_t *module, const char *name,
3031 const char *title, const char *description, guint base, guint *var);
3032
3033 /* Register a preference with an Boolean value. */
3034 void prefs_register_bool_preference(module_t *module, const char *name,
3035 const char *title, const char *description, gboolean *var);
3036
3037 /* Register a preference with an enumerated value. */
3038 void prefs_register_enum_preference(module_t *module, const char *name,
3039 const char *title, const char *description, gint *var,
3040 const enum_val_t *enumvals, gboolean radio_buttons)
3041
3042 /* Register a preference with a character-string value. */
3043 void prefs_register_string_preference(module_t *module, const char *name,
3044 const char *title, const char *description, char **var)
3045
3046 /* Register a preference with a file name (string) value.
3047 * File name preferences are basically like string preferences
3048 * except that the GUI gives the user the ability to browse for the
3049 * file. Set for_writing TRUE to show a Save dialog instead of normal Open.
3050 */
3051 void prefs_register_filename_preference(module_t *module, const char *name,
3052 const char *title, const char *description, char **var,
3053 gboolean for_writing)
3054
3055 /* Register a preference with a range of unsigned integers (e.g.,
3056 * "1-20,30-40").
3057 */
3058 void prefs_register_range_preference(module_t *module, const char *name,
3059 const char *title, const char *description, range_t *var,
3060 guint32 max_value)
3061
3062Where: module - Returned by the prefs_register_protocol routine
3063 name - This is appended to the name of the protocol, with a
3064 "." between them, to construct a name that identifies
3065 the field in the preference file; the name itself
3066 should not include the protocol name, as the name in
3067 the preference file will already have it. Make sure that
3068 only lower-case ASCII letters, numbers, underscores and
3069 dots appear in the preference name.
3070 title - Field title in the preferences dialog
3071 description - Comments added to the preference file above the
3072 preference value and shown as tooltip in the GUI, or NULL
3073 var - pointer to the storage location that is updated when the
3074 field is changed in the preference dialog box. Note that
3075 with string preferences the given pointer is overwritten
3076 with a pointer to a new copy of the string during the
3077 preference registration. The passed-in string may be
3078 freed, but you must keep another pointer to the string
3079 in order to free it.
3080 base - Base that the unsigned integer is expected to be in,
3081 see strtoul(3).
3082 enumvals - an array of enum_val_t structures. This must be
3083 NULL-terminated; the members of that structure are:
3084
3085 a short name, to be used with the "-o" flag - it
3086 should not contain spaces or upper-case letters,
3087 so that it's easier to put in a command line;
3088
3089 a description, which is used in the GUI (and
3090 which, for compatibility reasons, is currently
3091 what's written to the preferences file) - it can
3092 contain spaces, capital letters, punctuation,
3093 etc.;
3094
3095 the numerical value corresponding to that name
3096 and description
3097 radio_buttons - TRUE if the field is to be displayed in the
3098 preferences dialog as a set of radio buttons,
3099 FALSE if it is to be displayed as an option
3100 menu
3101 max_value - The maximum allowed value for a range (0 is the minimum).
3102
3103These functions are declared in <epan/prefs.h>.
3104
3105An example from packet-rtpproxy.c -
3106
3107 proto_rtpproxy = proto_register_protocol ( "Sippy RTPproxy Protocol", "RTPproxy", "rtpproxy");
3108
3109 ...
3110
3111 rtpproxy_module = prefs_register_protocol(proto_rtpproxy, proto_reg_handoff_rtpproxy);
3112
3113 prefs_register_bool_preference(rtpproxy_module, "establish_conversation",
3114 "Establish Media Conversation",
3115 "Specifies that RTP/RTCP/T.38/MSRP/etc streams are decoded based "
3116 "upon port numbers found in RTPproxy answers",
3117 &rtpproxy_establish_conversation);
3118
3119 prefs_register_uint_preference(rtpproxy_module, "reply.timeout",
3120 "RTPproxy reply timeout", /* Title */
3121 "Maximum timeout value in waiting for reply from RTPProxy (in milliseconds).", /* Descr */
3122 10,
3123 &rtpproxy_timeout);
3124
3125This will create preferences "rtpproxy.establish_conversation" and
3126"rtpproxy.reply.timeout", the first of which is an Boolean and the
3127second of which is a unsigned integer.
3128
3129Note that a warning will pop up if you've saved such preference to the
3130preference file and you subsequently take the code out. The way to make
3131a preference obsolete is to register it as such:
3132
3133/* Register a preference that used to be supported but no longer is. */
3134 void prefs_register_obsolete_preference(module_t *module,
3135 const char *name);
3136
31372.7 Reassembly/desegmentation for protocols running atop TCP.
3138
3139There are two main ways of reassembling a Protocol Data Unit (PDU) which
3140spans across multiple TCP segments. The first approach is simpler, but
3141assumes you are running atop of TCP when this occurs (but your dissector
3142might run atop of UDP, too, for example), and that your PDUs consist of a
3143fixed amount of data that includes enough information to determine the PDU
3144length, possibly followed by additional data. The second method is more
3145generic but requires more code and is less efficient.
3146
31472.7.1 Using tcp_dissect_pdus().
3148
3149For the first method, you register two different dissection methods, one
3150for the TCP case, and one for the other cases. It is a good idea to
3151also have a dissect_PROTO_common function which will parse the generic
3152content that you can find in all PDUs which is called from
3153dissect_PROTO_tcp when the reassembly is complete and from
3154dissect_PROTO_udp (or dissect_PROTO_other).
3155
3156To register the distinct dissector functions, consider the following
3157example, stolen from packet-hartip.c:
3158
3159 #include "packet-tcp.h"
3160
3161 dissector_handle_t hartip_tcp_handle;
3162 dissector_handle_t hartip_udp_handle;
3163
3164 hartip_tcp_handle = create_dissector_handle(dissect_hartip_tcp, proto_hartip);
3165 hartip_udp_handle = create_dissector_handle(dissect_hartip_udp, proto_hartip);
3166
3167 dissector_add_uint("udp.port", HARTIP_PORT, hartip_udp_handle);
3168 dissector_add_uint_with_preference("tcp.port", HARTIP_PORT, hartip_tcp_handle);
3169
3170The dissect_hartip_udp function does very little work and calls
3171dissect_hartip_common, while dissect_hartip_tcp calls tcp_dissect_pdus with a
3172reference to a callback which will be called with reassembled data:
3173
3174 static int
3175 dissect_hartip_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,
3176 void *data)
3177 {
3178 if (!tvb_bytes_exist(tvb, 0, HARTIP_HEADER_LENGTH))
3179 return 0;
3180
3181 tcp_dissect_pdus(tvb, pinfo, tree, hartip_desegment, HARTIP_HEADER_LENGTH,
3182 get_dissect_hartip_len, dissect_hartip_pdu, data);
3183 return tvb_reported_length(tvb);
3184 }
3185
3186(The dissect_hartip_pdu function acts similarly to dissect_hartip_udp.)
3187The arguments to tcp_dissect_pdus are:
3188
3189 the tvbuff pointer, packet_info pointer, and proto_tree pointer
3190 passed to the dissector;
3191
3192 a gboolean flag indicating whether desegmentation is enabled for
3193 your protocol;
3194
3195 the number of bytes of PDU data required to determine the length
3196 of the PDU;
3197
3198 a routine that takes as arguments a packet_info pointer, a tvbuff
3199 pointer and an offset value representing the offset into the tvbuff
3200 at which a PDU begins, and a void pointer for user data, and should
3201 return the total length of the PDU in bytes (or 0 if more bytes are
3202 needed to determine the message length).
3203 The routine must not throw exceptions (it is guaranteed that the
3204 number of bytes specified by the previous argument to
3205 tcp_dissect_pdus is available, but more data might not be available,
3206 so don't refer to any data past that);
3207
3208 a new_dissector_t routine to dissect the pdu that's passed a tvbuff
3209 pointer, packet_info pointer, proto_tree pointer and a void pointer for
3210 user data, with the tvbuff containing a possibly-reassembled PDU. (The
3211 "reported_length" of the tvbuff will be the length of the PDU);
3212
3213 a void pointer to user data that is passed to the length-determining
3214 routine, and the dissector routine referenced in the previous parameter.
3215
32162.7.2 Modifying the pinfo struct.
3217
3218The second reassembly mode is preferred when the dissector cannot determine
3219how many bytes it will need to read in order to determine the size of a PDU.
3220It may also be useful if your dissector needs to support reassembly from
3221protocols other than TCP.
3222
3223Your dissect_PROTO will initially be passed a tvbuff containing the payload of
3224the first packet. It should dissect as much data as it can, noting that it may
3225contain more than one complete PDU. If the end of the provided tvbuff coincides
3226with the end of a PDU then all is well and your dissector can just return as
3227normal. (If it is a new-style dissector, it should return the number of bytes
3228successfully processed.)
3229
3230If the dissector discovers that the end of the tvbuff does /not/ coincide with
3231the end of a PDU, (ie, there is half of a PDU at the end of the tvbuff), it can
3232indicate this to the parent dissector, by updating the pinfo struct. The
3233desegment_offset field is the offset in the tvbuff at which the dissector will
3234continue processing when next called. The desegment_len field should contain
3235the estimated number of additional bytes required for completing the PDU. Next
3236time your dissect_PROTO is called, it will be passed a tvbuff composed of the
3237end of the data from the previous tvbuff together with desegment_len more bytes.
3238
3239If the dissector cannot tell how many more bytes it will need, it should set
3240desegment_len=DESEGMENT_ONE_MORE_SEGMENT; it will then be called again as soon
3241as any more data becomes available. Dissectors should set the desegment_len to a
3242reasonable value when possible rather than always setting
3243DESEGMENT_ONE_MORE_SEGMENT as it will generally be more efficient. Also, you
3244*must not* set desegment_len=1 in this case, in the hope that you can change
3245your mind later: once you return a positive value from desegment_len, your PDU
3246boundary is set in stone.
3247
3248static hf_register_info hf[] = {
3249 {&hf_cstring,
3250 {"C String", "c.string", FT_STRING, BASE_NONE, NULL, 0x0,
3251 NULL, HFILL}
3252 }
3253 };
3254
3255/**
3256* Dissect a buffer containing ASCII C strings.
3257*
3258* @param tvb The buffer to dissect.
3259* @param pinfo Packet Info.
3260* @param tree The protocol tree.
3261* @param data Optional data parameter given by parent dissector.
3262**/
3263static int dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree, void *data _U_)
3264{
3265 guint offset = 0;
3266 while(offset < tvb_reported_length(tvb)) {
3267 gint available = tvb_reported_length_remaining(tvb, offset);
3268 gint len = tvb_strnlen(tvb, offset, available);
3269
3270 if( -1 == len ) {
3271 /* we ran out of data: ask for more */
3272 pinfo->desegment_offset = offset;
3273 pinfo->desegment_len = DESEGMENT_ONE_MORE_SEGMENT;
3274 return (offset + available);
3275 }
3276
3277 col_set_str(pinfo->cinfo, COL_INFO, "C String");
3278
3279 len += 1; /* Add one for the '\0' */
3280
3281 if (tree) {
3282 proto_tree_add_item(tree, hf_cstring, tvb, offset, len,
3283 ENC_ASCII|ENC_NA);
3284 }
3285 offset += (guint)len;
3286 }
3287
3288 /* if we get here, then the end of the tvb coincided with the end of a
3289 string. Happy days. */
3290 return tvb_captured_length(tvb);
3291}
3292
3293This simple dissector will repeatedly return DESEGMENT_ONE_MORE_SEGMENT
3294requesting more data until the tvbuff contains a complete C string. The C string
3295will then be added to the protocol tree. Note that there may be more
3296than one complete C string in the tvbuff, so the dissection is done in a
3297loop.
3298
32992.8 Using udp_dissect_pdus().
3300
3301As noted in section 2.7.1, TCP has an API to dissect its PDU that can handle
3302a PDU spread across multiple packets or multiple PDUs spread across a single
3303packet. This section describes a similar mechanism for UDP, but is only
3304applicable for one or more PDUs in a single packet. If a protocol runs on top
3305of TCP as well as UDP, a common PDU dissection function can be created for both.
3306
3307To register the distinct dissector functions, consider the following
3308example using UDP and TCP dissection, stolen from packet-dnp.c:
3309
3310 #include "packet-tcp.h"
3311 #include "packet-udp.h"
3312
3313 dissector_handle_t dnp3_tcp_handle;
3314 dissector_handle_t dnp3_udp_handle;
3315
3316 dnp3_tcp_handle = create_dissector_handle(dissect_dnp3_tcp, proto_dnp3);
3317 dnp3_udp_handle = create_dissector_handle(dissect_dnp3_udp, proto_dnp3);
3318
3319 dissector_add_uint("tcp.port", TCP_PORT_DNP, dnp3_tcp_handle);
3320 dissector_add_uint("udp.port", UDP_PORT_DNP, dnp3_udp_handle);
3321
3322Both dissect_dnp3_tcp and dissect_dnp3_udp call tcp_dissect_pdus and
3323udp_dissect_pdus respectively, with a reference to the same callbacks which
3324are called to handle PDU data.
3325
3326 static int
3327 dissect_dnp3_udp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
3328 {
3329 return udp_dissect_pdus(tvb, pinfo, tree, DNP_HDR_LEN, dnp3_udp_check_header,
3330 get_dnp3_message_len, dissect_dnp3_message, data);
3331 }
3332
3333 static int
3334 dissect_dnp3_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
3335 {
3336 if (!check_dnp3_header(tvb, FALSE)) {
3337 return 0;
3338 }
3339
3340 tcp_dissect_pdus(tvb, pinfo, tree, TRUE, DNP_HDR_LEN,
3341 get_dnp3_message_len, dissect_dnp3_message, data);
3342
3343 return tvb_captured_length(tvb);
3344 }
3345
3346(udp_dissect_pdus has an option of a heuristic check function within it while
3347tcp_dissect_pdus does not, so it's done outside)
3348
3349The arguments to udp_dissect_pdus are:
3350
3351 the tvbuff pointer, packet_info pointer, and proto_tree pointer
3352 passed to the dissector;
3353
3354 the number of bytes of PDU data required to determine the length
3355 of the PDU;
3356
3357 an optional routine (passing NULL is okay) that takes as arguments a
3358 packet_info pointer, a tvbuff pointer and an offset value representing the
3359 offset into the tvbuff at which a PDU begins, and a void pointer for user
3360 data, and should return TRUE if the packet belongs to the dissector.
3361 The routine must not throw exceptions (it is guaranteed that the
3362 number of bytes specified by the previous argument to
3363 udp_dissect_pdus is available, but more data might not be available,
3364 so don't refer to any data past that);
3365
3366 a routine that takes as arguments a packet_info pointer, a tvbuff
3367 pointer and an offset value representing the offset into the tvbuff
3368 at which a PDU begins, and a void pointer for user data, and should
3369 return the total length of the PDU in bytes. If return value is 0,
3370 it's treated the same as a failed heuristic.
3371 The routine must not throw exceptions (it is guaranteed that the
3372 number of bytes specified by the previous argument to
3373 tcp_dissect_pdus is available, but more data might not be available,
3374 so don't refer to any data past that);
3375
3376 a new_dissector_t routine to dissect the pdu that's passed a tvbuff
3377 pointer, packet_info pointer, proto_tree pointer and a void pointer for
3378 user data, with the tvbuff containing a possibly-reassembled PDU. (The
3379 "reported_length" of the tvbuff will be the length of the PDU);
3380
3381 a void pointer to user data that is passed to the length-determining
3382 routine, and the dissector routine referenced in the previous parameter.
3383
33842.9 PINOs (Protocols in name only)
3385
3386For the typical dissector there is a 1-1 relationship between it and it's
3387protocol. However, there are times when a protocol needs multiple "names"
3388because it has multiple dissection functions going into the same dissector
3389table. The multiple names removes confusion when picking dissection through
3390Decode As functionality.
3391
3392Once the "main" protocol name has been created through proto_register_protocol,
3393additional "pinos" can be created with proto_register_protocol_in_name_only.
3394These pinos have all of the naming conventions of a protocol, but are stored
3395separately as to remove confusion from real protocols. "pinos" the main
3396protocol's properties for things like enable/disable. i.e. If the "main"
3397protocol has been disabled, all of its pinos will be disabled as well.
3398Pinos should not have any fields registered with them or heuristic tables
3399associated with them.
3400
3401Another use case for pinos is when a protocol contains a TLV design and it
3402wants to create a dissector table to handle dissection of the "V". Dissector
3403tables require a "protocol", but the dissection functions for that table
3404typically aren't a protocol. In this case proto_register_protocol_in_name_only
3405creates the necessary placeholder for the dissector table. In addition, because
3406a dissector table exists, "V"s of the TLVs can be dissected outside of the
3407original dissector file.
3408
34092.10 Creating Decode As functionality.
3410
3411While the Decode As functionality is available through the GUI, the underlying
3412functionality is controlled by dissectors themselves. To create Decode As
3413functionality for a dissector, two things are required:
3414 1. A dissector table
3415 2. A series of structures to assist the GUI in how to present the dissector
3416 table data.
3417
3418Consider the following example using IP dissection, stolen from packet-ip.c:
3419
3420 static build_valid_func ip_da_build_value[1] = {ip_value};
3421 static decode_as_value_t ip_da_values = {ip_prompt, 1, ip_da_build_value};
3422 static decode_as_t ip_da = {"ip", "ip.proto", 1, 0, &ip_da_values, NULL, NULL,
3423 decode_as_default_populate_list, decode_as_default_reset, decode_as_default_change, NULL};
3424 ...
3425 ip_dissector_table = register_dissector_table("ip.proto", "IP protocol", ip_proto, FT_UINT8, BASE_DEC);
3426 ...
3427 register_decode_as(&ip_da);
3428
3429ip_da_build_value contains all of the function pointers (typically just 1) that
3430can be used to retrieve the value(s) that go into the dissector table. This is
3431usually data saved by the dissector during packet dissector with an API like
3432p_add_proto_data and retrieved in the "value" function with p_get_proto_data.
3433
3434ip_da_values contains all of the function pointers (typically just 1) that
3435provide the text explaining the name and use of the value field that will
3436be passed to the dissector table to change the dissection output.
3437
3438ip_da pulls everything together including the dissector (protocol) name, the
3439"layer type" of the dissector, the dissector table name, the function pointer
3440values as well as handlers for populating, applying and resetting the changes
3441to the dissector table through Decode As GUI functionality. For dissector
3442tables that are an integer or string type, the provided "default" handling
3443functions shown in the example should suffice.
3444
3445All entries into a dissector table that use Decode As must have a unique
3446protocol ID. If a protocol wants multiple entries into a dissector table,
3447a pino should be used (see section 2.9)
3448
34492.11 ptvcursors.
3450
3451The ptvcursor API allows a simpler approach to writing dissectors for
3452simple protocols. The ptvcursor API works best for protocols whose fields
3453are static and whose format does not depend on the value of other fields.
3454However, even if only a portion of your protocol is statically defined,
3455then that portion could make use of ptvcursors.
3456
3457The ptvcursor API lets you extract data from a tvbuff, and add it to a
3458protocol tree in one step. It also keeps track of the position in the
3459tvbuff so that you can extract data again without having to compute any
3460offsets --- hence the "cursor" name of the API.
3461
3462The three steps for a simple protocol are:
3463 1. Create a new ptvcursor with ptvcursor_new()
3464 2. Add fields with multiple calls of ptvcursor_add()
3465 3. Delete the ptvcursor with ptvcursor_free()
3466
3467ptvcursor offers the possibility to add subtrees in the tree as well. It can be
3468done in very simple steps :
3469 1. Create a new subtree with ptvcursor_push_subtree(). The old subtree is
3470 pushed in a stack and the new subtree will be used by ptvcursor.
3471 2. Add fields with multiple calls of ptvcursor_add(). The fields will be
3472 added in the new subtree created at the previous step.
3473 3. Pop the previous subtree with ptvcursor_pop_subtree(). The previous
3474 subtree is again used by ptvcursor.
3475Note that at the end of the parsing of a packet you must have popped each
3476subtree you pushed. If it's not the case, the dissector will generate an error.
3477
3478To use the ptvcursor API, include the "ptvcursor.h" file. The PGM dissector
3479is an example of how to use it. You don't need to look at it as a guide;
3480instead, the API description here should be good enough.
3481
34822.11.1 ptvcursor API.
3483
3484ptvcursor_t*
3485ptvcursor_new(proto_tree* tree, tvbuff_t* tvb, gint offset)
3486 This creates a new ptvcursor_t object for iterating over a tvbuff.
3487You must call this and use this ptvcursor_t object so you can use the
3488ptvcursor API.
3489
3490proto_item*
3491ptvcursor_add(ptvcursor_t* ptvc, int hf, gint length, const guint encoding)
3492 This will extract 'length' bytes from the tvbuff and place it in
3493the proto_tree as field 'hf', which is a registered header_field. The
3494pointer to the proto_item that is created is passed back to you. Internally,
3495the ptvcursor advances its cursor so the next call to ptvcursor_add
3496starts where this call finished. The 'encoding' parameter is relevant for
3497certain type of fields (See above under proto_tree_add_item()).
3498
3499proto_item*
3500ptvcursor_add_ret_uint(ptvcursor_t* ptvc, int hf, gint length, const guint encoding, guint32 *retval);
3501 Like ptvcursor_add, but returns uint value retrieved
3502
3503proto_item*
3504ptvcursor_add_ret_int(ptvcursor_t* ptvc, int hf, gint length, const guint encoding, gint32 *retval);
3505 Like ptvcursor_add, but returns int value retrieved
3506
3507proto_item*
3508ptvcursor_add_ret_string(ptvcursor_t* ptvc, int hf, gint length, const guint encoding, wmem_allocator_t *scope, const guint8 **retval);
3509 Like ptvcursor_add, but returns string retrieved
3510
3511proto_item*
3512ptvcursor_add_ret_boolean(ptvcursor_t* ptvc, int hf, gint length, const guint encoding, gboolean *retval);
3513 Like ptvcursor_add, but returns boolean value retrieved
3514
3515proto_item*
3516ptvcursor_add_no_advance(ptvcursor_t* ptvc, int hf, gint length, const guint encoding)
3517 Like ptvcursor_add, but does not advance the internal cursor.
3518
3519void
3520ptvcursor_advance(ptvcursor_t* ptvc, gint length)
3521 Advances the internal cursor without adding anything to the proto_tree.
3522
3523void
3524ptvcursor_free(ptvcursor_t* ptvc)
3525 Frees the memory associated with the ptvcursor. You must call this
3526after your dissection with the ptvcursor API is completed.
3527
3528
3529proto_tree*
3530ptvcursor_push_subtree(ptvcursor_t* ptvc, proto_item* it, gint ett_subtree)
3531 Pushes the current subtree in the tree stack of the cursor, creates a new
3532one and sets this one as the working tree.
3533
3534void
3535ptvcursor_pop_subtree(ptvcursor_t* ptvc);
3536 Pops a subtree in the tree stack of the cursor
3537
3538proto_tree*
3539ptvcursor_add_with_subtree(ptvcursor_t* ptvc, int hfindex, gint length,
3540 const guint encoding, gint ett_subtree);
3541 Adds an item to the tree and creates a subtree.
3542If the length is unknown, length may be defined as SUBTREE_UNDEFINED_LENGTH.
3543In this case, at the next pop, the item length will be equal to the advancement
3544of the cursor since the creation of the subtree.
3545
3546proto_tree*
3547ptvcursor_add_text_with_subtree(ptvcursor_t* ptvc, gint length,
3548 gint ett_subtree, const char* format, ...);
3549 Add a text node to the tree and create a subtree.
3550If the length is unknown, length may be defined as SUBTREE_UNDEFINED_LENGTH.
3551In this case, at the next pop, the item length will be equal to the advancement
3552of the cursor since the creation of the subtree.
3553
35542.11.2 Miscellaneous functions.
3555
3556tvbuff_t*
3557ptvcursor_tvbuff(ptvcursor_t* ptvc)
3558 Returns the tvbuff associated with the ptvcursor.
3559
3560gint
3561ptvcursor_current_offset(ptvcursor_t* ptvc)
3562 Returns the current offset.
3563
3564proto_tree*
3565ptvcursor_tree(ptvcursor_t* ptvc)
3566 Returns the proto_tree associated with the ptvcursor.
3567
3568void
3569ptvcursor_set_tree(ptvcursor_t* ptvc, proto_tree *tree)
3570 Sets a new proto_tree for the ptvcursor.
3571
3572proto_tree*
3573ptvcursor_set_subtree(ptvcursor_t* ptvc, proto_item* it, gint ett_subtree);
3574 Creates a subtree and adds it to the cursor as the working tree but does
3575not save the old working tree.
3576
35772.12 Optimizations
3578
3579A protocol dissector may be called in 2 different ways - with, or
3580without a non-null "tree" argument.
3581
3582If the proto_tree argument is null, Wireshark does not need to use
3583the protocol tree information from your dissector, and therefore is
3584passing the dissector a null "tree" argument so that it doesn't
3585need to do work necessary to build the protocol tree.
3586
3587In the interest of speed, if "tree" is NULL, avoid building a
3588protocol tree and adding stuff to it, or even looking at any packet
3589data needed only if you're building the protocol tree, if possible.
3590
3591Note, however, that you must fill in column information, create
3592conversations, reassemble packets, do calls to "expert" functions,
3593build any other persistent state needed for dissection, and call
3594subdissectors regardless of whether "tree" is NULL or not.
3595
3596This might be inconvenient to do without doing most of the
3597dissection work; the routines for adding items to the protocol tree
3598can be passed a null protocol tree pointer, in which case they'll
3599return a null item pointer, and "proto_item_add_subtree()" returns
3600a null tree pointer if passed a null item pointer, so, if you're
3601careful not to dereference any null tree or item pointers, you can
3602accomplish this by doing all the dissection work. This might not
3603be as efficient as skipping that work if you're not building a
3604protocol tree, but if the code would have a lot of tests whether
3605"tree" is null if you skipped that work, you might still be better
3606off just doing all that work regardless of whether "tree" is null
3607or not.
3608
3609Note also that there is no guarantee, the first time the dissector is
3610called, whether "tree" will be null or not; your dissector must work
3611correctly, building or updating whatever state information is
3612necessary, in either case.
3613
3614/*
3615 * Editor modelines - https://www.wireshark.org/tools/modelines.html
3616 *
3617 * Local variables:
3618 * c-basic-offset: 4
3619 * tab-width: 8
3620 * indent-tabs-mode: nil
3621 * End:
3622 *
3623 * vi: set shiftwidth=4 tabstop=8 expandtab:
3624 * :indentSize=4:tabSize=8:noTabs=true:
3625 */
3626