[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=475

--- Comment #8 from Guy Harris <guy@xxxxxxxxxxxx> 2009-12-30 17:47:10 PST ---
> Ok, so this is a difference between using pcap_open_live() and pcap_create()/pcap_activate()?  Because I can capture with 802.11 headers when using pcap_open_live(), but I'm unable to select linktype when using pcap_create()/pcap_activate().

Yes, it is an intentional difference.  On some platforms (such as one rhyming
with "Finnux" :-)), with at least some adapters and drivers, the *only* way to
determine what link-layer header types are available in monitor mode is to go
into monitor mode and find out what link-layer header type is provided.  On
others, such as Mac OS X Leopard and later, the OS gives you a list of
link-layer header types, and some of them implicitly turn on monitor mode (all
the 802.11 link-layer header types are available only in monitor mode.  On
still others, such as *BSD, monitor mode is independent of link-layer header
type (although monitor mode plus Ethernet headers makes sense only if you see
only data frames, and might not work - you can, however, get 802.11 headers, or
802.11 headers plus radio headers, even if you're not in monitor mode).  Mac OS
X Tiger is a bit more complicated - you have the "enN" device, which doesn't
run in monitor mode and gives you only Ethernet headers, and the "wltN" device
device, which always runs in monitor mode and gives you 802.11 headers.

The pcap_create()/pcap_activate() behavior was chosen so as to make it work in
as similar a fashion as possible on all platforms, so that applications don't
have to care how the platform behaves.  If you select monitor mode, you get, by
default, the "best" 802.11 header type (radiotap beats AVS, AVS beats Prism,
Prism beats no radio, and "beats" is a transitive relation).

For backwards compatibility, if you use pcap_open_live() on Mac OS X Leopard
and later, you get all the link-layer types when you ask for a list of
link-layer types, and can select any of those link-layer types.

> Does pcap_open_live() "set rfmon" behind the scenes?

No.  "Set rfmon" is done *very* differently on different platforms (and even
differently between OS X Tiger and OS X Leopard-and-later) - go take a look at
top-of-Git-tree libpcap's pcap-linux.c for the steaming pile of code I wrote
for Linux, and then see pcap-bpf.c for the
not-quite-as-high-but-still-a-bit-steamy pile of code for *BSD and Mac OS X. 
pcap_set_datalink(), on systems with BPF, just does the ioctl to set the
link-layer header type; if you do that ioctl on an AirPort device in OS X
Leopard and later, and the link-layer header type is an 802.11-header type,
that turns on monitor mode.

On OS X Leopard and later, pcap_activate() does that ioctl behind the scenes if
you've requested monitor mode.

> I really just want the old behaviour.  I do not want to introduce a "monitor mode" option at this point, just introduce "set buffer size".  And I'm using Mac OS X 10.6 here.

Unfortunately, BPF doesn't let you set the buffer size once you've bound the
BPF device to an adapter, so the desired buffer size has to be known before the
BPF device is bound to the adapter.  Thus, it's un-implementable with
pcap_open_live(); my original proposal on tcpdump-workers was a new "open live
capture" call with an extensible list of options, but the consensus we reached
was the pcap_create()/pcap_activate() scheme, where you do a pcap_create(),
make calls to set open options, and do a pcap_activate().  That means you have
to use pcap_create() and pcap_activate() if you want to set the buffer size,
and thus have to offer an explicit "monitor mode" option as well if you're
going to support monitor mode on OS X.

If you want to hand this over to me, go ahead, given that I'm the person who
put all that monitor mode stuff into libpcap in the first place.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.