On Jan 6, 2008, at 12:54 PM, Guy Harris wrote:
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring
if a PF_RING socket were being used? That'd avoid some per-packet
checks in the read_op routine, and might involve fewer #ifdefs as
well.
For that matter, should there be a separate live_open_pf_ring()
routine, with that routine called first and, if it fails (e.g.,
because the system doesn't have PF_RING support), live_open_new()
called? From a quick look at the libpfring code, at least some of the
code path in live_open_new() that appears to be used with PF_RING
doesn't need to be, such as the code to use the PACKET_ADD_MEMBERSHIP
socket option to turn promiscuous mode on.
(Speaking of which, again, from looking at the libpfring code, it
appears that it uses the old SIOCGIFFLAGS/SIOCSIFFLAGS mechanism for
controlling promiscuous mode; to quote a comment early in pcap-
linux.c, explaining the problems with the old PF_INET/SOCK_PACKET
sockets:
* - We have to set the interface's IFF_PROMISC flag ourselves, if
* we're to run in promiscuous mode, which means we have to turn
* it off ourselves when we're done; the kernel doesn't keep track
* of how many sockets are listening promiscuously, which means
* it won't get turned off automatically when no sockets are
* listening promiscuously. We catch "pcap_close()" and, for
* interfaces we put into promiscuous mode, take them out of
* promiscuous mode - which isn't necessarily the right thing to
* do, if another socket also requested promiscuous mode between
* the time when we opened the socket and the time when we close
* the socket.
Is there a way to use a mechanism such as the PACKET_ADD_MEMBERSHIP
socket option with PF_RING sockets, and, if so, will the socket keep
track of both PF_PACKET and PF_RING sockets, and shut promiscuous mode
off only if *neither* of those types of sockets are using promiscuous
mode?)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
