tcpdump mailing list archives
Re: Killing kernel packet response
From: Guy Harris <gharris () sonic net>
Date: Mon, 11 Nov 2002 08:51:40 -0800
On Mon, Nov 11, 2002 at 09:26:35AM -0700, Jeff Shipman wrote:
I'm working on a project where I must capture packets as they come in over the wire and then depending on what I see in those packets, I need to send out a particular response packet. I'm using libpcap for the capturing and libnet for the packet crafting. What I'm wondering is: how can I keep the kernel from generating its own response packet so I can send off my packet in response instead? I would like there to be a way that does not require writing kernel code as I'm trying to keep this very portable across multiple unices.
Unfortunately, I don't think you're going to get what you'd like. I know of no portable way to disable the kernel processing of particular packets for some particular protocol. There may be ways of doing this in userland on some UNIXes, but I don't think there's any single way to do it that works on multiple UNIXes. (I also don't know what any of those platform-dependent ways of doing it are.)
I also have one more question: When my callback gets called from pcap_loop(), how can I tell what type of packet is being held inside? (ie: ethernet or atm?
The way you tell what link-layer packet type you're getting is to use the result of "pcap_datalink()" (which doesn't change from packet to packet).
udp or tcp?)
You left out a step - "IPv4, IPv6, etc.?" You first have to determine if the packet is an IP packet before asking whether it's UDP, TCP, or another protocol that runs atop IP (ICMP, SCTP, etc.). The way you determine the type of a packet depends on the link-layer packet type. You'd have to look at the link-layer header, and possibly another header after it, such as an 802.2 LLC header. If you have an IPv4 packet, you then look at the protocol field in the IPv4 header. If you have an IPv6 packet, you look at the "next header" field in the IPv6 header - and, if the next header is an extension header, look at the "next header" field in *that* header, and keep going until you run out of extension headers.
Any advice will be greatly appreciated.
Advice: read the pcap(3) man page for recent versions of libpcap to see how to interpret the result of "pcap_datalink()"; read various link-layer protocol specs to see how to analyze link-layer headers (see http://standards.ieee.org/getieee802/ for free access to many IEEE standards for link-layer headers); read RFC 791 to see how to analyze IPv4 headers and read RFC 2460 to see how to analyze IPv6 headers; and/or read the source code to tcpdump to see how to do that. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- Killing kernel packet response Jeff Shipman (Nov 11)
- Re: Killing kernel packet response Guy Harris (Nov 11)
- RE: Killing kernel packet response David Hoelzer (Nov 11)
- Re: Killing kernel packet response Guy Harris (Nov 11)