[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2226





--- Comment #5 from Jeff Morriss <jeff.morriss@xxxxxxxxxxx>  2008-01-31 23:16:17 GMT ---
(In reply to comment #3)
> ---whats that???---
>   <field name="tcp.segments" showname="Reassembled TCP Segments (1516 bytes):
> #181(1460), #182(56)" size="1516" pos="0" show="" value="">
>     <field name="tcp.segment" showname="Frame: 181, payload: 0-1459 (1460
> bytes)" size="1460" pos="0" show="181"
> value="485454502f312e3120323030204f4b0d0a446174653a205468752c203331204a616e20323030382030373a30323a303520474d540d0a5365727665723a204170616368652f322e322e33202844656269616e29206d6f645f707974686f6e2f332e322e313020507974686f6e2f322e342e34205048502f352e322e302d382b657463683130206d6f645f73736c2f322e322e33204f70656e53534c2f302e392e3863206d6f645f7065726c2f322e302e32205065726c2f76352e382e380d0a582d506f77657265642d42793a205048502f352e322e302d382b6574636831300d0a457870697265733a205468752c203139204e6f7620313938312030383a35323a303020474d540d0a43616368652d436f6e74726f6c3a206e6f2d63616368650d0a507261676d613a206e6f2d63616368650d0a566172793a204163636570742d456e636f64696e670d0a436f6e74656e742d547970653a20746578742f6a6176617363726970740d0a436f6e74656e742d6c656e6774683a20313035320d0a50726f78792d436f6e6e656374696f6e3a204b6565702d416c6976650d0a436f6e6e656374696f6e3a204b6565702d416c6976650d0a436f6e74656e742d456e636f64696e673a20677a69700d0a0d0a1f8b08000000000000037c556d6fdb3610feee5f71288a5a4e0cc
 96bba17c40bd0a24bd3acdd1620dd802208065a3a59ac655220296b469bffbe3bd292a5d8a9be5012ef1ededdf3dc31393919c109fc2e36c2a646560e4ab930c26cc1692884ca4a0401161de81c56b85d489549b5b43179b1e3a702a1b668c016ba2e33902a2deb0cc115d242409c02c1d00f54908ab264b00f1d5044985306e2ad85485713c8b5011469d13b8ebc850342ccd04a83594ce776f8d04842756285046290c128d6525a878a7d198fa02a83d6a2f5c1ac455505585c73a2b47601405eabd449adec14b461b44cb3add29413ad32a7d7bd358781ae2dc7f3f7da64780e052f89c375550a8736f9d2d537e917f18b9d6ee087f8c7f855fc33bc9ccd7e4a66bf246733989d9dcf66e7672f212d6a3ae3f2bf0a9eef4eb845f4e122155a5bcc209744d1dbbf6e3e5fff79e5732d658aca2251415f6bc1a940f4f1eae6e32486eb1cb6ba864c668c452981c114e5664718634d291f84c2b9ea3c499aa689739bc7da2c935457db12739794cbaa8c0bb72edbac5f575409b144f0d9d39f64344a82b0de90886cf184785e6f84817f69e30f5179afde375c80c206de1823b6d164de01de9214ebca97a02575c7359ad883104151a6d37a8dcac5a9a85c6df072431f165ebc00ff167fb8fcfcf7cd04be8e809ee3c651df723e7a1875665ad1c9354748eb7bdf236610a0e50845
 4f51c48a60e35467d82b9a116bfe0be1f91452621baf4923974b6a2cade29e7987e9cd5ba9b2bdefad86bbec19a13c636106c953b7dc86e65c502f33d6c1d3e290401c2c39012f312e40dbbc5d68827039147468ecf4289cd5a161596aa9503c20288d61b8bbd9b2ae4b27abd2c35beaada3788c53ca15067e3b94c341b29f22a3402d6bc16d2b24fded747547cb3d5c5cc0b85619e65261366e85c0cfd00ceeeee77eeb61f418af6382b1da989e848aabda165117de0e14b0a4d27ccf837be0dd0e3c1ae3780a63da1cef3385531847d4b4f477321f4f5a64d26b2bc86bb5d12b1a148bade79147fd6d189c81e035b1ba538e17e9403957240606e92b20128e271bab647f4790f81646377415d889d74ca9f5ca5bf03809c4363457c4862f94e06560c780ef102f193ac34f29ab438a20dda386c120fd107b17c040e3dd647824987dbb46d82a84470e12d108dfbed14da232ddc41e7bbe671c63f27c4ba9f7d9e54a915bbb3560343835854c8b632e7e63a0abe48493a6221b1cdb27ebe32908756a444752285438e484ea35a5feb4d65f556ad8b9bb4ef6e9c55c9936c1beeefa01f3b111574852dcb3392dbf0e355aa25aba620ea7a7b2ef770cf74edeb73a7d6cca0fc60669f8aa7f4459331fb9a042ce0fcc7a0d88311580"/>
>     <field name="tcp.segment" showname="Frame: 182, payload: 1460-1515 (56
> bytes)" size="56" pos="1460" show="182"
> value="53f90d734163e4e9461c9e33f48a2687871cf4e5f70275a63e12e7c3c19f8541b11a1aee8d1ebaaefd1f0000ffff0300e11a872691090000"/>
>   </field>
> ---whats that???---
> 
>   <proto name="http" showname="Hypertext Transfer Protocol" size="464" pos="0"> 
> 
> After a <proto>-tag follows a field tag with tcp-segments?!?!
> Seems like there is new layer in the OSI Model.

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 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?)


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.