aboutsummaryrefslogtreecommitdiff
path: root/pcap-linux.c
Commit message (Collapse)AuthorAgeFilesLines
...
* DLT_LINUX_SLL2 support.Guy Harris2018-07-121-87/+319
|
* Rename pcap_set_protocol() to pcap_set_protocol_linux().Denis Ovsienko2018-07-111-1/+1
| | | | | As discussed on tcpdump-workers: emphasize the fact this function is Linux-specific.
* Loopback devices aren't wireless and aren't connected/disconnected.Guy Harris2018-04-301-0/+9
|
* find_or_add_if() needs to be passed get_if_flags() as well.Guy Harris2018-04-301-1/+2
|
* Don't do anything with pathstr if we don't need it.Guy Harris2018-04-301-2/+4
| | | | | Declare it in the if() arm where it's used, and free it before we exit that arm.
* Pass the "get additional flags" function to the findalldevs helpers.Guy Harris2018-04-301-2/+3
| | | | | This lets us make it a static function - or eliminate it entirely for pcap-null.c.
* Fix build errors.Guy Harris2018-04-291-3/+4
|
* Fix build problems.Guy Harris2018-04-291-2/+11
| | | | Protect against particular ARPHRD_ values not being defined.
* Add more interface flags to pcap_findalldevs().Guy Harris2018-04-291-1/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We add: PCAP_IF_WIRELESS, which indicates whether the interface is "wireless" or not. PCAP_IF_CONNECTION_STATUS, which is a bitmask for a two-bit field that can have one of the values: PCAP_IF_CONNECTION_STATUS_UNKNOWN if the status of whether the interface is "connected" or "disconnected" is unknown; PCAP_IF_CONNECTION_STATUS_CONNECTED if the interface is "connected"; PCAP_IF_CONNECTION_STATUS_DISCONNECTED if the interface is "disconnected"; PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE if the notion of "connected" or "disconnected" doesn't apply to this interface. Take that into account when sorting interfaces in the interface list, penalizing "disconnected" interfaces, as you won't see traffic on them if they're not wireless and you'd have to be in some form of "monitor mode" to see traffic on them if they're wireless. This should address GitHub issue #700.
* Clean up the VLAN information handling.Guy Harris2018-04-061-24/+68
| | | | | | | | | | | | | | | | | | | | | | | | | Define a macro to test whether we think a packet has VLAN information, and explain why the test is what it is (VLAN TCI != 0 or TP_STATUS_VLAN_VALID flag set in tp_status). If TP_STATUS_VLAN_VALID isn't defined, test the 0x10 bit (as that's how TP_STATUS_VLAN_VALID is defined in 3.0 and later), so that if we compile this on a system whose headers don't define TP_STATUS_VLAN_VALID (pre-3.0 kernel headers) and run it on a system that has TP_STATUS_VLAN_VALID (3.0 and later kernel), we'll test that flag. In the non-memory-mapped path, make sure we fill in the aux_data structure; that should fix Coverity CID 1430309. Set the "VLAN information present flag" to 0 or 1; that's what the BPF code that's generated to test the flag expects. Set the aux_data structure members in order - "VLAN information present" flag first, VLAN tag next. Clean up indentation. Add some more comments.
* Fix a set of trivial unused warningsJoerg Mayer2018-04-041-1/+1
|
* Use AC_CHECK_TYPES and AC_CHECK_MEMBERS.Guy Harris2018-01-201-14/+14
| | | | | | | | | Rather than rolling our own autoconf macros to test for the existence of data types and structure members, use AC_CHECK_TYPES and AC_CHECK_MEMBERS. That cleans the configure script code up a bit, and makes it a bit more like the CMakeLists.txt file.
* Fix a half-converted error message formatting call.Guy Harris2017-11-151-1/+1
|
* Add a routine to format error messages with an errno-based message at the end.Guy Harris2017-11-151-176/+166
| | | | | | | | | | | | | | That routine will use strerror_s() or strerror_r() if available, in a fashion that's thread-safe. Otherwise, it falls back on pcap_strerror(). Use it in both libpcap and rpcapd. Given that we check for errors in strerror_r(), hopefully this will squelch warnings with newer version of GCC and GNU libc; whilst the macOS (and other BSD-flavored?) strerror_r() always fills in a message, that's not required by the Single UNIX Specification, as far as I can tell, so we apparently really *do* need to check for errors.
* No need to generate version.c or pcap_version.h.Guy Harris2017-10-031-2/+0
| | | | We can get the project version from config.h, so do so.
* Push pcap_lib_version() into the pcap-XXX.c files.Guy Harris2017-09-061-15/+17
| | | | | | | | This lets us move the Windows version to pcap-win32.c, so we don't have to include packet32.h in pcap.c. It also gets rid of some #ifdefs, and lets us construct the version string on UN*X platforms, and MS-DOS, at compile time.
* Merge pull request #595 from buytenh/pcap_protocolGuy Harris2017-08-241-9/+29
|\ | | | | Add pcap_set_protocol() to allow specifying a specific capture protocol.
| * Add pcap_set_protocol() to allow specifying a specific capture protocol.Lennert Buytenhek2017-08-211-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the Linux-specific pcap_set_protocol(), which allows you to specify a specific protocol to be captured. A protocol value specified with this function will be used instead of ETH_P_ALL when creating and binding a packet socket. For ethernet packets, a similar result can be achieved by explicitly creating a BPF filter that filters on ethertype and attaching that filter to the packet socket, however, filtering using the packet socket protocol field is slightly more efficient. Also, in some cases, the packet socket protocol field and the ethertype field have different values, and in those cases it is impossible to achieve the same result by using a BPF filter. An example of this is on Arista platforms, where sFlow-sampled packets are delivered, unmodified, to virtual interfaces on the management CPU with their packet socket protocol value set to the magic value 0x002d, independently of their actual ethertype.
* | Consistently use handle as the pointer to the pcap_t.Guy Harris2017-08-211-5/+5
| | | | | | | | Use handle as the pcap_t pointer in all functions.
* | Always include <config.h> rather than "config.h".Guy Harris2017-08-181-1/+1
| | | | | | | | | | | | | | | | This can prevent bizarre failures if, for example, you've done a configuration in the top-level source directory, leaving behind one config.h file, and then do an out-of-tree build in another directory, with different configuration options. This way, we always pick up the same config.h, in the build directory.
* | Add link-layer header type for Linux vsock.Gerard Garcia2017-07-061-0/+7
|/ | | | | | | | | | | | Linux 4.12 has the vsockmon kernel module for AF_VSOCK packet capture. AF_VSOCK is used for host<->guest communication between a hypervisor and virtual machines. It is supported by VMware and KVM. Traffic can be captured as follows: # modprobe vsockmon # ip link add type vsockmon # ip link set vsockmon0 up
* Make the checks and adjustment of the snapshot length module-dependent.Guy Harris2017-06-011-0/+11
| | | | | | | | | | | | | Also, initialize the snapshot length to 0, meaning "not specified", so that the default snapshot length, if not specified, is also module-dependent. That way, D-Bus has a maximum and default of 128MB, as that's the maximum message size, but other capture devices have the current MAXIMUM_SNAPLEN, so we can handle full-size D-Bus messages without advertising an overly-large snapshot length for other devices, potentially causing libpcap and programs using it or reading libpcap files to allocate overly-large buffers for other capture devices.
* Shorten the version string and give only the best TPACKET version.Guy Harris2017-05-161-4/+4
|
* Allow a platform to add information to the version string.Guy Harris2017-05-161-0/+19
| | | | | For example, on Linux, we add information about memory-mapped capture support; see comments on GitHub issue #600.
* bound snaplen for linux tpacket_v2 to ~64kPaolo Abeni2017-05-111-17/+25
| | | | | | | | | | | | | | | | | | | | | | | The aggregated ethernet packets produced by the linux kernel can't exceed 65535 (plus eth overhead), so we can bound accordingly the snaplen for tpacket_v2 on such devices. This allows a more efficient usage of the receive buffer; tcpdump has increased the default snaplen up to 256K in recent versions, to cope better with USB data, and that leads to tpacket_v2 rx ring being configured by default with tp_frame_nr equal to 7, which is very bad for most use-case. With this change the default tpacket_v2 layout has tp_frame_nr equal to 32, which is still quite low, but works much better and is consistent with the previous tcpdump behavior. v1 -> v2: update the comment to better reflect the current status, code cleanup Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* Fix length of DLT_ list.Guy Harris2017-04-101-1/+1
| | | | There are 3 entries in the list provided for ARPHRD_FCFABRIC, not 2.
* Support setting non-blocking mode before activating.Guy Harris2017-02-251-5/+5
| | | | | | | | | | | | | | | | | | We just set a flag and attempt to set non-blocking mode after activating. If a module can't support non-blocking mode, it should set the set non-blocking operator in the create routine, so a pre-activation call will fail the same way a post-activation call fails. While we're at it: Have the get non-blocking and set non-blocking modes not take an error buffer as an argument; they have the error buffer in the pcap_t to set. pcap_getnonblock() and pcap_setnonblock() just copy the error from there to the argument passed in. Make sure we set the cleanup op pointer when appropriate.
* Properly handle interface flags for Linux interfaces in add_linux_if().Guy Harris2017-01-201-1/+1
| | | | | Use a new find_or_add_if() routine that takes IFF_ flags as an argument and maps them to PCAP_IF_ flags.
* Pass IFF_ flags to add_addr_to_iflist().Guy Harris2017-01-181-2/+1
| | | | | | | | It's only used on UN*Xes, so it's only used on systems that have IFF_ flags; have add_addr_to_iflist() do the mapping to PCAP_IF_ flags. That restores the workaround for systems lacking IFF_LOOPBACK and the "don't even try" for systems lacking IFF_UP or IFF_RUNNING.
* Have a pcap_if_list_t structure for use by the findalldevs code.Guy Harris2017-01-181-8/+8
| | | | | | | It's not part of the API, but it's an internal structure used by the findalldevs code. Currently, it just has a pointer to the beginning of the list, but it could change in order to speed up the process of adding to the list.
* Merge pull request #429 from msekletar/bpf-userland-cookedGuy Harris2017-01-171-2/+8
|\ | | | | bpf: increase snaplen if doing cooked mode userspace filtering
| * bpf: increase snaplen if doing cooked mode userspace filteringMichal Sekletar2015-04-201-2/+8
| | | | | | | | | | | | | | This commit should address the issue when bpf_filter_with_auxdata returned 0 for valid packets because offset in filter exceeded tp_snaplen as returned by kernel. If we filter in cooked mode filter offsets are adjusted because sll_header, we should do the same for snaplen.
* | Round the buffer size up to a multiple of the frame size.Guy Harris2017-01-101-4/+18
| | | | | | | | | | | | | | | | | | | | When calculating the number of frames for the memory-mapped buffer, round the buffer size up to a multiple of the frame size - rather than rounding down, which is what happens by default with a divide, as that could give a buffer smaller than our caller asked for, all the way down to "zero frames" if the buffer size is less than the frame size. Addresses the main problem with GitHub issue #548.
* | Work around a typo in many Linux kernel versions.Guy Harris2017-01-101-1/+4
| | | | | | | | | | | | Kernel versions dating back at least as far as 2.4.20, and at least as far ahead as 2.6.23, returned ENONET, rather than ENOENT, for a SO_DETACH_FILTER where there was no filter present.
* | Ignore ENOENT in reset_kernel_filter().Guy Harris2017-01-101-1/+9
| | | | | | | | | | | | | | | | | | It means "there was no filter on the socket"; as the goal of this routine is to remove whatever filter is on the socket, it means that the goal has been achieved by virtue of there not having been a filter there in the first place, so just return 0, meaning "success". See GitHub issue #549.
* | Clean up findalldevs code.Guy Harris2016-12-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Have a routine that unconditionally adds a device to the list of devices, without bothering to check whether there's already a device with that name, and a separate routine that does the check and, if it doesn't find the device, calls the routine to add ti. That avoids scanning the entire list in cases where we know the search will fail. The only reasons for doing the check are that we're on a platform where we find the list of interfaces by a call that returns a list of *addresses*, with an interface name attached to each address, and 1) for each address, we need to make sure we don't already have the interface, create it if we don't, and add the address to the now-guaranteed-to-exist entry for the interface; 2) we might have to make a *separate* call to enumerate interfaces, to find interfaces with *no* addresses, and that call also enumerates the ones that *do* have addresses, and we don't want to create a duplicate entry for them. Change some findalldevs helper routines to have "dev" rather than "if" in the name, as not all devices are regular network interfaces. For the DAG findalldevs routine, make sure it always provides an error message if it fails. We don't need add_addr_to_iflist() or get_if_description() on Windows, so don't define them on Windows. Update comments to reflect reality.
* | Check for the "break the loop" condition in the inner loop for TPACKET_V3.Guy Harris2016-10-021-1/+1
| | | | | | | | | | Otherwise, if a callback calls pcap_breakloop(), the inner loop won't terminate.
* | Fix handling of packet count in the TPACKET_V3 inner loop.Guy Harris2016-10-021-3/+10
| | | | | | | | | | | | | | | | | | If we were told to process no more than N packets, and we've already processed M packets so far, we should process no more than N-M packets in a buffer; if we stop at N rather than N-M, we could end up processing more than N packets in a pcap_dispatch() call. Fixes GitHub issue #493.
* | Filter out duplicate looped back CAN frames.Guy Harris2016-09-191-0/+16
| | | | | | | | | | | | | | | | | | CAN devices and drivers, and the Linux CAN stack, always arrange to loop back transmitted packets, so they also appear as incoming packets. We don't want duplicate packets, and we can't easily distinguish packets looped back by the CAN layer than those received by the CAN layer, so we discard packets with a packet type "outgoing" and a protocol of CAN or CAN FD.
* | On Linux, handle all CAN captures with pcap-linux.c, in cooked mode.Guy Harris2016-08-251-16/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no need to support capturing on PF_CAN sockets; CAN interfaces show up as regular interfaces on which you can capture with PF_PACKET sockets, so just let pcap-linux.c handle them, and get rid of pcap-can-linux.c. Capture on them in cooked mode, so we get the protocol field and can distinguish between "classic" CAN and CAN FD. The hardware for which pcap-canusb-linux.c was intended never reached production: https://github.com/axos88/libpcap/commit/f3edbb599b8cbcc7e4560000dcba8e992dc11a31#commitcomment-18716617 so we don't need pcap-canusb-linux.c, either. This all removes the need for the "host-endian" link-layer header type; it never made it into a libpcap release, so we just remove it. The "big-endian" link-layer header type is kept for the benefit of packets captured with the old pcap-can-linux.c code; we revert it to its old name.
* | Have separate DLTs for big-endian and host-endian SocketCAN headers.Guy Harris2016-08-181-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least with some versions of the Linux kernel, you can capture on SocketCAN interfaces with a PF_PACKET socket and get packets with SocketCAN headers; that code doesn't special-case ARPHRD_CAN, so it leaves the CAN ID field in host byte order. In addition, the "capture CAN packets on a USB device" code wasn't putting that field into host byte order, either. So have separate DLT_/LINKTYPE_ types, one for packets with the CAN ID in big-endian byte order and one for packets with the CAN ID in host byte order. When reading LINKTYPE_CAN_SOCKETCAN_HOSTENDIAN files, swap the CAN ID field as necessary to put it into the byte order for the host reading the file rather than the byte order for the host that wrote the file.
* | Squelch still more signed vs. unsigned warnings.Guy Harris2016-07-251-2/+2
| |
* | Squelch more signed vs. unsigned comparison warnings.Guy Harris2016-07-251-9/+9
| |
* | pcap_create_interface() needs the interface name on Linux.Guy Harris2016-06-301-9/+10
| | | | | | | | | | So pass it the interface name, and use the name passed to it rather than the name in the pcap_t - which hasn't yet been set at that point.
* | Don't have pcap_create_common() set opt.device.Guy Harris2016-06-301-2/+2
| | | | | | | | | | | | | | Instead, have pcap_create() do so. Also have pcap_create() on Windows handle converting a little-endian UCS-2/UTF-16 string to ASCII.
* | Rename opt.source to opt.device.Guy Harris2016-06-291-15/+15
| | | | | | | | | | | | | | For local captures, it's jut the device. If we add remote capture support, we'll be handed a URL, and will split the URL into multiple components, and will store the various components in the opt structure, with the path of the URL being opt.device.
* | Let the platform decide how to check capturable interfaces.Guy Harris2016-06-281-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Git's annoying policy of expecting a short one-line description of every change means that the first line isn't very explanatory.) Make pcap_findalldevs_interfaces() take as an argument a function that's used to check whether an interface can be captured on or not, rather than doing the check by trying to open the device for capturing. This lets pcap_findalldevs() find interfaces even if you don't have permission to capture on them; that way, instead of users saying "why isn't {tcpdump -D, tshark -D, dumpcap -D, Wireshark, etc.} showing me any interfaces?", they'll say "why am I getting a 'you don't have permissions' error when I try to capture on this interface?", which is a better description of the underlying problem. On some platforms, it also avoids a bunch of extra work when getting a list of interfaces.
* | Clean up handling of pcap_create(<nonexistent device>).Guy Harris2016-06-271-5/+25
| | | | | | | | | | | | | | Don't fail in pcap_create(), as it returns a pointer and isn't very good at being able to report specific errors, and as on other platforms - and with older versions of libpcap on Linux - it doesn't fail if there's no such device. Let it fail in pcap_activate(), instead.
* | Have pcap_platform_finddevs() do all the "find local interfaces" work.Guy Harris2016-06-261-0/+6
| | | | | | | | | | | | | | | | Have pcap_findalldevs() call it to find *all* the local interfaces. pcap_platform_finddevs() might call pcap_findalldevs_interfaces() or might do the work itself. Further work to come.
* | Clean up hardware time stamp support.Guy Harris2016-05-131-11/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't say that the "any" device supports any time stamp types; we can't arrange that every device, including devices that show up in the future, do hardware time stamping. If we can ask about hardware time stamp support, don't say we support hardware time stamping if the answer is "not for all packets". If we get ERANGE from an attempt to set hardware time stamping, it means "yes, we support hardware time stamping, but not for all packets matching that filter"; the filter in question is "all packets", so here it would mean "we can't do hardware time stamping for all incoming packets", which means "we can't do time stamping for captured packets".
generated by cgit v1.2.3 (git 2.39.1) at 2025-05-12 23:09:33 +0000