[Marc Milgram <mmilgram@xxxxxxxxxxxx>]

I don't know of an elegant way to get at raw packet data on a network
interface in VMS.  The TCPtrace maintainer indicated that he would like
to add a binary file format, but I don't know of any time table for
doing that.

Many traces that I look at are from Compaq's customers.  So, until they
have and use a binary output version, I am stuck with the text-mode
version.  There is no documented binary option in the current
development version of tcptrace, and there is a feature freeze.

There is a third-party tool called dbs-etherwatch that dumps ip frames
in an easy to parse text format (at least from the one trace that I
needed to handle).

Another engineer took a look at porting libpcap to VMS.  It looked
challenging.  He indicates that the lan drivers may provide the
appropriate interface to libpcap, but neither of us knows much about
that interface.  Nor do we have the time to learn right now.

Given the correct option, TCPtrace will dump ARP and ICMP packets, but
not in a format that ethereal will handle.  Unless I have a real need, I
don't plan on adding that functionality.

I mostly work on ethereal to make my job easier.  My real job is fixing
bugs in VMS TCP, mostly in NFS.


-Marc

On Thu, 2002-03-07 at 16:14, Guy Harris wrote:
> On Thu, Mar 07, 2002 at 03:59:30PM -0500, Marc Milgram wrote:
> > In my private version I now accept packets that are not tagged
> > TCPtrace.  I also contacted the maintainer of TCPtrace as to this
> > issue.  I am hesitant to release the modified code because it may parse
> > lines of text after the end of the dump, and perhaps behave strangely. 
> > I will wait to hear what the TCPtrace maintainer says after he returns
> > from his leave.
> 
> Is there any way, in VMS, to get at raw packet data on a network
> interface?
> 
> If so, it might be interesting to try to port libpcap, so you're not
> forced to rely on tools such as TCPtrace, which attempt to interpret the
> raw data and don't always do it in a way useful for Ethereal.