One solution is to take the LaBrea approach- ie, discover an unused IP on the local network and take it over through MAC spoofing.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:owner-tcpdump-workers@;sandelman.ottawa.on.ca] On Behalf Of Guy Harris Sent: Monday, November 11, 2002 11:52 AM To: Jeff Shipman Cc: [EMAIL PROTECTED] Subject: Re: [tcpdump-workers] Killing kernel packet response 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 - 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
