Re: [WinPcap-users] snaplen only works when BPF is set ?
Guy Harris wrote: At least on the original systems where BPF was implemented, the snapshot length was supplied by the BPF program; the return instruction in BPF includes a snapshot length value, which, if zero, means discard this packet. On those systems, you need a BPF program to supply a snapshot length. The WinPcap driver might follow that model, in which case you'd see that behavior, just as you would, for example, on various BSD systems. Well, I definitely saw it on one BSD system (Mac OS X), and have checked in a fix for BPF systems... On other systems, that's not the case. Perhaps libpcap should, when opening a device, install, on systems where the snapshot length comes from a BPF program, an initial BPF program that consists only of a return instruction with the specified snapshot length. ...which does exactly that. A similar thing could be done in the WinPcap support code. == This is the WinPcap users list. It is archived at http://www.mail-archive.com/winpcap-users@winpcap.polito.it/ To unsubscribe use mailto: [EMAIL PROTECTED] ==
Re: [WinPcap-users] snaplen only works when BPF is set ?
phengmaly peter wrote: It seems to me, that the pcap_open_live's snaplen argument has only effect when a BPF filter is set thereafter (pcap_setfilter). Is it the intended functionality ? (both 3.0 and 3.1b4) At least on the original systems where BPF was implemented, the snapshot length was supplied by the BPF program; the return instruction in BPF includes a snapshot length value, which, if zero, means discard this packet. On those systems, you need a BPF program to supply a snapshot length. The WinPcap driver might follow that model, in which case you'd see that behavior, just as you would, for example, on various BSD systems. On other systems, that's not the case. Perhaps libpcap should, when opening a device, install, on systems where the snapshot length comes from a BPF program, an initial BPF program that consists only of a return instruction with the specified snapshot length. == This is the WinPcap users list. It is archived at http://www.mail-archive.com/winpcap-users@winpcap.polito.it/ To unsubscribe use mailto: [EMAIL PROTECTED] ==
Re: [WinPcap-users] snaplen only works when BPF is set ?
Guy Harris wrote: phengmaly peter wrote: It seems to me, that the pcap_open_live's snaplen argument has only effect when a BPF filter is set thereafter (pcap_setfilter). Is it the intended functionality ? (both 3.0 and 3.1b4) At least on the original systems where BPF was implemented, the snapshot length was supplied by the BPF program; the return instruction in BPF includes a snapshot length value, which, if zero, means discard this packet. On those systems, you need a BPF program to supply a snapshot length. The WinPcap driver might follow that model, in which case you'd see that behavior, just as you would, for example, on various BSD systems. Yes, I confirm that the winpcap driver follows that model. On other systems, that's not the case. Perhaps libpcap should, when opening a device, install, on systems where the snapshot length comes from a BPF program, an initial BPF program that consists only of a return instruction with the specified snapshot length. This is a good idea, but I'd leave it for the next winpcap release. We are sort of freezing the development to focus on fixing the last bugs in 3.1, so I'd prefer not to change the interface with libpcap now. The same applies to the user buffer not emptied after a setfilter problem. Loris == This is the WinPcap users list. It is archived at http://www.mail-archive.com/winpcap-users@winpcap.polito.it/ To unsubscribe use mailto: [EMAIL PROTECTED] ==
