> > * 101: Perhaps this is a good time to ask about DLPI_NATIVE. For those > not familiar with the concept, the idea is that some DLPI providers > masquerade as a well-known media type by default, but can morph into > their "native" types on-demand. Recent Solaris WiFi DLPI devices behave > this way (DL_ETHER by default, but DL_WIFI under the covers). Passing > the DLPI_NATIVE flag to dlpi_open() causes such providers to provide > access to their native media type. Do we have a plan to eventually add > support for DLPI_NATIVE here so that libpcap consumers can have access to > raw WiFi frames, for example?
I'd prototyped this support a while ago (it was a bit messier to support without libdlpi), and it worked perfectly with WireShark. I didn't try tcpdump but I suspect it'd work fine there too. It'd be great if we could support for DLPI_NATIVE integrated into libpcap though I'm not sure if it needs to be done with this wad. > * 321: dlpi_close() handles being called with a NULL dlpi_hd. (that > should probably go in the dlpi_close() man page, but I don't see it there) This seems a bit messier to me. In particular, strictly speaking, it's not clear to me that a handle has a notion of being NULL (it's supposed to be opaque to the caller and could theoretically be a scalar type) -- instead, if dlpi_open() succeeded, then the returned handle can/should be closed via dlpi_close(). (But as a practical matter, *it is* a pointer and it's convenient to compare it with NULL.) -- meem - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
