Where Did Wireshark/Tcpdump/Libpcap Intercept Packet Inside Linux Kernel

Where did Wireshark/tcpdump/libpcap intercept packet inside Linux kernel?

But where does this happen?

If I understood you correctly - you want to know, where is initialized such socket.

There is pcap_create function, that tries to determine type of source interface, creates duplicate of it and activates it.

For network see pcap_create_interface function => pcap_create_common function => pcap_activate_linux function.

All initialization happens in pcap_activate_linux => activate_new function => iface_bind function

( copy descriptor of device with handlep->device = strdup(device);,

create socket with socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL)),

bind socket to device with bind(fd, (struct sockaddr *) &sll, sizeof(sll)) ).

For more detailed information read comments in source files of mentioned functions - they are very detailed.

After initialization all work happens in a group of functions such as pcap_read_linux, etc.

where does the wireshark capture the packets

where does the wireshark capture the packets in the linux kernel?

On UN*Xes, it uses libpcap, which, on Linux, uses AF_PACKET sockets. (On Windows, it uses WinPcap, which is a driver plus a port of libpcap to use the driver.)

If an output packet is captured by wireshark , will the packet be sent out definitely through corresponding interface?

No. The networking stack hands the packet to the appropriate AF_PACKET sockets and to the driver; the driver might drop the packet (for example, if, on an Ethernet, it got multiple collisions and gave up) even though the packet was delivered to the AF_PACKET socket.

In other words, could an output packet that captured by wireshark be dropped before it is sent out?

Yes. See above.

How to intercept IP packets going to the kernel Linux

Apparently you are trying to create a tunnel. Instead of trying to hijack an existing interface, the proper way to create a tunnel is to create a new interface, using a kernel module or TUN/TAP. However, tunnels are normally intended to receive traffic generated on the machine which runs the tunnel software, or at least routed through it. That means you will also have to set up the kernel to route the traffic to your tunnel.

You can create a new interface as a TUN/TAP interface. It is like a virtual ethernet driver except you don't need to write a new kernel module. It is designed for tunnels (hence the name).

The difference between TUN and TAP is that a TUN interface is an IP interface that receives IP packets from the kernel's IP routing system, and a TAP interface receives Ethernet packets (which may contain IP packets) so it can alternatively be part of a bridge (a virtual Ethernet switch - which only looks at the Ethernet header, not the IP header).

I think for your scenario, you will find it easiest to create a TAP interface, then create a bridge (virtual Ethernet switch) between the TAP interface, and the interface which the other host is connected to. Neither one needs an IP address - the kernel will happily pass Ethernet-layer traffic without attempting to process the IP information in the packet. Your tunnel software can then emulate a host - or tunnel to an actual host - or whatever you want it to do.

Or in visual form:

If you want the host to also be able to talk to the machine running the tunnel software - without going through the tunnel software - then you may choose to put an IP address on the bridge.

Does libpcap use the traffic control layer of linux?

does pcap_inject call the traffic control layer of linux to send packets? Or does it directly send to the device driver?

It does a send() call on a PF_PACKET socket. By default, packets sent on those sockets go through the traffic control layer; to quote the PF_PACKET socket man page:

   PACKET_QDISC_BYPASS (since Linux 3.14)
          By default, packets sent through packet sockets pass through
          the kernel's qdisc (traffic control) layer, which is fine for
          the vast majority of use cases.  For traffic generator appli‐
          ances using packet sockets that intend to brute-force flood
          the network—for example, to test devices under load in a simi‐
          lar fashion to pktgen—this layer can be bypassed by setting
          this integer option to 1.  A side effect is that packet
          buffering in the qdisc layer is avoided, which will lead to
          increased drops when network device transmit queues are busy;
          therefore, use at your own risk.

libpcap does not turn that option on.

In tools like tcpdump, when exactly are the network packets captured?

Both of those tools capture the data exactly as it goes out over the wire. (Think of it as sort of the equivalent of "tee" for output that's going to screen as well as to file; here too, the same data goes to the socket as well as to tcpdump or whatever.)

So yes, if your tool is configured correctly to encrypt the data before sending it, then tcpdump or Wireshark should reflect that in their packet captures.

Do real software have kernel modules inside them on Linux and other OSes

No. Linux programs very rarely have kernel modules. Kernel modules are normally for hardware device drivers.

If a program does need a certain kernel module, it will tell you to install the module yourself. It won't include a copy of the module.

It sounds like you want to make your own driver that replaces the normal driver for your network card. It's possible, but nobody does it. If you want to shut down or start up a network interface, there is already a way to do that without writing your own kernel module. If you want to count the packets, there's already a way to do that. If you want to see all the packets, there's already a way to do that.

There's no way to read card registers already - that's because every card has different registers. But whatever you want to do with those registers, there's probably a way to do it already.

---

Related Topics