Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem

[Guy Harris <gharris@xxxxxxxxxxxx>]

> I then tried re-running ethereal, and stepping into it with dbx.
> I stepped into pcap_open_live().  It looks like pcap_open_live() fails..
> The problem was deeper inside pcap, when it tried to open the
> actual device to do the packet filtering.  When I compiled
> libpcap with bpf filtering, the code would fail when it tried
> to open /dev/bpf0 for a read (this file exists on AIX).

What did it fail with?

> I then re-compiled libpcap for dlpi, but that didn't work either. 

Where did that fail?

> bpf is undocumented and unsupported under AIX.  It is only there
> to support the version of tcpdump that IBM hacked.
> 
> There is another packet filtering method under AIX called pfmod.  I'm not sure
> if this is similar to the pfmod man page I saw under Solaris.

"pfmod", on Solaris, is a STREAMS module that does packet filtering -
you push it atop a DLPI stream (or atop STREAMS NIT, in Solaris 1.x); it
doesn't provide raw packet access by itself, it just filters a stream of
raw packets sent to it by a STREAMS-based mechanism.

The filtering language it uses is the old CMU/Stanford stack machine;
unfortunately, "libpcap" doesn't support that (it sets up DLPI to give
it an unfiltered packet stream, and filters them in userland using its
own BPF interpreter; this means that packets have to be copied up to
userland before being thrown away, which is a bit of a waste, although
if you're not getting too much traffic, you may have the CPU cycles to
spare).

If the "pfmod" in AIX is like that, then

	1) it probably requires DLPI;

	2) it can't be used by "libpcap" anyway, even if DLPI *did* work
	   with "libpcap".

However, it may be unrelated, and may just have the same name.