netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: bridge@linux-foundation.org, netdev@vger.kernel.org
Subject: Re: [RFC 1/2] bridge: avoid ptype_all packet handling
Date: Fri, 2 Mar 2007 15:34:14 -0800	[thread overview]
Message-ID: <20070302153414.4d8304e0@freekitty> (raw)
In-Reply-To: <20070302.151803.74748558.davem@davemloft.net>

On Fri, 02 Mar 2007 15:18:03 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: David Miller <davem@davemloft.net>
> Date: Fri, 02 Mar 2007 14:48:18 -0800 (PST)
> 
> > Back to a workable solution, why doesn't DHCP specify a specific
> > device?  It would fix this performance problem completely, at the
> > application level.
> 
> Since nobody seems to be able to be bothered to actually look
> at what DHCP clients are doing, I actually did and it's no
> surprise that broken stuff is happening here.

I was in middle of checking that..

> Here is how dhcp3-3.0.3 binds AF_PACKET sockets, in common/lpf.c:
> 
> 	struct sockaddr sa;
>  ...
> 	/* Bind to the interface name */
> 	memset (&sa, 0, sizeof sa);
> 	sa.sa_family = AF_PACKET;
> 	strncpy (sa.sa_data, (const char *)info -> ifp, sizeof sa.sa_data);
> 	if (bind (sock, &sa, sizeof sa)) {
> 		if (errno == ENOPROTOOPT || errno == EPROTONOSUPPORT ||
> 		    errno == ESOCKTNOSUPPORT || errno == EPFNOSUPPORT ||
> 		    errno == EAFNOSUPPORT || errno == EINVAL) {
> 			log_error ("socket: %m - make sure");
> 			log_error ("CONFIG_PACKET (Packet socket) %s",
> 				   "and CONFIG_FILTER");
> 			log_error ("(Socket Filtering) are enabled %s",
> 				   "in your kernel");
> 			log_fatal ("configuration!");
> 		}
> 		log_fatal ("Bind socket to interface: %m");
> 	}
> 
> So it puts a string into the sockaddr data, and there
> is no mention of sockaddr_ll, which is what is supposed to be
> provided as the socket address here, in the entire DHCP tree.
> 
> I'm tempted to say I must be missing something here, since I can't see
> how this could possible work at all.  The string passed in should
> be interpreted as the ifindex value, and thus trigger a -ENODEV
> return from AF_PACKET's bind() implementation.
> 
> My suspicions are confirmed by the patch here:
> 
> http://kernel.org/pub/linux/kernel/people/chuyee/patches/dhcp-3.0/dhcp-3.0-linux_cooked_packet.patch

Can you get FC fixed?

> Really, this bogus bind() explains everything.

Should we add a warning to kernel log, to make distro's fix it?

It might make sense to add a per-device ptype_dev list in network device?



-- 
Stephen Hemminger <shemminger@linux-foundation.org>

  reply	other threads:[~2007-03-02 23:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-01  1:18 [PATCH] bridge: avoid ptype_all packet handling Stephen Hemminger
2007-03-01  1:28 ` Ben Greear
2007-03-01  3:56   ` Stephen Hemminger
2007-03-01  4:05     ` Ben Greear
2007-03-01  7:04       ` Stephen Hemminger
2007-03-01  7:22         ` David Miller
2007-03-01  7:26           ` Stephen Hemminger
2007-03-01  7:30             ` David Miller
2007-03-01 11:47               ` jamal
2007-03-03  2:14               ` Andi Kleen
2007-03-03  4:22                 ` David Miller
2007-03-03  7:09                   ` Stephen Hemminger
2007-03-03 12:30                   ` Andi Kleen
2007-03-02 21:26 ` David Miller
2007-03-02 22:09   ` [RFC 1/2] " Stephen Hemminger
2007-03-02 22:14     ` [RFC 2/2] bridge: per device promiscious taps Stephen Hemminger
2007-03-02 22:48     ` [RFC 1/2] bridge: avoid ptype_all packet handling David Miller
2007-03-02 23:18       ` David Miller
2007-03-02 23:34         ` Stephen Hemminger [this message]
2007-03-02 23:41           ` David Miller
2007-03-03  5:38         ` Herbert Xu
2007-03-03  5:59           ` David Miller
2007-03-03  6:42             ` Herbert Xu
2007-03-02 22:15   ` Stephen Hemminger
2007-03-03 12:04   ` [PATCH] " Stefan Rompf

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=20070302153414.4d8304e0@freekitty \
    --to=shemminger@linux-foundation.org \
    --cc=bridge@linux-foundation.org \
    --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).