On Oct 5, 2007, at 3:35 PM, sagun shakya wrote:
> Improvements after adding support to libpcap:
> ---------------------------------------------
> * Observe all IP layer network traffic, including loopback, IPMP
> group, IP tunnel traffic and IP layer network traffic flowing to and
> from a zone.
This will still also allow you see *non*-IP-layer traffic, right?
I.e., you'll see all link-layer packets received by the hardware, even
if the networking stack would otherwise discard them? Otherwise, it
doesn't fully qualify as an "improvement".
> * Currently, pcap_findalldevs() which lists all the network devices on
> the system for packet capturing uses SIOCGLIFCONF to generate the
> list on Solaris. This limits the lists to network devices that are
> plumbed IP interfaces. libdlpi has an interface dlpi_walk(), which
> will walk all the network device, thus will provide a complete list.
Including SunATM devices? See, for example, pcap_platform_finddevs()
in pcap-dlpi.c.
> I would like to hear from you for suggestions on how libpcap can be
> updated to libdlpi. I have a couple of possible approaches to make
> this addition but they may not necessarily be the best approach:
>
> 1) Introduce a new pcap-libdlpi-solaris.c file which will handle all
> the
> versions of Solaris with libdlpi. The existing pcap-dlpi.c will
> continue
> working for pre-libdlpi versions of Solaris.
>
> 2) Continue with the use of ifdef #HAVE_SOLARIS approach in the
> existing
> pcap-dlpi.c file to call libdlpi functions for releases that support
> libdlpi.
>
> 3) Instead of using libdlpi, add support to open different
> directories, i.e /dev/net, /dev/ipnet, and add other Solaris-
> specific ioctls to the existing pcap-dlpi.c file under #ifdef
> protection.
A quick look at
http://in.opensolaris.org/os/community/arc/caselog/2007/282/materials/libdlpi-api_updated-txt/
suggests that libdlpi APIs could replace some of the lower-level
routines in pcap-dlpi.c - but not the higher-level stuff that pushes
STREAMS modules atop the DLPI device, etc.
As such, I'd vote for solution 2. pcap_read_dlpi() would presumably
continue to directly call getmsg() on the low-level file descriptor,
as it's *NOT* getting DLPI messages, it's getting a chunk of packets
as delivered by bufmod.
