Re: libdlpi with libpcap

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

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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.