All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, bridge@linux-foundation.org
Subject: Re: [Bridge] [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>

WARNING: multiple messages have this Message-ID (diff)
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: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-01  1:18 [Bridge] [PATCH] bridge: avoid ptype_all packet handling Stephen Hemminger
2007-03-01  1:18 ` Stephen Hemminger
2007-03-01  1:28 ` [Bridge] " Ben Greear
2007-03-01  1:28   ` Ben Greear
2007-03-01  3:56   ` [Bridge] " Stephen Hemminger
2007-03-01  3:56     ` Stephen Hemminger
2007-03-01  4:05     ` [Bridge] " Ben Greear
2007-03-01  4:05       ` Ben Greear
2007-03-01  7:04       ` [Bridge] " Stephen Hemminger
2007-03-01  7:04         ` Stephen Hemminger
2007-03-01  7:22         ` [Bridge] " David Miller
2007-03-01  7:22           ` David Miller
2007-03-01  7:26           ` [Bridge] " Stephen Hemminger
2007-03-01  7:26             ` Stephen Hemminger
2007-03-01  7:30             ` [Bridge] " David Miller
2007-03-01  7:30               ` David Miller
2007-03-01 11:47               ` [Bridge] " jamal
2007-03-01 11:47                 ` jamal
2007-03-03  2:14               ` [Bridge] " Andi Kleen
2007-03-03  2:14                 ` Andi Kleen
2007-03-03  4:22                 ` [Bridge] " David Miller
2007-03-03  4:22                   ` David Miller
2007-03-03  7:09                   ` [Bridge] " Stephen Hemminger
2007-03-03  7:09                     ` Stephen Hemminger
2007-03-03 12:30                   ` [Bridge] " Andi Kleen
2007-03-03 12:30                     ` Andi Kleen
2007-03-02 21:26 ` [Bridge] " David Miller
2007-03-02 21:26   ` David Miller
2007-03-02 22:09   ` [Bridge] [RFC 1/2] " Stephen Hemminger
2007-03-02 22:09     ` Stephen Hemminger
2007-03-02 22:14     ` [Bridge] [RFC 2/2] bridge: per device promiscious taps Stephen Hemminger
2007-03-02 22:14       ` Stephen Hemminger
2007-03-02 22:48     ` [Bridge] [RFC 1/2] bridge: avoid ptype_all packet handling David Miller
2007-03-02 22:48       ` David Miller
2007-03-02 23:18       ` [Bridge] " David Miller
2007-03-02 23:18         ` David Miller
2007-03-02 23:34         ` Stephen Hemminger [this message]
2007-03-02 23:34           ` Stephen Hemminger
2007-03-02 23:41           ` [Bridge] " David Miller
2007-03-02 23:41             ` David Miller
2007-03-03  5:38         ` [Bridge] " Herbert Xu
2007-03-03  5:38           ` Herbert Xu
2007-03-03  5:59           ` [Bridge] " David Miller
2007-03-03  5:59             ` David Miller
2007-03-03  6:42             ` [Bridge] " Herbert Xu
2007-03-03  6:42               ` Herbert Xu
2007-03-02 22:15   ` [Bridge] " Stephen Hemminger
2007-03-02 22:15     ` Stephen Hemminger
2007-03-03 12:04   ` [Bridge] [PATCH] " Stefan Rompf
2007-03-03 12:04     ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.