Add some info about extended value string to section 1.7.1
[obnox/wireshark/wip.git] / doc / README.xml-output
1 Protocol Dissection in XML Format
2 =================================
3 $Id$
4 Copyright (c) 2003 by Gilbert Ramirez <gram@alumni.rice.edu>
5
6
7 Wireshark has the ability to export its protocol dissection in an
8 XML format, tshark has similar functionality by using the "-Tpdml" 
9 option. 
10
11 The XML that wireshark produces follows the Packet Details Markup
12 Language (PDML) specified by the group at the Politecnico Di Torino
13 working on Analyzer. The specification can be found at:
14
15 http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm
16
17 A related XML format, the Packet Summary Markup Language (PSML), is
18 also defined by the Analyzer group to provide packet summary information.
19 The PSML format is not documented in a publicly-available HTML document,
20 but its format is simple. Wireshark can export this format too. Some day it 
21 may be added to tshark so that "-Tpsml" would produce PSML.
22
23 One wonders if the "-T" option should read "-Txml" instead of "-Tpdml"
24 (and in the future, "-Tpsml"), but if tshark was required to produce
25 another XML-based format of its protocol dissection, then "-Txml" would
26 be ambiguous.
27
28 PDML
29 ====
30 The PDML that wireshark produces is known not to be loadable into Analyzer.
31 It causes Analyzer to crash. As such, the PDML that wireshark produces
32 is be labeled with a version number of "0", which means that the PDML does
33 not fully follow the PDML spec. Furthermore, a creator attribute in the
34 "<pdml>" tag gives the version number of wireshark/tshark that produced the PDML.
35 In that way, as the PDML produced by wireshark matures, but still does not
36 meet the PDML spec, scripts can make intelligent decisions about how to
37 best parse the PDML, based on the "creator" attribute.
38
39 A PDML file is delimited by a "<pdml>" tag.
40 A PDML file contains multiple packets, denoted by the "<packet>" tag.
41 A packet will contain multiple protocols, denoted by the "<proto>" tag.
42 A protocol might contain one or more fields, denoted by the "<field>" tag.
43
44 A pseudo-protocol named "geninfo" is produced, as is required by the PDML
45 spec, and exported as the first protocol after the opening "<packet>" tag.
46 Its information comes from wireshark's "frame" protocol, which serves
47 the similar purpose of storing packet meta-data. Both "geninfo" and
48 "frame" protocols are provided in the PDML output.
49
50 The "<pdml>" tag
51 ================
52 Example:
53         <pdml version="0" creator="wireshark/0.9.17">
54
55 The creator is "wireshark" (i.e., the "wireshark" engine. It will always say
56 "wireshark", not "tshark") version 0.9.17.
57
58
59 The "<proto>" tag
60 =================
61 "<proto>" tags can have the following attributes:
62
63         name - the display filter name for the protocol
64         showname - the label used to describe this protocol in the protocol
65                 tree. This is usually the descriptive name of the protocol,
66                 but it can be modified by dissectors to include more data
67                 (tcp can do this)
68         pos - the starting offset within the packet data where this
69                 protocol starts
70         size - the number of octets in the packet data that this protocol
71                 covers.
72
73 The "<field>" tag
74 =================
75 "<field>" tags can have the following attributes:
76
77         name - the display filter name for the field
78         showname - the label used to describe this field in the protocol
79                 tree. This is usually the descriptive name of the protocol,
80                 followed by some representation of the value.
81         pos - the starting offset within the packet data where this
82                 field starts
83         size - the number of octets in the packet data that this field
84                 covers.
85         value - the actual packet data, in hex, that this field covers
86         show - the representation of the packet data ('value') as it would
87                 appear in a display filter.
88
89 Some dissectors sometimes place text into the protocol tree, without using
90 a field with a field-name. Those appear in PDML as "<field>" tags with no
91 'name' attribute, but with a 'show' attribute giving that text.
92
93 Many dissectors label the undissected payload of a protocol as belonging
94 to a "data" protocol, and the "data" protocol usually resided inside
95 that last protocol dissected. In the PDML, The "data" protocol becomes
96 a "data" field, placed exactly where the "data" protocol is in wireshark's
97 protocol tree. So, if wireshark would normally show:
98
99 +-- Frame
100 |
101 +-- Ethernet
102 |
103 +-- IP
104 |
105 +-- TCP
106 |
107 +-- HTTP
108     |
109     +-- Data
110
111 In PDML, the "Data" protocol would become another field under HTTP:
112
113 <packet>
114         <proto name="frame">
115         ...
116         </proto>
117
118         <proto name="eth">
119         ...
120         </proto>
121
122         <proto name="ip">
123         ...
124         </proto>
125
126         <proto name="tcp">
127         ...
128         </proto>
129
130         <proto name="http">
131         ...
132                 <field name="data" value="........."/>
133         </proto>
134 </packet>
135
136
137
138 tools/WiresharkXML.py
139 ====================
140 This is a python module which provides some infrastructure for
141 Python developers who wish to parse PDML. It is designed to read
142 a PDML file and call a user's callback function every time a packet
143 is constructed from the protocols and fields for a single packet.
144
145 The python user should import the module, define a callback function
146 which accepts one argument, and call the parse_fh function:
147
148 ------------------------------------------------------------
149 import WiresharkXML
150
151 def my_callback(packet):
152         # do something
153
154 fh = open(xml_filename)
155 WiresharkXML.parse_fh(fh, my_callback)
156
157 # Now that the script has the packet data, do something.
158 ------------------------------------------------------------
159
160 The object that is passed to the callback function is an
161 WiresharkXML.Packet object, which corresponds to a single packet.
162 WiresharkXML Provides 3 classes, each of which corresponds to a PDML tag:
163
164         Packet   - "<packet>" tag
165         Protocol - "<proto>" tag
166         Field    - "<field>" tag
167
168 Each of these classes has accessors which will return the defined attributes:
169
170         get_name()
171         get_showname()
172         get_pos()
173         get_size()
174         get_value()
175         get_show()
176
177 Protocols and fields can contain other fields. Thus, the Protocol and
178 Field class have a "children" member, which is a simple list of the
179 Field objects, if any, that are contained. The "children" list can be
180 directly accessed by code using the object. The "children" list will be
181 empty if this Protocol or Field contains no Fields.
182
183 Furthermore, the Packet class is a sub-class of the PacketList class.
184 The PacketList class provides methods to look for protocols and fields.
185 The term "item" is used when the item being looked for can be
186 a protocol or a field:
187
188         item_exists(name) - checks if an item exists in the PacketList
189         get_items(name) - returns a PacketList of all matching items
190
191
192 General Notes
193 =============
194 Generally, parsing XML is slow. If you're writing a script to parse
195 the PDML output of tshark, pass a read filter with "-R" to tshark to
196 try to reduce as much as possible the number of packets coming out of tshark.
197 The less your script has to process, the faster it will be.
198
199 'tools/msnchat' is a sample Python program that uses WiresharkXML to parse
200 PDML. Given one or more capture files, it runs tshark on each of them,
201 providing a read filter to reduce tshark's output. It finds MSN Chat
202 conversations in the capture file and produces nice HTML showing the
203 conversations. It has only been tested with capture files containing
204 non-simultaneous chat sessions, but was written to more-or-less handle any
205 number of simultaneous chat sessions.