Re: Killing kernel packet response

[Guy Harris <gharris () sonic net>]

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