In order to conform to the schema, we'd need to insist that items were always added inside protocol trees, and not directly in to the top-level tree passed to dissectors.
The TCP dissector writes unparsed data into the top-level tree. I know that I also added an ARP entry to the top-level tree (in the case where duplicate use of IP addresses is detected). I'm not sure if there really is the will to change these things to conform to the schema?
On Jan 28, 2008 7:09 PM, <
bugzilla-daemon@xxxxxxxxxxxxx> wrote:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2226
Summary: Mismatching </proto> element in a PDML explort
Product: Wireshark
Version: SVN
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: prasad.shenoy@xxxxxxxxx
CC: prasad.shenoy@xxxxxxxxx
Build Information:
wireshark 0.99.8-SVN-24191 (SVN Rev 24191)
Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.5, with GLib 2.14.5, with WinPcap (version unknown),
with libz 1.2.3, with libpcre 6.4, with SMI 0.4.5, with ADNS, with Lua 5.1,
with
GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio
V19-devel, with AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
Overview: The PDML export of a capture contains a mis-matched </proto> element
(closing tag) that conflicts with the PDML specifications.
Details: The problem of an extra </proto> element was initially addressed and
fixed in bug# 2185 but the fix removed the wrong element.
E.g:
PDML with problems looked like this:
<pdml>
<packets>
<packet>
<proto>
<field>...</field>
</proto>
<field>...</field>
</proto> <-- mis-matching element
</packet>
</packets>
</pdml>
bug fix for #2185 removed the wrong element. Now, the PDML looks like this:
<pdml>
<packets>
<packet>
<proto>
<field>...</field>
</proto>
<field>...</field>
</packet>
</packets>
</pdml>
As per the PDML specifications
(http://gd.tuwien.ac.at/.vhost/analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm)
the <field> elements cannot occur directly under <packet> parent element. The
bug fix for #2185 might be breaking the specification for PDML.
The element that should have been removed is the first (inner) closing </proto>
element.
The conforming PDML should look like:
<pdml>
<packets>
<packet>
<proto>
<field>...</field>
<field>...</field>
</proto>
</packet>
</packets>
</pdml>
Steps to Reproduce:
1. Open the attached mis-match-proto-element.pcap file in wireshark
2. Choose on File -> Export -> File...
3. In the Wireshark: Export File dialog that appears,
- Enter a file name in "File name:" text box
- Select PDML (XML Packet Detail).xml from the "Save as type:" drop-down
4. Click Save
5. Open the .pdml file using your favorite text editor and search for </proto>
elements until you encounter one that has one or more <field> elements
following it instead of another <proto> or a </packet> element.
Approximate location is around line 493 (first occurrence)in the attached .pdml
file.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Wireshark-bugs mailing list
Wireshark-bugs@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-bugs
