merged in 742c5498aca9a9a31a68eb9d5888edf36b7034dd

@pouria — you're right that this is solvable in the firewall, and I should have checked before offering the boot-window argument. One detail worth recording: on a stock system rcorder puts netif well before rc.d/ipfw, and net.inet.ip.fw.default_to_accept reads 1 on my hosts — so with ipfw loaded from rc.conf the window is real. It closes with ipfw_load="YES" and net.inet.ip.fw.default_to_accept=0 in loader.conf, which makes the default deny active before any interface is configured. That's the correct answer to my objection, and it belongs in documentation.

In D59160#1357307, @paulo_nlink.com.br wrote:

@pouria MLD's role is informing snooping switches and multicast routers where to forward group traffic so they can prune instead of flooding (RFC 4541). So "ND relies on MLD" holds on fabrics whose switches prune by snooping

@pouria — thanks for the reasoning chain, but I believe step 4 conflates two mechanisms. What limits NS processing to the right nodes on a flat L2 is the solicited-node-to-33:33:xx MAC mapping: NICs filter in hardware, no MLD involved. MLD's role is informing snooping switches and multicast routers where to forward group traffic so they can prune instead of flooding (RFC 4541). So "ND relies on MLD" holds on fabrics whose switches prune by snooping — and IXP peering LANs are the opposite case: they flood link-local multicast, which is why their operators can and do forbid MLD (IX.br PRT, Euro-IX). Your step 2 is actually the argument: exchanges permit ARP because IPv4 can't work without it, and they permit NS/NA while forbidding MLD because, on their fabric, ND works without it. That analysis was done by the people who run the switches.

I'm the original author of this code. I have run into exactly the same issue you have called out, but at COMEX/CME in Chicago with IGMPv3 being seen upstream of a demarc boundary where only PIM traffic was expected. This was on Linux, and we ended up filtering outgoing IGMP traffic with iptables; ~2010.

Thank you for your contribution.
I understand your concern.
I've encountered similar policies at multiple IXPs as well. (ofc not for MLD)

oh and I just hit this myself on a power8 box that /has/ bxe in it!

Superseded by D58721, which covers both fixes here on a rewritten common unwind path and adds the SR-IOV schema and core-offset refcount cases. Abandoning in favor of that.

I was independently dealing with similar issues while testing SR-IOV. Can you have a look at https://reviews.freebsd.org/D58721 and the linked fail(9) commit.

igc already does not panic per your own statement, so I'm not sure what you are arguing. My request is to unify lifecycle management as one commit. But now looking and iflib.c I think the igc_if_init should simply be dropped from resume and media_change so please do that instead.

@kbowling resume and media_change are not the same. They already inside a CTX_LOCK already, no panic.

It's one unit of work unifying a lifecycle issue

In D58629#1345834, @kbowling wrote:

Can you do the same for media_change and if_resume?

Can you do the same for media_change and if_resume?

Can you do the same for media_change and if_resume?

In D58585#1344817, @pouria wrote:

Nice work, do you have plan to create an I-D for it?

Nice work, do you have plan to create an I-D for it?

i'm ok with this; this could've been two or more diffs though (the debug refactor alone would be good as a single diff.)

nice catch! lets see if we can find a broadcom peep to look at this.

Root cause analysis revealed 2 kernel-space issues:

The #ifdef INVARIANTS conditional for _Static_assert() is mostly a no-op, because GENERIC enables them via "include "std.debug"".

@gallatin would you mind eyeballing this? ty!

@tuexen is currently looking to create standard compliant packetdrill scripts to check various test cases.