Hey Michael and Guy, After writing applications that use libpcap for over 8 years, I believe that it has finally gotten to the point where I need help in understanding what version of libpcap is running so I can do what I need to do. I didn't say that pcap-int.h had existed and then went away, I'm asking that it be added to the basic install, or some form of version numbers be available.
Because you guys don't provide a complete set of routines so that we can get to all the various contents of "struct pcap", especially the bpf_program struct and the pcap_md struct, we've had to improvise, which in my case worked rather well for 4-5 years. The issue has just now gotten problematic because OS vendors are shipping with libpcap installed and they are not providing pcap-int.h. Prior to this, 95% of the time, adding an application that used libpcap meant downloading libpcap, which meant that access to pcap-int.h was pretty much a given. But now its gotten to be a little bit more complex. You guys are adding more variations to struct's and providing less overt methods for distinguishing which version is on the system. I used to extract the version string from installed libpcap libraries so I could provide the right 'struct pcap' definition. That was the method that tcpdump used many years ago. That is not as fruitful now because, there are conditional compile statements in critical structs, so that even if you know the version, you still don't know what the structure layout is. Having access to the actual definition of 'struct pcap' that is being used by the system would solve all my problems, but that doesn't seem to be in the cards. Why is all of this important? Because you guys still have unwanted behaviors in your routines. pcap_setfilter() is a perfect example. A huge side effect of pcap_setfilter() is that it tries to load the filter into the kernel. Sounds like a great idea, unless you've already loaded a filter into the kernel and you want libpcap to use a different one, or you want to change the filter in-between each packet. The next packet I want to filter has already been read and passed the kernel filter, so poking a new filter down into the kernel will not help at all. But I doubt that you guys will ever put in support for double and triple filtering. No problem, as long as I can poke my own filter into the 'struct pcap' without the library trying to poke it into the kernel. Without pcap-int.h, currently that is impossible. And that's just filters, there are a lot of issues when it comes to reading packets. Many routines in libpcap are great and I use them extensively. A lot of routines in libpcap are not quite what I want and so I replace them with my own. When I can't replace them, its important to have knowledge of what libpcap is doing. As an example, on linux there are conditions where the interface can revert to 'cooked' mode, possibly without the user's intention. Cooked mode adds some significant overhead that may not be appropriate. How can I find out if the interface has reverted to cooked mode without the 'struct pcap'? I don't think its possible. And these are pretty minor issues. Hanging multiple interfaces on multiple selects, scheduling them if you will in SMP architectures seems to beg for pcap_md indictors that are not currently available using the standard libpcap library. That doesn't mean we can't use the existing libpcap library, it just means that one or two minor routines need adjustment or we need access to some part of the 'struct pcap'. For instance, its nice to grab the device name from the 'struct pcap' on the fly. But that requires access to pcap_md struct. I may want to swap packet handlers on the fly, but what is the state of the read buffer? What if I want to use my own interface close routine, one that does something stupid, like send a syslog() message with each close? Don't I have to have follow the p->md.next pointer to get all the possible interfaces? How do I get to that pointer today? Libpcap is a great collection of sub-routines. It is a better collection of sub-routines when the internal structures are available. If you guys don't want to make it easy, by providing pcap-int.h, then at least give us a version number so we can derive pcap-int.h on our own. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 [EMAIL PROTECTED] Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: Michael Richardson [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 06, 2002 7:19 PM > To: [EMAIL PROTECTED] > Cc: 'Guy Harris'; [EMAIL PROTECTED] > Subject: Re: [tcpdump-workers] RedHat and debian do not have > pcap-int.h > > > > >>>>> "Carter" == Carter Bullard <[EMAIL PROTECTED]> writes: > Carter> Hey Guy, All versions of Unix provide include > files that contain > Carter> structures that are intended solely for the > kernel itself. These > Carter> internal structures are distributed, not for the > casual user to > Carter> use, but rather to satisfy a greater set of motives; > Carter> completeness, education/reference, debugging > support and the rare > > Yes. And you are free to install pcap-int.h into your > /usr/include if you like. Or complain to your distro that > they should. No other OS has this either. > libpcap never installed it ever. What makes you think differently? > > Every Unix also provides several hundred system calls, not > to mention /proc, /kern, /dev, ioctl(), setsockopt() so that > every application doesn't have to grovel /dev/kmem to get > info. So you suggest that we get rid of all of this? > > Carter> I think libpcap could benefit from this simple approach. > > I guess you haven't dealt with versioning of shared > libraries. (or Windoz DLL rot). > > If you always build code in statically, no problem. > Otherwise, you need well defined interfaces. Sorry, but > that's the way it works. > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] [EMAIL PROTECTED] > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > panic("Just another NetBSD/notebook using, kernel hacking, > security guy"); [ > > - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
