grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] efinet: add efinet_multicast_filter command


From: Josef Bacik
Subject: Re: [PATCH] efinet: add efinet_multicast_filter command
Date: Fri, 6 Nov 2015 09:12:20 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]