3

If I want to sniffing packet in linux without set any filters, I saw 2 options.

  1. Use libpcap

  2. Use raw socket myself like https://www.binarytides.com/packet-sniffer-code-in-c-using-linux-sockets-bsd-part-2/

Why libpcap is better than use raw sockets myself?

yfr24493AzzrggAcom
  • 159
  • 1
  • 2
  • 13

1 Answers1

7

Three reasons:

1) It's way easier to correctly set up.

2) It's portable, even to Windows, which uses a quite similar yet different API for sockets.

3) It's MUCH faster.

1 and 2, IMO, don't need much explanation. I'll dive into 3.

To understand why libpcap is (generally) faster, we need to understand the bottlenecks in the socket API.

The two biggest bottlenecks that libpcap tends to avoid are syscalls and copies.

How it does so is platform-specific.

I'll tell the story for Linux.

Linux, since 2.0 IIRC, implements what it calls AF_PACKET socket family, and later with it PACKET_MMAP. I don't exactly recall the benefits of the former, but the latter is critical to avoid both copying from kernel to userspace (there are still a few copies kernel-side) and syscalls.

In PACKET_MMAP you allocate a big ring buffer in userspace, and then associate it to an AF_PACKET socket. This ring buffer will contain a bit of metadata (most importantly, a marker that says if a region is ready for user processing) and the packet contents.

When a packet arrives to a relevant interface (generally one you bind your socket to), the kernel makes a copy in the ring buffer and marks the location as ready for userspace*. If the application was waiting on the socket, it gets notified*.

So, why is this better than raw sockets? Because you can do with few or none syscalls after setting up the socket, depending on whether you want to busy-poll the buffer itself or wait with poll until a few packets are ready, and because you don't need the copy from the socket's internal RX buffer to your user buffers, since it's shared with you.

libpcap does all of that for you. And does it on Mac, *BSD, and pretty much any platform that provides you with faster capture methods.

*It's a bit more complex on version 3, where the granularity is in "blocks" instead of packets.

Oppen
  • 413
  • 2
  • 9
  • so if I sniffing with raw packets that maybe slowly my network in machine? Because it's make bottlenecks, and if I will sniffing with libpcap my network will not slowly? – yfr24493AzzrggAcom Apr 03 '20 at 10:34
  • No, it won't make your network slower. The kernel will be copying the data to internal buffers associated to the given socket as they come. If there's no space, *that socket* will not have a copy, and a counter will be incremented that serves as a stat for lost packets for that socket. Any other socket that actually had space will normally receive packets at normal speed. There is a little nuance coming from the fact you make copies per socket: you *can* overwhelm the network stack if you open too many sockets, but that's probably controlled by an rlimit or the like. – Oppen Apr 03 '20 at 13:43