ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-users: Re: [Ethereal-users] running ethereal on aix

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Tue, 31 Jul 2001 15:01:03 -0700 (PDT)
> I was trying to make the IBM libpcap (which uses bpf)to work with Ethereal
> and now it does work.The change I had to make was we had to export a symbol
> 'pcap_version' which wasnt exported by IBM libpcap.

The current version of Ethereal in CVS checks whether libpcap exports
"pcap_version", and uses it only if it's exported.

> > And in both the cases I had to disable ipv6 while configuring tcpdump.
> 
> I.e., if you didn't specify --disable-ipv6, it enabled it, but that
> didn't compile?
> 
> What errors did it produce when you tried compiling with IPv6 enabled?
> 
>  ---->
> Yes, it didnt compile unless I provide --disable-ipv6 during
> configuration.It gives me the following error.
> 
> checking whether to enable ipv6... yes
> checking ipv6 stack type... linux-libinet6
> You do not have inet6 library, using libc
> checking for library containing getaddrinfo... none required
> checking getaddrinfo bug... buggy
> Fatal: You must get working getaddrinfo() function.
>        or you can specify "--disable-ipv6".

I guess the version of AIX you're using has a buggy "getaddrinfo()" (or
perhaps the test is buggy, but I suspect not; I don't know the details
of the bug, but you might want to ask tcpdump-workers@xxxxxxxxxxx if
you're curious what the bug is).

> I have another question.Now, when I start capturing, it does show the two
> interfaces I have got.tr0 and lo0.capturing with tr0 works fine but when I
> start capturing with lo0, it gives me the error, "The network you're
> capturing from is of a type that Ethereal doesn't support."
> 
> I looked up in capture.c from where the message comes from.And somewhere in
> there it says "capture filters only work on real interfaces"
> 
> Does that mean that Ethereal doesnt work with loopback interfaces?

The comment doesn't say anything about loopback interfaces; in the
context in which "real interfaces" is being used, loopback interfaces
*are* real interfaces.  The comment means that capture filters don't
work if you're "capturing" from a pipe, i.e. running some program that
captures packets and writes a libpcap capture-file stream to its
standard output, and having Ethereal read from a pipe to that program.

The error message from Ethereal means, instead, that the AIX version of
libpcap returns, for loopback devices, a link-layer type that isn't one
of the types that Ethereal knows about.

This could either be because

	1) AIX invented a new DLT_ type, so that Ethereal - and,
	   probably, the tcpdump.org tcpdump - needs to be modified to
	   know about that type;

	2) AIX's BPF and libpcap use a different number for the loopback
	   device's link-layer type than other libpcaps use for the same
	   type, and the version of Ethereal you're using doesn't handle
	   that;

	3) AIX's BPF and libpcap don't use DLT_ values at all - I have
	   the suspicion, from what I think were AIX tcpdump captures
	   that people have had problem reading, that one of the
	   "improvements" IBM made to tcpdump was to use SNMP values for
	   link-layer types rather than DLT_ values (*without* bothering
	   to change the file's magic number so that programs reading
	   the capture know that the link-layer type should be
	   interpreted as an SNMP value; they also appear to have
	   changed time stamps to be seconds/nanoseconds rather than
	   seconds/microseconds, which is arguably better, but doing so
	   without making it possible to tell from the capture file
	   header what units are being used was just bogus).

Given that the error message was "The network you're capturing from is
of a type that Ethereal doesn't support." rather than "The network
you're capturing from is of a type that Ethereal doesn't support (data
link type N).", for some value of N, you're using an old version of
Ethereal; try using 0.8.19, which will include the offending link-layer
type in the message, making it easier to figure out what the problem is.

By the way, were you able to compile the current tcpdump with the
modified "print-sctp.c" and "sctpHeader.h"?  We ("we", in this case,
meaning tcpdump.org) would like to have the tcpdump.org tcpdump compile
on as many platforms as possible, including AIX.

Also, did you try the current tcpdump.org libpcap with tcpdump or
Ethereal, using DLPI?  We'd like to get that working as well.