[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

I'd propose to add all XML stuff even when printing a single packet,
otherwise this output breaks the PDML description. Additionally, you get a
free gift with this: merging captures in XML format will be trivial then.

Regards,

Olivier

| -----Original Message-----
| From: Martin Regner
| 
| Gilbert Ramirez wrote:
| > I've committed the change to CVS. Update and read the
| > doc/README.xml-output file for more information.
| >
| > To produce PDML from a capture file, use:
| >
| > tethereal -Tpdml -V -r capturefile
| >
| > enjoy!
| 
| I think that I will have much use of the new feature in the future.
| Thanks a lot for providing the new functionality.
| 
| However I would also have the possibility to get the hex-data 
| for each PDU
| in the
| generated PDML document.
| Ethereal/Tethereal is a very good tool for reassembling data 
| and so on, but
| in some cases I want
| to be able to do some post-processing on the reassembled 
| TPKT/H.225/H.245
| PDUs or similar.
| I have used a modified version of tethereal to dump the 
| complete/reassembled
| TPKT PDUs as hex octets in the normal printouts as a temporar 
| solution.
| 
| Maybe we could use the "-x" option to specify whether to 
| include the hex
| data in the PDML document.
| 
| I have attached a very simple patch that I used for some experiments
| yesterday and a sample
| PDML file I generated.
| 
| With the current patch the hex data for the complete frame is 
| given in hex
| for proto "frame", but for proto "ip" it's just the hex data 
| for the IP
| header and not including the IP payload, and the same for 
| proto "eth", "tcp"
| and "tpkt".
| This was actually unintended and I haven't looked closer how 
| I could get the
| hex data for e.g. the complete
| (reassembled) TPKT PDU.
| 
| The attached patch is not intended for check-in, but just 
| included as a
| preliminar example.
| 
| I was also thinking that it may be good to indicate the 
| underlaying protocol
| for each proto entry, e.g.
| something like below:
| <proto name="eth"  baseproto="frame"  ..
|  :
| </proto>
| <proto name="ip" baseproto="eth" ...
|  :
| </proto>
| <proto name="tcp" baseproto="ip"  ...
|  :
| </proto>
| <proto name="tpkt" baseproto="tcp"  ...
|  :
| </proto>
| <proto name="q931" baseproto="tpkt" ...
|  :
| </proto>
| <proto name="h225" baseproto="q931" ...
|  :
| </proto>
| <proto name="tpkt" baseproto="tcp"  ...
|  :
| </proto>
| <proto name="q931" baseproto="tpkt" ...
|  :
| </proto>
| <proto name="h225" baseproto="q931" ...
|  :
| </proto>
| 
| or
| 
| <packet>
| :
| <proto name="frame"   ..
|  :
| </proto>
| <proto name="eth"  protopath="frame"  ..
|  :
| </proto>
| <proto name="ip" protopath="frame/eth" ...
|  :
| </proto>
| <proto name="tcp" protopath="frame/eth/ip"  ...
|  :
| </proto>
| <proto name="tpkt" protopath="frame/eth/ip/tcp"  ...
|  :
| </proto>
| <proto name="q931" protopath="frame/eth/ip/tcp/tpkt" ...
|  :
| </proto>
| <proto name="h225" protopath="frame/eth/ip/tcp/tpkt/q931" ...
|  :
| </proto>
| <proto name="tpkt" protopath="frame/eth/ip/tcp"  ...
|  :
| </proto>
| <proto name="q931" protopath="frame/eth/ip/tcp/tpkt" ...
|  :
| </proto>
| <proto name="h225" protopath="frame/eth/ip/tcp/tpkt/q931" ...
|  :
| </proto>
| </packet>
| 
| I haven't looked so much on PDML specifications, so it might 
| be that I have
| missed if there is some other mecahnism that can be used for 
| indicating how
| the protocols are related.
|