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
