Re: [clearview-discuss] libdlpi with libpcap

[Guy Harris <guy () alum mit edu>]

On Feb 1, 2008, at 10:10 AM, Sebastien Roy wrote:

> * 118-123: I would think that in 2008, most compilers can do a  
> better job at assigning register use than this (making every single  
> variable a "register" variable.)  You don't have to fix this; this  
> is more a question for those more knowledgeable than me at compiler  
> optimization.

I can't speak for Sun C, but GCC, at least, tends to put things in  
registers when it thinks they belong there, regardless of whether they  
were declared with "register" or not; I would not be surprised to hear  
that Sun C does the same.  Some of libpcap's code may date back to an  
era where some compilers actually took the hint, and hasn't had the  
"register" keywords purged from it.  It's been ages since I bothered  
declaring anything "register".

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

With an 802.11 device, does turning DLPI_NATIVE on put the device into  
monitor mode, or does it just cause it to supply 802.11 headers?

Is there a way to query whether a device supports DLPI_NATIVE  
("supports" in the sense that it gives different link-layer headers  
depending on whether it's set or not)?

Is there a raw DLPI (without libdlpi) equivalent to DLPI_NATIVE in pre- 
Solaris 11 releases?

And, speaking of monitor mode, is there a way to put an 802.11 adapter  
into monitor mode, and is there a way to set the channel it uses?   
(I'm in the middle of adding monitor mode support on various  
platforms, using the new open APIs mentioned in the "supporting extend  
'open live capture' parametes" threads on tcpdump-workers; so far I  
have it working in Mac OS X 10.4, Mac OS X 10.5, and Linux - well, at  
least, in the latest Ubuntu with my Belkin USB 802.11 adapter - and  
plan to get it working in recent FreeBSD and any other *BSDs I can.   
If I can add Solaris to the list, that'd be great.)

> * 130: This looks like a bug.  In the pcap-dlpi.c code, failure to  
> enable multicast promiscuous mode does not result in a failure, but  
> only a warning.

For better or worse, that's a feature.  The existing DLPI code just  
gives a warning if that fails:

                /*
                ** Try to enable multicast (you would have thought
                ** promiscuous would be sufficient). (Skip if using
                ** HP-UX or SINIX) (Not necessary on send FD)
                */
#if !defined(__hpux) && !defined(sinix)
                if (dlpromisconreq(p->fd, DL_PROMISC_MULTI, ebuf) < 0  
||
                    dlokack(p->fd, "promisc_multi", (char *)buf,  
ebuf) < 0)
                        fprintf(stderr,
                            "WARNING: DL_PROMISC_MULTI failed (%s) 
\n", ebuf);
#endif
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.