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.
|
