RE: Killing kernel packet response

["David Hoelzer" <dhoelzer () sans org>]

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: owner-tcpdump-workers () sandelman ottawa on ca
[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: tcpdump-workers () tcpdump org
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