From: Michael Renzmann <mrenzmann@web.de>
To: netdev@oss.sgi.com
Subject: Deleting incoming network packets / sk_buff
Date: Sat, 14 Aug 2004 21:12:44 +0200 [thread overview]
Message-ID: <411E642C.9010708@web.de> (raw)
Hi all.
I'm just making my first steps in kernel programming, and I have a few
questions.
It's necessary for me to "delete" network packets that come in on a
ethernet device after passing them to an userspace program (through a
packet socket that the program has opened). My first idea was to write a
kernel module that registers on the NF_IP_PRE_ROUTING netfilter hook and
does its job. But there are two downsides on this approach:
1. I need to delete every packet, no matter if it is IP or something
else. As far as I understood only IP-packets will pass the netfilter
hooks, since the netfilter framework only works with IP traffic.
2. The solution also has to work for 2.2.x kernels, as long as there is
any way to achieve this functionality for these kernel series and 2.4.x
as well.
I continued to dig some documentation, and found a possible solution in
a rather old phrack article [1]: "What we do is code our own kernel
module that registers our packet_type{} data structure to handle all
incoming packets (sk_buff's) right after they come out of the device
driver." While the authors use this technique to implement some
"protocol obfuscation" or an in-kernel packet sniffer, it seems to be a
good way to reach what I want to do.
Now, what I'm wondering about is the way to "correctly" remove an
sk_buff so that the upper layer won't see the corresponding packet. I
somewhere read that the code for packet sockets have to clone the
sk_buff before passing it to the socket, else it would be "lost" and
could not be seen by following handlers.
So, the questions I have:
1. What has to be done to delete a bypassing sk_buff, so that upper
layer routines don't see it?
2. How can it be achieved to pass a sk_buff to opened packet sockets
before deleting the sk_buff? I guess the handler either has to pass the
sk_buff "manually" to the packet socket handler packet_rcv() or has to
place itself to be called directly after packet_rcv() has been called.
I hope that my description can be understood - not enough that I'm not
very keen with kernel programming, but I also am no native english
speaker... :) Please let me know if you need further information to clarify.
Bye, Mike
[1] http://www.phrack.org/show.php?p=55&a=12
next reply other threads:[~2004-08-14 19:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-14 19:12 Michael Renzmann [this message]
2004-08-14 22:15 ` Deleting incoming network packets / sk_buff Ben Greear
2004-08-15 18:05 ` Michael Renzmann
2004-08-15 18:18 ` Ben Greear
2004-08-15 18:57 ` Michael Renzmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=411E642C.9010708@web.de \
--to=mrenzmann@web.de \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).