Re: AIX BPF Problems

[Shaun <delius () progsoc uts edu au>]

> > 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?

Yes, in fact it does so before EVERY read.

> 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.

> From what I can tell the timeout basically doesn't work at all (though
admitedly I haven't really tried since I don't need that functionality)

> >     - 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.

Yes, exactly.

> >     - 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?

16k

> >     - 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.

Yep

> 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?

Yeah, that's the symptom. It's very strange.

> >     - 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?

Yep

> >     - 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?

Exactly. Where is gets even weirder is that further experimentation showed
that:
        - Modifying bpf_load() to always do the sysconfig stuff even if
the loaded flag was already set caused the problem to go away
        - Modifying the bpf_load() code to not query the ODM via
getminors() caused the problem to go away
        - Modifying pcap to call bpf_load() before doing anything (i.e
before iterating over the devices etc) caused the problem to go away

> >     - 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?

Exactly.

> 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?

None that is obvious, the only difference appears to be that one involves
the bpf_load being called during the iteration of the devices, the other
does not. Though closing the UDP socket before calling pcap_open_live and
reopening it on the other side of the pcap_open doesn't fix the problem.

> >     - 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.

Yeah.

> 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?

Yeah, sorry, repeated myself on that one

> >     - 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?

That would certainly appear to be the case.

> >     - 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?

Yeah, 68, though from my cursory search I didn't see that value getting
passed to the kernel?

Thanks,
Shaun

-
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