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>
next prev parent 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.