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.
