forked from osmocom/wireshark
documentation: update PDML/PSML doc
Provide Internet Archive links for dead URLs. Update to note that PSML output is supported by tshark and not a future feature (true since 17 years ago, when it was still tethereal). Note "fake-field-wrapper" protocol for top level fields (including data, which is converted from a protocol to a field for PDML). Note "_ws.expert" protocol replaced by field, as with data. Note that some dissectors place subdissected protocols in subtrees instead of at the top level, and that this is _not_ changed, violating the PDML spec. Fix #10588.pespin/rlcmac
parent
3adfca384b
commit
07330b392e
|
@ -12,11 +12,8 @@ working on Analyzer. The specification was found at:
|
|||
|
||||
http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm
|
||||
|
||||
That URL is not working any more, but a copy can be found at:
|
||||
|
||||
http://gd.tuwien.ac.at/.vhost/analyzer.polito.it/docs/dissectors/PDMLSpec.htm
|
||||
|
||||
or at the internet archive:
|
||||
That URL is not working anymore, but a copy can be found at the Internet
|
||||
Archive:
|
||||
|
||||
https://web.archive.org/web/20050305174853/http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm
|
||||
|
||||
|
@ -24,16 +21,16 @@ This is similar to the NetPDL language specification:
|
|||
|
||||
http://www.nbee.org/doku.php?id=netpdl:index
|
||||
|
||||
The domain registration there has also expired, but an Internet Archive
|
||||
copy is also available at:
|
||||
|
||||
https://web.archive.org/web/20160305211810/http://nbee.org/doku.php?id=netpdl:index
|
||||
|
||||
A related XML format, the Packet Summary Markup Language (PSML), is
|
||||
also defined by the Analyzer group to provide packet summary information.
|
||||
The PSML format is not documented in a publicly-available HTML document,
|
||||
but its format is simple. Wireshark can export this format too. Some day it
|
||||
may be added to tshark so that "-Tpsml" would produce PSML.
|
||||
|
||||
One wonders if the "-T" option should read "-Txml" instead of "-Tpdml"
|
||||
(and in the future, "-Tpsml"), but if tshark was required to produce
|
||||
another XML-based format of its protocol dissection, then "-Txml" would
|
||||
be ambiguous.
|
||||
but its format is simple. Wireshark can export this format too, and
|
||||
tshark can produce it with the "-Tpsml" option.
|
||||
|
||||
PDML
|
||||
====
|
||||
|
@ -41,7 +38,9 @@ The PDML that Wireshark produces is known not to be loadable into Analyzer.
|
|||
It causes Analyzer to crash. As such, the PDML that Wireshark produces
|
||||
is labeled with a version number of "0", which means that the PDML does
|
||||
not fully follow the PDML spec. Furthermore, a creator attribute in the
|
||||
"<pdml>" tag gives the version number of wireshark/tshark that produced the PDML.
|
||||
"<pdml>" tag gives the version number of wireshark/tshark that produced the
|
||||
PDML.
|
||||
|
||||
In that way, as the PDML produced by Wireshark matures, but still does not
|
||||
meet the PDML spec, scripts can make intelligent decisions about how to
|
||||
best parse the PDML, based on the "creator" attribute.
|
||||
|
@ -96,14 +95,26 @@ The "<field>" tag
|
|||
show - the representation of the packet data ('value') as it would
|
||||
appear in a display filter.
|
||||
|
||||
|
||||
Deviations from the PDML standard
|
||||
=================================
|
||||
Various dissectors parse packets in a way that does not fit all the assumptions
|
||||
in the PDML specification. In some cases Wireshark adjusts the output to match
|
||||
the spec more closely, but exceptions exist.
|
||||
|
||||
Some dissectors sometimes place text into the protocol tree, without using
|
||||
a field with a field-name. Those appear in PDML as "<field>" tags with no
|
||||
'name' attribute, but with a 'show' attribute giving that text.
|
||||
|
||||
Some dissectors place field items at the top level instead of inside a
|
||||
protocol. In these cases, in the PDML output the field items are placed
|
||||
inside a fake "<proto>" element named "fake-field-wrapper" in order to
|
||||
maximize compliance.
|
||||
|
||||
Many dissectors label the undissected payload of a protocol as belonging
|
||||
to a "data" protocol, and the "data" protocol usually resided inside
|
||||
that last protocol dissected. In the PDML, The "data" protocol becomes
|
||||
a "data" field, placed exactly where the "data" protocol is in wireshark's
|
||||
to a "data" protocol, and the "data" protocol often resides inside
|
||||
that last protocol dissected. In the PDML, the "data" protocol becomes
|
||||
a "data" field, placed exactly where the "data" protocol is in Wireshark's
|
||||
protocol tree. So, if Wireshark would normally show:
|
||||
|
||||
+-- Frame
|
||||
|
@ -143,8 +154,24 @@ In PDML, the "Data" protocol would become another field under HTTP:
|
|||
</proto>
|
||||
</packet>
|
||||
|
||||
In cases where the "data" protocol appears at the top level, it is
|
||||
still converted to a field, and placed inside the "fake-field-wrapper"
|
||||
protocol, just as any other top level field.
|
||||
|
||||
Similarly, expert info items in Wireshark belong to an internal protocol
|
||||
named "_ws.expert", which is likewise converted into a "<field>" element
|
||||
of that name.
|
||||
|
||||
Some dissectors also place subdissected protocols in a subtree instead of
|
||||
at the top level. Unlike with the "data" protocol, the PDML output does
|
||||
_not_ change these protocols to fields, but rather outputs them as "<proto>"
|
||||
elements. This results in well-formed XML that does, however, violate the
|
||||
PDML spec, as "<proto>" elements should only appear as direct children of
|
||||
"<packet>" elements, with only "<field>" elements nested therein.
|
||||
|
||||
Note that packet tag may have nonstandard color attributes, "foreground" and "background"
|
||||
|
||||
|
||||
tools/WiresharkXML.py
|
||||
====================
|
||||
This is a python module which provides some infrastructure for
|
||||
|
|
Loading…
Reference in New Issue