Hi,
Read the manual page very carefully: "Text2pcap understands a hexdump of the
form generated by od -Ax -tx1. In other words, each byte is individually
displayed and surrounded with a space."
That is also the problem with the patch discussed earlier, it doesn't really
work in all cases.
Thanx,
Jaap
Andy Lawman wrote:
Abhik,
text2pcap was designed to read hex dumps in od format ie: with a
character representation of the data on the right. If, like me, you have
to create a hex dump from some other source to act as input to
text2pcap, then it's your responsibility to ensure that there's
something on the right that acts as a place holder. I append " .." which
is sufficient for text2pcap.
Andy.
*"Abhik Sarkar" <sarkar.abhik@xxxxxxxxx>*
To
wireshark-dev@xxxxxxxxxxxxx
cc
bcc
Subject
[Wireshark-dev] Question on text2pcap behaviour
*"Abhik Sarkar" <sarkar.abhik@xxxxxxxxx>*
Please respond to : Developer support list for Wireshark
<wireshark-dev@xxxxxxxxxxxxx>
Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx
01/05/2008 09:36
Hi All,
I just ran into a small problem while using text2pcap and I wanted to
know (before I attempt to fix it) whether this is a problem at all.
Let's say I have a text file with a single line as so (this is just an
example, not actual payload):
00000000 30 31 32 33 34 35 36 37 38 39 0123456789
According to the comments in text2pcap.c, The text at the end is
ignored. My interpretation of this is that the text at the end may or
may not be present. Perhaps this interpretation is not quite right
because, if I have a like like this (quotes added to clarify the
situation):
"00000000 30 31 32 33 34 35 36 37 38 39"
the last byte is ignored. However, if the line is like this
"00000000 30 31 32 33 34 35 36 37 38 39 "
then it is parsed correctly.
Not having the text part in the end is useful sometimes because
sometimes we get just a hex dump of the TCP payload (but without the
text part in the end).
Thanks!
Abhik.
