Hey Guy, Well, I've given you 4 reasons why I currently use pcap-int.h, and I suspect that if I gave you 10 more it still won't be compelling for you. So, I'll simply require my users to download and compile a new version of libpcap, regardless of whether there is one already installed on the system. That is probably a better approach to software design and maintenance anyway, since libpcap will be changing so much between releases.
A simple solution. 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Guy Harris > Sent: Monday, May 06, 2002 11:51 PM > To: Carter Bullard > Cc: 'Michael Richardson'; [EMAIL PROTECTED] > Subject: Re: [tcpdump-workers] RedHat and debian do not have > pcap-int.h > > > On Mon, May 06, 2002 at 10:13:51PM -0400, Carter Bullard wrote: > > 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, > > "md" stands for "machine-dependent"; libpcap is supposed to provide a > machine-*independent* interface to packet capture mechanisms. > > If you don't care about machine-independence, perhaps the > right thing to do is to directly use the native packet > capture mechanism. > > > 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. > > "Access" in the sense that you had it in the source, *not* in > the sense that it was in the system include directories. > > > 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. > > Well, yeah, that's what it's *supposed* to do, on systems > that do filtering in 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, > > I infer from those two sentences that by "want libpcap to use > a different one" you mean that you want the kernel filter to > be in effect > *and* you want an additional user-mode filter to be in effect. > > If so, why not do the filtering outside of libpcap? Libpcap > currently only has the notion of one filter being in effect; > it puts that into the kernel, if possible, and otherwise does > it in userland. > > > or you want to change the filter in-between each packet. > > Well, "changing the filter in between each packet" in the > kernel is a bit tricky, given that packets arrive while > you're doing that. > Presumably you can do that outside libpcap. > > > 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. > > Umm, why do you *need* to poke it into the "struct pcap"? > Putting it there won't cause libpcap to use it; why not, > well, just do the filtering in userland, by calling > "bpf_filter()" directly? > > > 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. > > What libpcap does is subject to change between releases. > > > 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. > > If you know the interface is running in cooked mode, what > would your code do differently? > > The reason why we fall back to cooked mode ("revert to" could > be viewed as indicating that this happens at arbitrary points > in the capture process; that is not the case) is that, for > some link-layer types on Linux, either > > 1) the driver hides the link-layer header, so that the *only* > way to find out, for example, the payload type above the link > layer (e.g., IP, IPX, etc.) is to run in cooked mode; > > 2) the driver hands you random crap as the link-layer header, so > that you have *no idea* what's in the link-layer header, or > how large it is; > > so what would your program do if libpcap *weren't* using cooked mode? > > > 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. > > How so? > > Note that, if those indicators provide information that's not > currently available, that would be because they don't > *exist*, in which case exposing the "pcap_md" structure > wouldn't help.... > > > 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. > > Or a "pcap_get_devname()" routine. Accesss to the "pcap_md" > structure would give you the device name *only on Linux*, > because the *only* reason it's kept around is to let us muck > with interface flags to work around a botch in the > SOCK_PACKET capture mechanism (which indicates that we don't > even need to set that field if PF_PACKET sockets rather than > PF_INET/SOCK_PACKET sockets are being used). > > > I may want to swap packet handlers on the fly, but what is > the state > > of the read buffer? > > "Packet handlers" in what sense? > > > What if I want to use my own interface close routine, one that does > > something stupid, like send a syslog() message with each close? > > What do you mean by "interface close routine"? A wrapper > around "pcap_close()"? A replacement for "pcap_close()"? A > routine to close > *all* the interfaces? > > > Don't I have to have follow the p->md.next > > pointer to get all the possible interfaces? > > "p->md.next" is *NOT* a list of "all the possible interfaces". > > It's a list of all the interfaces, *on a Linux system*, that > are opened with SOCK_PACKET sockets, in promiscuous mode. > That is exactly what it is *intended* to be; it's there > *solely* as a workaround for misfeatures of SOCK_PACKET > sockets - misfeatures fixed by the PF_PACKET mechanism in the > 2.2 and later kernels. > > If you want a list of *all* the open interfaces, "p->md.next" > is *not* guaranteed to be that, and you should *not* use it as such. > > If your code is the only code that opens interfaces that you > care about, you should maintain the list yourself. > > If your code is *not* the only code that opens interfaces > that you care about, so that you *can't* maintain the list > yourself, this would require changes to libpcap to maintain > such a list, as it's not maintained on *any* platform right now. > > > Libpcap is a great collection of sub-routines. It is a better > > collection of sub-routines when the internal structures are > available. > > I am not yet convinced that making the internal structures > available would make it better. (In fact, if they're > available, they're no longer internal structures!) > > In the case of "pcap_setfilter()", I'm not convinced that you > need to get at the structure at all. > > In the case of the cooked mode flag, you haven't yet shown > that your code can do anything *with* that flag's value, by > showing what it > *would* do with the flag's value. > > In the case of the indicators in the pcap_md structure for > SMP, you haven't indicated what those indicators would do, or > even that they > *exist* at present. > > In the case of getting the device name on the fly, that can > be done with a routine (and would require code changes > *anyway*, as it's not maintained on platforms other than Linux). > - > This is the TCPDUMP workers list. It is archived at > http://www.tcpdump.org/lists/workers/index.htm> l > To > unsubscribe use > mailto:[EMAIL PROTECTED]?body=unsubscribe > > - 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
