Wireshark-dev: Re: [Wireshark-dev] Question on text2pcap behaviour
From: Jaap Keuter <[email protected]>
Date: Fri, 02 May 2008 13:39:38 +0200

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.

Andy Lawman wrote:

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.

*"Abhik Sarkar" <[email protected]>*
	[email protected]
	[Wireshark-dev] Question on text2pcap behaviour


		*"Abhik Sarkar" <[email protected]>*

Please respond to : Developer support list for Wireshark <[email protected]>
Sent by: [email protected]  
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
"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).