Member Avatar for dospy

i'm learning about networking on a site and there says there are 3 types of sending data:
unicast, multicast and broadcast
in the unicast case the IP layer encapsulates the IP destination(let's say "derp"). the interesting fact i've read about the unicast is that all machines within the same network will recieve the packet that is supposed to arrive at derp, but only derp will 'accept' the packet as the rest of the machines will drop it seeing the destination IP doesn't match with its IP.
so, i suppose kernel does check the ip matching which means it also drops the packet if it doesn't match.
what i'm interested in: "is it possible to catch the packets denied by kernel?" if yes, how?

  • 3 Contributors
  • 4 Replies
  • 136 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Taywin

Dani AI

Generated

As asked, you can sometimes capture packets that the IP stack later rejects — but whether you can see them at all depends on where they’re filtered: the NIC/switch (L2) or inside the kernel (L3/netfilter). was right to point at sniffing and was right to flag hardware; both are parts of the real picture.

If the network interface actually receives the Ethernet frame, a link‑layer capture (libpcap/tcpdump or a PF_PACKET socket) will see it before the IP layer accepts or rejects it. To force the interface to accept non‑matching frames, enable promiscuous mode and run a capture (tcpdump/libpcap). See the packet socket documentation for details on how link‑level capture works: packet(7) man page and libpcap docs at tcpdump.org.

If packets are dropped by kernel firewall/routing rules before userland sees them, use kernel hooks designed for inspection: netfilter’s NFLOG/NFQUEUE or a userspace queue with libnetfilter_queue lets you receive packets for analysis before a final DROP/ACCEPT decision. For the earliest, driver‑level inspection (and extreme performance), eBPF/XDP can attach very early in the receive path. See libnetfilter_queue and the kernel XDP docs: .

If the switch never forwards the frame to your port, no software on your host will see it. Options then are port mirroring (SPAN) or a network TAP, or capturing on a device that actually forwards the traffic. For general guidance on mirroring see Port mirroring.

Quick checklist: (1) Determine whether the NIC ever receives the frame (promisc/tcpdump on target). (2) If kernel drops it, try NFQUEUE/ulogd or eBPF/XDP. (3) If the switch filters it, use SPAN/TAP or capture on-path.

Recommended Answers

All 4 Replies

Member Avatar for Taywin

I think you may need to look into packet sniffing... Though, there would be even more interesting detail you may like to read.

Member Avatar for dospy

the problem is that the packets don't arrive to packet sniffers because they are discarded right away

Edited by dospy
Member Avatar for nmaillet

This also depends on your network as well. Many modern switches provide layer 3 support as well; that is, they are IP aware. If they do, they will keep routing tables, and usually only forward it to one port. Some commericial switches have a specific port that all packets are forwarded to for packet sniffers to use.

Member Avatar for Taywin

As nmaillet said, it involves hardware at this point...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.