Re: [clearview-discuss] libdlpi with libpcap

[Peter Memishian <peter.memishian () Sun COM>]

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