From: Herbert Xu <herbert@gondor.apana.org.au>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: dhcp client packet sniffing...
Date: Thu, 8 Apr 2010 19:47:38 +0800 [thread overview]
Message-ID: <20100408114738.GA23329@gondor.apana.org.au> (raw)
In-Reply-To: <20100408.035049.177640912.davem@davemloft.net>
On Thu, Apr 08, 2010 at 03:50:49AM -0700, David Miller wrote:
>
> This is an old topic, but looking at traces tonight I was reminded
> about it.
>
> dhcp clients sniff every packet in the system, the reason it does this
> and the things we can do to make it not have to do so have been
> discussed before. Actually, I don't remember where we got with
> that and if we were able to make it such that the dhcp client
> doesn't have to do this any more. Herbert?
The main problem is that it needs to be able to receive packets
destined to an address which is not yet a local address. IOW,
it needs to be able to bypass the routing table and receive
non-local traffic.
> This means every packet in the machine gets sniffed.
>
> The DHCP client at least installs a socket filter that only accepts
> the packets that the DHCP client is actually interested in.
>
> The problem is that we clone the SKB and do some other operations
> before running the socket filter.
>
> I was thinking, what if we simply move the sk_filter() call up to
> dev_queue_xmit_nit()? And if sk_filter() rejects we don't even need
> to clone the packet.
Since you're talking about dev_queue_xmit_nit, I presume you're
mainly concerned about the TX direction?
FWIW the DHCP client does not need to see any packets in the TX
direction. So if we could provide a way to only sniff RX traffic
then that would remove the need to clone for TX. However, this
may require user-space modifications.
Another approach is to use skb_share. At some point all protocols
were designed to handle shared skbs.
If we could tap into that then it would be an obvious way to
eliminate the clone. To do this we'd need to audit all the
protocols to ensure that they can still handle shared packets
safely.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2010-04-08 11:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 10:50 dhcp client packet sniffing David Miller
2010-04-08 10:59 ` Neil Horman
2010-04-08 11:01 ` David Miller
2010-04-08 11:47 ` Herbert Xu [this message]
2010-04-08 12:11 ` David Miller
2010-04-08 12:30 ` Herbert Xu
2010-04-08 12:49 ` Patrick McHardy
2010-04-08 13:12 ` Herbert Xu
2010-04-08 13:23 ` Patrick McHardy
2010-04-08 14:27 ` Herbert Xu
2010-04-08 14:37 ` Maxime Bizon
2010-04-08 15:07 ` Herbert Xu
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=20100408114738.GA23329@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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).