All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: <grub-devel@gnu.org>
Subject: Re: [PATCH] efinet: add efinet_multicast_filter command
Date: Fri, 6 Nov 2015 09:12:20 -0500	[thread overview]
Message-ID: <563CB544.1060809@fb.com> (raw)
In-Reply-To: <563C2971.5090705@gmail.com>

On 11/05/2015 11:15 PM, Andrei Borzenkov wrote:
> 05.11.2015 22:23, Josef Bacik пишет:
>> We have some hardware that doesn't honor
>> EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST properly so we aren't
>> getting
>
> You mean that driver advertises promiscuous multicast support but does
> not implement it? Can you add debugging to efi_call_6
> (net->receive_filters, net, filters, 0, 0, 0, NULL); whether it fails.
> May be need set each one separately and fall back to promiscuous.
>

I spent a week debugging this before I declared it a firmware bug.  The 
receive_filters succeeds when setting it to promiscuous, and 
net->mode->receive_filter_settings has all the appropriate bits set. 
It's all done right, the firmware just isn't working.

I'll also note we noticed this with ipxe first (we haven't finished our 
grub2 rollout yet) and we had to do a similar approach there.

>> RA's that are multicasted properly (our switches respond to
>> solicitations with a
>> multicast rather than a unicast).
>
> Could you send packet trace?
>

Can't sorry, this is in our secure network.  But I can tell you we see 
the solicit from grub properly, and then the switches respond with a 
multicast RA and grub doesn't do anything with it.  These are from our 
FBOSS switches, we are fixing them to do unicast responses to 
solicitations as well because of this but a multicast response is also 
allowed.

>>  I don't want to add this filtering by
>> default, so add a new command to allow a user to specify a multicast
>> receive
>> filter.  We use it like this
>>
>
> I do not think we need any IPv4 multicasts; for IPv6 we need all nodes
> and solicited address.
>
> But I would like to understand first whether receive_filters fail and we
> ignore it or it succeeds.
>

I agree, I'll do what Vladimir is suggesting.  However I'm going to 
leave an option to use promiscuous.  We are going to use that to test 
new hardware coming in so we stop buying crap that doesn't behave 
according to spec.  Thanks,

Josef



      reply	other threads:[~2015-11-06 14:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05 19:23 [PATCH] efinet: add efinet_multicast_filter command Josef Bacik
2015-11-05 20:28 ` Vladimir 'phcoder' Serbinenko
2015-11-05 21:17   ` Josef Bacik
2015-11-05 23:47     ` Vladimir 'phcoder' Serbinenko
2015-11-06 18:42       ` Andrei Borzenkov
2015-11-06 18:47         ` Vladimir 'phcoder' Serbinenko
2015-11-07  6:08           ` Andrei Borzenkov
2015-11-10 18:33   ` Josef Bacik
2015-11-06  4:15 ` Andrei Borzenkov
2015-11-06 14:12   ` Josef Bacik [this message]

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=563CB544.1060809@fb.com \
    --to=jbacik@fb.com \
    --cc=grub-devel@gnu.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.