[Guy Harris <gharris@xxxxxxxxx>]

On Fri, Nov 23, 2001 at 05:42:45PM -0800, Guy Harris wrote:
> It really needs to be fixed so that, as long as it's processing what it
> thinks it's text, it thinks *EVERYTHING* is text - not offsets, not
> binary data, not *ANYTHING* else - until it sees a line ending.

Well, that bug is fixable with a change to the scanner to separately
handle putative offsets not followed by EOL and putative offsets
followed by EOL.

However, there's yet another (long-standing) bug, wherein the line

00D0     20 31 38 20 4D 61 72 20 32 30 30 31 20 31 37 3A         18 Mar 2001 17:

also confuses text2pcap, as it thinks the "18" is a byte, not part of
the text.

Unless somebody *knows* of a text dump format in which the number of
bytes of packet data per line doesn't have an absolute maximum (e.g.,
16), text2pcap should have such a maximum, and if it's seen that many
byte values per line, ignore all subsequent byte values.  The maximum
should probably default to 16, and be settable with a command-line flag.