summaryrefslogtreecommitdiff
path: root/pcap.h
Commit message (Collapse)AuthorAgeFilesLines
* remove libpcap's own CVS keywordsDenis Ovsienko2014-01-031-2/+0
| | | | | | This change removes CVS keywords that express that the file belongs to libpcap repository. All such keywords represented the revision and timestamp by the end of 2008 or even older.
* Put the public libpcap headers into a pcap subdirectory in both theguy2006-10-041-287/+8
| | | | | | | | source directory and the target include directory, and have include files at the top-level directory to include those headers, for backwards compatibility. Update the FILES and INSTALL.txt files to reflect current reality.
* Clean up some comments, and give more details so people understand whatguy2006-02-091-4/+11
| | | | | they do, and don't, have to do about 32-bit vs. 64-bit platforms in libpcap.
* OK, we'll be putting out 0.9.2 soon, so add the API changes back inguy2005-07-071-6/+6
| | | | again.
* 0.9's already been released, so, for better or worse, we're stuck withguy2005-07-051-6/+6
| | | | the old names.
* Rename "direction_t" to "pcap_direction_t", and rename "D_IN" andguy2005-07-051-6/+6
| | | | | "D_OUT" to "PCAP_D_IN" and "PCAP_D_OUT", to avoid potential namespace collisions, as per a suggestion by Dean Gaudet.
* Add a "pcap_dump_ftell()" routine, to fetch the current offset of aguy2005-06-031-2/+3
| | | | | | | | | pcap_dumper_t. (Just doing an "ftell()" on the result of "pcap_dump_file()" won't necessarily work on Windows, as Microsoft, in their infinite wisdom, have multiple different versions of the C library runtime, and if a DLL is built using one version, and another DLL or an executable is built with another version, file descriptors and FILE *'s opened in one of them cannot be used in the other.)
* From Pawel Pokrywka: add support for requesting that only receivedguy2005-05-031-1/+8
| | | | | | | packets, only sent packets, or all packets be accepted, with an implementation for Linux. Add an implementation for BPF platforms that support BIOCSSEESENT.
* From Gisle Vanem: MS-DOS support.guy2004-12-181-11/+59
|
* From Chris Lightfoot <cwrl@users.sourceforge.net>: addguy2004-11-071-1/+3
| | | | | | | | | | "pcap_dump_fopen()" to open a pcap_t given a FILE *, and add "pcap_dump_fopen()" to open a pcap_dumper_t given a FILE *. On Windows, if we're opening the standard input, put it in binary mode. Check for errors from "sf_write_header()" and return an error if we get an error.
* Add support for sending packets; includes contributions from Markguy2004-03-231-2/+3
| | | | Pizzolato <List-tcpdump-workers@subscriptions.pizzolato.net>.
* Added the definition of MOD_MON, required by WinPcap to work properly with ↵risso2004-01-271-1/+2
| | | | some applications
* Add a "pcap_get_selectable_fd()" API to get an FD on which you can do aguy2003-11-211-1/+8
| | | | "select()" or "poll()" - or -1 if that won't work.
* Add "pcap_datalink_val_to_description()", which returns, for a DLT_guy2003-11-181-1/+2
| | | | | | type, a short description intended for humans. Fix up some man page typoes.
* Add a "pcap_dump_file()" API to get the "FILE *" corresponding to aguy2003-11-161-1/+2
| | | | "pcap_dumper_t".
* Add a "pcap_breakloop()" API to break out of the loop inguy2003-11-041-1/+2
| | | | "pcap_dispatch()" and "pcap_loop()".
* Add a prototype for "pcap_next_ex()", to squelch compiler complaints,guy2003-04-101-1/+2
| | | | and to make it available to applications using it.
* Add a "pcap_lib_version()" routine to return a version string forguy2003-02-111-1/+3
| | | | | | | | | | | | | | libpcap; it generates the string at run time on the first call, so that it's not a constant string - in at least some UNIXes, constant data in a shared library is kept separate from the library code, and is bound into applications linked with that library at link time, not at run time, so a constant string (such as "pcap_version[]") can reflect the version of the library with which the application was built, not the version with which it's running. Document it, in the hopes that vendors will be less likely to omit it from their libpcaps (unlike "pcap_version[]", which is absent from some vendors' libpcaps).
* From Shaun <delius@progsoc.uts.edu.au>: on AIX, load the BPF driver andguy2003-02-111-2/+4
| | | | | | | | | | create the BPF device nodes if necessary, and rename our "bpf.h" to "pcap-bpf.h" and install it in "/usr/include", so that "pcap-bpf.c" gets the system's bpf.h file if it includes <net/bpf.h> - on AIX, it needs to get an AIX-specific structure from that header in order to support loading the driver and creating the nodes. Update "packaging/pcap.spec".
* Make "pcap_dump_flush()" return a success-vs-failure indication;guy2002-12-221-2/+2
| | | | | | | | unfortunately, we can't fix "pcap_dump()" and "pcap_dump_close()" to do that, as any application that tests the return value would fail to work correctly if linked at runtime with an older libpcap, but we should perhaps introduce "pcap_dump_ex()" and "pcap_dump_close_ex()" routines that do return a success-vs-vailure indication.
* From Yoann Vandoorselaere <yoann@prelude-ids.org>: make the "device"guy2002-12-221-3/+3
| | | | | | | argument to "pcap_open_live()" a "const" pointer. Constify some additional device name arguments, and update the man page to reflect some arguments that were already consts.
* From Andrew Brown <atatat@atatdot.net>: add a "pcap_dump_flush()" call,guy2002-12-211-1/+2
| | | | | to flush the standard I/O buffer for a "pcap_dumper_t" and force all packets written with "pcap_dump()" to the savefile.
* NetBSD support for multiple data link types on an interface, from Davidguy2002-12-191-1/+5
| | | | | | | | | | | | Young <dyoung@ojctech.com>, with some minor changes by Jason R. Thorpe <thorpej@netbsd.org>, and further changes by me to support it on BPF systems lacking BIOCGDLTLIST and other platforms lacking an equivalent feature. Update Jason Thorpe's e-mail address (Zembu is going away, if it hasn't done so already). Add APIs to map DLT names to DLT values and vice versa.
* Use <pcap-stdinc.h> only on Windows; on UNIX, selectively include, inguy2002-08-021-1/+6
| | | | | | | | | | | | | | | | | | | | | | each source file, only the headers that file needs, and all the headers it needs in order to compile on various platforms and not to get any avoidable compiler warnings on those platforms (as well as any incomplete structure definitions needed to avoid those warnings). That also means that <pcap.h> doesn't include <pcap-stdinc.h> on UNIX; we don't want it to include <pcap-stdinc.h>, at least on UNIX, as doing so 1) would mean we'd have to install that, so that programs can build with libpcap and 2) would mean that programs including <pcap.h> would drag in a bunch of header files that they don't need. Put a newline at the end of "inet.c" - the Sun C compiler doesn't like it if the last line doesn't end with a newline.
* Added support for Win32, based on WinPcap.risso2002-08-011-3/+25
|
* Make "flags" in a "struct pcap_if" a "bpf_u_int32", as requested byguy2002-07-201-2/+2
| | | | Fulvio Risso.
* Add APIs to put a "pcap_t" into or out of non-blocking mode, and to getguy2001-12-091-1/+3
| | | | | | | | | | the current state of non-blocking mode; this allows us to implement, for example, memory-mapped capture devices, where "pcap_read()" uses "select()" or "poll()" to wait for packets to arrive, and hide that implementation detail from applications using this API ("pcap_setnonblock()" would set or clear a non-blocking mode flag in the "pcap_t", and the "select()" or "poll()" would not be done if the "pcap_t" is in non-blocking mode).
* Make the "is_loopback" field of a "pcap_if" structure a general "flags"guy2001-10-281-2/+4
| | | | | | | field, and make a PCAP_IF_LOOPBACK flag be the first flag bit in that field, specifying whether the interface is a loopback interface; this allows us to add more flags without changing the layout of the structure.
* From Scott Gifford:guy2001-10-081-1/+29
| | | | | | | | | | | | | | | | | Add a new "pcap_findalldevs()" routine to get a list of all interfaces that can be opened with "pcap_open_live()", and a "pcap_freealldevs()" routine to free the list. Make "pcap_lookupdev()" use it, which also arranges that it will not return a device that cannot be opened by "pcap_open_live()". Allow the "any" device to be opened, on Linux, with "promisc" non-zero; ignore the request for promiscuity, and return a warning message indicating that promiscuous mode isn't supported on the "any" device. Document "pcap_findalldevs()" and "pcap_lookupdev()", and clean up some items in the libpcap man page.
* When attaching a "bpf_program" to a "pcap_t" to use as a userlandguy2000-10-281-2/+2
| | | | | | | | | | | | | | filter, always attach a copy, as "pcap-linux.c" does; that way, after a program uses "pcap_setfilter()", it can safely use "pcap_freecode()" to free up the BPF instructions allocated by "pcap_compile()". Also, always free it up when the "pcap_t" is closed. Get rid of the "pcap_t *" argument to "pcap_freecode()", as it's not necessary. Document "pcap_freecode()", for the benefit of programs that might repeatedly compile filter programs and attach them, so that they can free them up after attaching them and avoid leaking memory for them.
* The Linux "pcap_setfilter()" makes a copy of the filter it's handed, andguy2000-10-251-3/+2
| | | | installs that copy; when closing a pcap_t on Linux, free that copy.
* In addition to telling people not to change the format of the savefileguy2000-10-121-3/+10
| | | | | | header without getting a new magic number from us, tell them not to change the interpretation of any fields in the header without getting a new magic number from us.
* Get rid of the PCAP_ENCAP_ values - if an application uses them, thatguy2000-10-121-90/+2
| | | | | | | | | | | | | | | | | | application won't build with any other version of libpcap, which means that a lot of applications won't use them. In addition, "pcap_linktype()" needs to return DLT_ values, so that platforms that build libpcap as a shared library won't break binary compatibility if they update to this version of libpcap. Instead, we map from DLT_ values to LINKTYPE_ values when writing savefiles, and map from LINKTYPE_ values to DLT_ values when reading savefiles, so that savefiles don't have platform-dependent DLT_ values in the header as the link type, they have platform-independent LINKTYPE_ values. This means we don't need to make DLT_ATM_RFC1483, DLT_RAW, etc. have platform-independent values starting at 100 - only the values in the savefile header need to be like that.
* Add support for NetBSD DLT_PPP_SERIAL (PPP in HDLC-like framing, as perguy2000-09-181-1/+13
| | | | | | | RFC 1662, or Cisco point-to-point with HDLC framing, as per seciont 4.3.1 of RFC 1547; there's always an address and control octet at the beginning of these packets, but they're not necessarily 0xff 0x03), which we map to PCAP_ENCAP_PPP_HDLC.
* Introduce a set of PCAP_ENCAP_ codes to specify packet encapsulations.guy2000-09-171-2/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For those PCAP_ENCAP_ codes corresponding to DLT_ codes that are (believed to be) the same in all BSDs, the PCAP_ENCAP_ codes have the same values as the corresponding DLT_ codes. For those PCAP_ENCAP_ codes corresponding to DLT_ codes that were added in libpcap 0.5 as "non-kernel" DLT_ codes, or had their values changed in libpcap 0.5 in order to cope with the fact that those DLT_ codes have different values in different systems, the PCAP_ENCAP_ codes have the same values as the corresponding DLT_ codes. We add some additional PCAP_ENCAP_ codes to handle IEEE 802.11 (which currently has its link-layer information turned into an Ethernet header by at least some of the BSDs, but John Hawkinson at MIT wants to add a DLT_ value for 802.11 and pass up the full link-layer header) and the Classical IP encapsulation for ATM on Linux (which isn't always the same as DLT_ATM_RFC1483, from what I can tell, alas). "pcap-bpf.c" maps DLT_ codes to PCAP_ENCAP_ codes, so as not to supply to libpcap's callers any DLT_ codes other than the ones that have the same values on all platforms; it supplies PCAP_ENCAP_ codes for all others. In libpcap's "bpf/net/bpf.h", we define the DLT_ values that aren't the same on all platforms with the new values starting at 100 (to keep them out of the way of the values various BSDs might assign to them), as we did in 0.5, but do so only if they're not already defined; platforms with <net/bpf.h> headers that come with the kernel (e.g., the BSDs) should define them with the values that they have always had on that platform, *not* with the values we used in 0.5. (Code using this version of libpcap should check for the new PCAP_ENCAP_ codes; those are given the values that the corresponding DLT_ values had in 0.5, so code that checks for them will handle 0.5 libpcap files correctly even if the platform defines DLT_RAW, say, as something other than 101. If that code also checks for DLT_RAW - which means it can't just use a switch statement, as DLT_RAW might be defined as 101 if the platform doesn't itself define DLT_RAW with some other value - then it will also handle old DLT_RAW captures, as long as they were made on the same platform or on another platform that used the same value for DLT_RAW. It can't handle captures from a platform that uses that value for another DLT_ code, but that's always been the case, and isn't easily fixable.) The intent here is to decouple the values that are returned by "pcap_datalink()" and put into the header of tcpdump/libpcap save files from the DLT_ values returned by BIOCGDLT in BSD kernels, allowing the BSDs to assign values to DLT_ codes, in their kernels, as they choose, without creating more incompatibilities between tcpdump/libpcap save files from different platforms.
* Add comments telling people not to gratuitously change the capture fileguy2000-09-141-1/+22
| | | | | | | | | | | | | format (file header or per-packet header format, or interpretation of any of the fields in those headers) without getting a new magic number from "tcpdump-workers@tcpdump.org", and to make sure that libpcap can still read files with the existing magic numbers, not just files with the new magic number and record formats. (There have been at least three libpcap changes I know of that have changed the header formats, or the interpretation of fields in those headers, without changing the magic number. I would like not to ever have any other such changes happen ever again.)
* Pick up, from the FreeBSD libpcap, changes to surround all declarations withguy2000-07-291-1/+10
| | | | | | | | | | | | | | | #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif so that C++ code can include these header files and correctly call the C-language routines they declare.
* (pcap_open_dead, bpf_validate, bpf_dump): addassar2000-06-261-1/+4
|
* This adds a new function that allows using the bpf compiler withoutmcr1999-12-081-1/+3
| | | | | | | having a pcap open. One could argue that this and the existing compiler should be factored in common routines, but I was trying to make it clear that this wouldn't break the existing code. from Greg Troxel <gdt@ir.bbn.com>
* Initial revisionmcr1999-10-071-0/+137
View Lorry Controller Status