On Apr 12, 2004, at 2:25 AM, Darren Reed wrote:
In some email I received from Guy Harris, sie wrote:On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote:And there's also BPF_MAXBUFFERSIZE. I see pcap_getbuff() as being essential to getting code to work without trial and error by passing different sizes to read() to find out what the right size to read is, if you're not setting the size yourself.
But if you're using libpcap, you're not passing anything to read(), you're letting libpcap do that.
Not necessarily.
The interface exposed by libpcap is not conducive to good use by C++ applications - main culprit here is pcap_dispatch() but none of the others really help. Unless all your classes are static classes (which kind of defeats the purpose, in my book.)
So whilst pcap is good for discovering interfaces and setting up the sniffing, I've been forced to use pcap_fileno() and read(2) in order to get the application design I want. Using pcap_next() is too slow on BSDs where you can get multiple packets per read
So that presumably also applies to "pcap_next_ex()" - which was introduced on a platform (Win32/WinPcap) where you can get multiple packets per read.
(on Linux, it is fine.)
...but is "read()" fine on Linux? :-)
I.e., if you're using "read()", you're already not portable, unless you are, in effect, re-implementing the dispatch loop for all platforms. If your code knows what platform it's using, it could also know to do the BIOCGBLEN ioctl.
Also, I don't believe that the interfaces provided by pcap provide for a slimmed down read execution path.
What different interfaces would you suggest?
Maybe not...what I am envisaging, here, is between the pcap_open() and the pcap_startlive(), a program can interact with BPF to find out what capabilities it has, what buffer size it will accept, etc, before turning the tap of packets on.
Well, turning the tap of packets on involves binding to the BPF device -
and you currently can't set the buffer size once you've bound to a
device.
Well then, maybe we need to give some thought to what we would like in terms of useful BPF device behaviour, including being able to "turn the tap off" (without closing) or similar ?
...and some thought to whether the "open" and "turn the tap on" split can be implemented on other platforms.
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.