Re: libdlpi with libpcap

[sagun shakya <Sagun.Shakya () Sun COM>]

[Reposting as I had the put the wrong mailing list.]



Thank you for your response. Please see my responses inline.

Guy Harris 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".

Yes, you will be able to see *non*-IP- layer traffic. With the
improvements mentioned above there will be no regression in the existing
libpcap features but additional devices like loopback, and IP tunnel
interfaces will be observable.

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

dlpi_walk() will walk all DLPI devices, including SunATM. In which case
we wouldn't need the pcap_platform_finddevs() and have a probably a
fad-libdlpi.c file, which would have the pcap-findalldevs() functionality.

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

That is true that libdlpi APIs can replace the lower-level routines in
pcap-dlpi.c but at the higher level stuff that pushes STREAMS modules
atop DLPI devices cannot be replaced. We do similar thing for the
snoop(1M) application.

Although, I haven't done implementation work with all the 3 solutions
above. My solutions were based on skimming through the pcap code.
Since the plan isn't to replace the lower-level routines in pcap-dlpi.c
for all other releases of Solaris and other platforms, just adding
#ifdef in the pcap-dlpi.c file for libdlpi would not be a clean
approach. For this same reason solution 1 is probably a better approach
as we will have a separate file to handle just Solaris release that have
libdlpi apis. It may be the case that a lot of code will have to be
repeated in the pcap-libdlpi.c file after implementing solution 1 and in
that case I would like to go with solution 2.

As for pcap_read_dlpi(), dlpi_recv() can probably be used instead of
getmsg() since dlpi_recv() is just a wrapper function around an API to
get data message using DLPI.


Thanks,

Sagun


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.