dhcp client packet sniffing...

dhcp client packet sniffing...

[David Miller]

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?

But, in any event, the fact of the matter is that currently it still
does on many machines.

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.

Re: dhcp client packet sniffing...

[Neil Horman]

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?
> 
Dave, sorry to be late to the discussion, but can you refesh us on why dhcp has
to sniff every packet?
Regards
Neil

Re: dhcp client packet sniffing...

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 8 Apr 2010 06:59:51 -0400

> Dave, sorry to be late to the discussion, but can you refesh us on
> why dhcp has to sniff every packet?

It wants to see DHCP packets from the server.

And it can't use ipv4 RAW sockets due to some limitations wrt. getting
at the link layer headers when using that interfaces.

Re: dhcp client packet sniffing...

[Herbert Xu]

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

Re: dhcp client packet sniffing...

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 19:47:38 +0800

> 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.

I don't even want to call down into the AF_PACKET code for
the case where the filter doesn't pass.

We have the socket pointer etc. already in dev_queue_xmit_nit(), so we
can easily do it.

Re: dhcp client packet sniffing...

[Herbert Xu]

On Thu, Apr 08, 2010 at 05:11:44AM -0700, David Miller wrote:
>
> We have the socket pointer etc. already in dev_queue_xmit_nit(), so we
> can easily do it.

It doesn't look trivial to me since AF_PACKET fiddles with packet
headers before running the filter...

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

Re: dhcp client packet sniffing...

[Patrick McHardy]

Herbert Xu wrote:
> On Thu, Apr 08, 2010 at 05:11:44AM -0700, David Miller wrote:
>> We have the socket pointer etc. already in dev_queue_xmit_nit(), so we
>> can easily do it.
> 
> It doesn't look trivial to me since AF_PACKET fiddles with packet
> headers before running the filter...

Yes, that looks difficult. What might work is to pass the skb->data
offsets resulting from those modifications to sk_run_filter to
adjust the postition when loading data from the packet. That would
allow to run the filter on the original packet before cloning it.

Regarding your idea of only receiving incoming packets, userspace could
use the SKF_AD_PKTTYPE filter with PACKET_HOST. During filter attachment
and checks, we could mark the socket as only interested in incoming or
outgoing packets.

This would require userspace changes of course, but we should be able
to avoid passing outgoing packets to af_packet with very low overhead.

Re: dhcp client packet sniffing...

[Herbert Xu]

On Thu, Apr 08, 2010 at 02:49:49PM +0200, Patrick McHardy wrote:
> 
> Yes, that looks difficult. What might work is to pass the skb->data
> offsets resulting from those modifications to sk_run_filter to
> adjust the postition when loading data from the packet. That would
> allow to run the filter on the original packet before cloning it.

The thing is we can't express those offsets as constants so we'll
need to run protocol-specific code (i.e., an indirect function
call) prior to calling the filter.

At that point I'd just give up and go back to the skb_share idea :)

If we're concerned about atomic counter performance, we could even
do a non-atomic version of skb_share and use it here.  We're the
sole owner of the skb at this point.

> Regarding your idea of only receiving incoming packets, userspace could
> use the SKF_AD_PKTTYPE filter with PACKET_HOST. During filter attachment
> and checks, we could mark the socket as only interested in incoming or
> outgoing packets.
> 
> This would require userspace changes of course, but we should be able
> to avoid passing outgoing packets to af_packet with very low overhead.

As kernel programmers, we reject in principle any solution that
involves user-space coding :)

Seriously, with the number of DHCP clients out there, any solution
that requires changing the client is not going to achieve the
objective in a reasonable time-frame.

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

Re: dhcp client packet sniffing...

[Patrick McHardy]

Herbert Xu wrote:
> On Thu, Apr 08, 2010 at 02:49:49PM +0200, Patrick McHardy wrote:
>> Yes, that looks difficult. What might work is to pass the skb->data
>> offsets resulting from those modifications to sk_run_filter to
>> adjust the postition when loading data from the packet. That would
>> allow to run the filter on the original packet before cloning it.
> 
> The thing is we can't express those offsets as constants so we'll
> need to run protocol-specific code (i.e., an indirect function
> call) prior to calling the filter.

Well, we already have some AF_PACKET specific code in
dev_queue_xmit_nit(). It wouldn't be pretty, but for this special
case we could just calculate the offsets in a non-generic way
without indirect function calls. It basically comes down to:

if (ptype->af_packet_priv &&
    dev->header_ops) {
	if (((struct sock *)ptype->af_packet_priv)->sk_type != SOCK_DGRAM)
		offset = skb->data - skb_mac_header(skb);
	else /* always PACKET_OUTGOING in dev_queue_xmit_nit */
		offset = skb_network_offset(skb);
}

> At that point I'd just give up and go back to the skb_share idea :)

That does sound better :)

> If we're concerned about atomic counter performance, we could even
> do a non-atomic version of skb_share and use it here.  We're the
> sole owner of the skb at this point.
> 
>> Regarding your idea of only receiving incoming packets, userspace could
>> use the SKF_AD_PKTTYPE filter with PACKET_HOST. During filter attachment
>> and checks, we could mark the socket as only interested in incoming or
>> outgoing packets.
>>
>> This would require userspace changes of course, but we should be able
>> to avoid passing outgoing packets to af_packet with very low overhead.
> 
> As kernel programmers, we reject in principle any solution that
> involves user-space coding :)
> 
> Seriously, with the number of DHCP clients out there, any solution
> that requires changing the client is not going to achieve the
> objective in a reasonable time-frame.

That's true.

Re: dhcp client packet sniffing...

[Herbert Xu]

On Thu, Apr 08, 2010 at 07:47:38PM +0800, Herbert Xu wrote:
> 
> 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.

Oh and if anybody is doing any user-space hacking, this is what you
could do: AF_PACKET is only necessary when you're waiting for a
response from the server.  So you could close the socket after a
lease has been acquired, and reopen it the next time you need
to communicate with a server.

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

Re: dhcp client packet sniffing...

[Maxime Bizon]

On Thu, 2010-04-08 at 22:27 +0800, Herbert Xu wrote:

> Oh and if anybody is doing any user-space hacking, this is what you
> could do: AF_PACKET is only necessary when you're waiting for a
> response from the server.  So you could close the socket after a
> lease has been acquired, and reopen it the next time you need
> to communicate with a server.

That's already what some clients do (at least udhcpc from busybox)

The packet socket is only needed during "init_selecting", "init_reboot",
"requesting" and "rebinding" state.

For "bound" or "requesting" state (in which you spend most of the time),
the packet socket is not needed and a standard AF_INET dgram socket can
be used instead.

You can't close the socket while bound since you can receive DHCPINFORM
anytime.

-- 
Maxime

Re: dhcp client packet sniffing...

[Herbert Xu]

On Thu, Apr 08, 2010 at 04:37:20PM +0200, Maxime Bizon wrote:
>
> You can't close the socket while bound since you can receive DHCPINFORM
> anytime.

Right, as long as you don't use an AF_PACKET socket most of the
time it should be fine.

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