Re: AIX BPF Problems

[Guy Harris <guy () netapp com>]

On Wed, Feb 12, 2003 at 06:01:18PM +1100, Shaun wrote:
> Here's where it gets really weird, I hope I can explain the exact symptoms
> of the problem clearly.
>
> AIXs tcpdump is based on an older version of libpcap that doesn't do the
> magic BIOCSBLEN processing.

Does it also set immediate mode with BIOCIMMEDIATE?  If not, that might
make some difference (it doesn't wake up the application on every
packet), but, as per earlier messages, the timeout doesn't appear to
work, so if they don't set immediate mode they somehow manage to get the
timeout to work.

> It simply allows the system to run with it's
> existing buffer size (which defaults to 4096). If I modify the new libpcap
> to not do the magic BIOCSBLEN processing, we get the same results, i.e no
> EFAULTs, all data returned as expected.
>
> As discussed earlier I'd prefer to have as large a kernel buffer as
> humanly possible so I tried to experiment with this to see what was
> causing it.
>       - I found that if I didn't use pcap_findalldevs() at all and
> simply opened the device immediately everything worked perfectly (i.e no
> EFAULTs). Resulting in a magic buffer size selection of 16384

I assume by "magic buffer size selection" you mean that the process that
starts with 32K and works its way down by cutting the buffer size in
half succeeds at 16K.

>       - If I listed all the interfaces first using pcap_findalldevs
> (opening and doing the magic buffer selection of 16384 on them), it
> doesn't work properly

What buffer size does it choose on the "real" open?

>       - If I list all of the interfaces first but don't do the magic
> buffer size selection (i.e choose 4096 as the start of the magic buffer
> selection code),

I.e., you still do the magic buffer size selection, you just start it at
4096.

> it seems to work properly

So if you do the "search for a good buffer size" stuff in the open done
by "pcap_findalldevs()", starting at 32768, it screws things up, but if
you start at 4096, it doesn't?

>       - If we do the same as above but start buffer size selection at
> 8k, doesn't work

...and if you start at 8K, it also doesn't work?

>       - If we stop pcap_open_live from working on any interface except
> en0, i.e rejecting them before making any attempt to process them, doesn't
> work

So if you make "pcap_findalldevs()" not open anything other than "en0",
so "pcap_findalldevs()" opens "en0" and then the program opens "en0", it
still doesn't work with the buffer size selection starting at some value
above 4K?

>       - If we open and close the en0 device a number of times (straight
> off, no list of devices), it works perfectly with magic buffer size
> selection of 16384

...but if you just open "en0" twice, with the buffer size selection
starting at 32K, it works?

So in the previous two cases:

        use "pcap_findalldevs()", opening only "en0", and then opening
        "en0";

        opening "en0" twice;

what is the difference in the set of system calls being made?

>       - Disabling pcap_open_live(name, 68, 0, 0, errbuf) call in
> add_or_find_if() causes it all to work fine with magic discovered buffer
> size 16384

So that's equivalent to not doing "pcap_findalldevs()" at all, when it
comes to calls to "pcap_open_live()" made in the program.

>               - Disabling pcap_open_live for any device other than en0
> and re-enabling the pcap_open_live() call in add_or_find_if() does NOT
> help

That's the same as

              - If we stop pcap_open_live from working on any interface except
        en0, i.e rejecting them before making any attempt to process
        them, doesn't work

right?

>       - If I call pcap_open_live(sInterface, 68, 0, 0, acErrBuf) on the
> interface before listing devices it works ok

So if you open the interface *three* times - once before calling
"pcap_findalldevs()", once in "pcap_findalldevs()", and once in the
application, with all opens starting the buffer size scan at 32K, it
works?

>       - Disabling or enabling timeout processing in pcap_open_live has
> no noticable effect
>       - Disabling the reconfigure of the driver in bpf_open() had no
> effect at all
>
> So.... I can't see much logic in this madness, any ideas?

What's the snapshot length you're using in the "pcap_open_live()" calls
you're doing explicitly?  68?
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe