Wireshark-bugs: [Wireshark-bugs] [Bug 2226] Mismatching </proto> element in a PDML explort
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2226
Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |martin.r.mathieson@googlemai
| |l.com
--- Comment #6 from Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> 2008-01-31 23:59:12 GMT ---
(In reply to comment #5)
>
> Yes, there are some things Wireshark adds to the "top level tree" that are
> sort-of metadata that are not from this particular packet.
>
> In this case the data is Wireshark telling the user that there are some
> reassembled TCP fragments being displayed in this frame.
>
> It makes sense when you look at the GUI but apparently not to PDML.
>
>
> Martin, to answer your question from the -dev list here in the bug: things like
> this (TCP reassembly marker) or your ARP example should be GENERATED (flagged
> with PROTO_ITEM_SET_GENERATED()), right? Would it make sense (would it be
> possible) to not put GENERATED things into PDML? After all, they're not part
> of the message but rather are part of Wireshark's interpretation of it.
>
I'm not sure that that's true. Everything except the raw data is arguably
Wireshark's interpretation. I've fixed a few PDML bugs mainly because at my
company we discussed using the output, but in the end did something else. So
I'm not sure that we'd only be interested in the non-generated fields.
> (I may be showing my complete ignorance of PDML here in which case, well,
> sorry.)
>
> (OK that may not solve the general problem which allows anybody to put whatever
> they want on the top level tree, but maybe it will fix most examples?)
>
Any changes may upset someone whose application depends upon the status quo.
We could:
- tighten up the proto.h functions to not allow fields to be added outside of
protocol trees, and fix violations (although I expect the checking could only
take place at run-time, so it may take a while to pick them all up). I did
have a go at adding a second (protocol) tree to the function
decode_tcp_ports(). If it failed to find a dissector to call, it would use the
2nd (existing protocol) tree to add the data field inside the existing
protocol. This worked OK for TCP iteself and msproxy, but not easily for the
HTTP dissector.
- make the 'data' dissector print as a protocol instead of as a field. This
would help a lot.
- in the PDML output, keep track of the level, and if we attempt to write out
fields at level 0, wrap them up in a fake protocol
I don't have any applications to break. It'd be good to hear from people who
rely upon the output.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
