On Tue, 14 Dec 1999, Guy Harris wrote:
> > Because the i4btrace format doesn't include a magic header to
> > authoritative brand it as an I4B trace file,
>
> That's unfortunate.
Very much so. Fortunately, the project owner is very willing to accept
patches, unfortunately, the heap of things on my plate is way to big for
me... Sigh...
> Hopefully, if the "tcpdump.org" group does a new generation of "libpcap"
> format (with per-packet encapsulation types, and a wider range of
> encapsulation type values, *not* tied to the encapsulation type codes of
> *any* OS, including BSD - i.e., don't use DLT_ values, that encourages
> bogosities such as calling Linux loopback packets DLT_NULL, and, as
> encapsulation types added by different BSD-flavored OSes don't always
> have the same values, and sometimes they collide, causes the
> encapsulation types to be platform-dependent), it can be used for ISDN
> captures, rather than having a separate format that, alas, lacks a magic
> number.
Yup, that is a cool idea. I hope to have some more discretionary time on
my hands when the spec becomes available.
> If i4btrace were to run on a big-endian machine (I'm assuming "i4b"
> refers to ISDN4BSD, and that it's available on NetBSD or OpenBSD, not
> just the currently-little-endian-only FreeBSD), in what byte order would
> it write the stuff in the packet header - little-endian, or native byte
> order? (I'm trying to get Ethereal to read your capture file on
> Solaris/SPARC.)
I'd guess little-endian, but I'm not sure. I know it exists on Atari and
Amiga, but I'm not positive anyone has ever moved a trace across.
Cheers,
-- Bert
Bert Driehuis, MIS -- bert_driehuis@xxxxxxxxxxxxxxxx -- +31-20-3116119
Hi! I'm a signature virus! Copy me to your .signature and help me spread!
