On 2019/06/09 11:35, Martin Pieuchot wrote:
> On 07/06/19(Fri) 20:55, Eygene Ryabinkin wrote:
> > Good day.
> >
> > With the hints from Martin Pieuchot had found out that the current
> > handling of IFT_ETHER for bridge(4) /and nowadays, after de-introduction
> > of IFT_MPLSTUNNEL/mpw(4) type interfaces, only IFT_ETHER ones can
> > be attached to the bridge(4)/
>
> Can't gif(4) interfaces be attached as well?
gif(4) can't any more. Some of the gre(4) family can, but only the
ethernet-ish ones - there is this existing check in if_bridge.c when
the port is added to the bridge:
if (ifs->if_type == IFT_ETHER) {
error = ifpromisc(ifs, 1);
if (error != 0)
break;
} else {
error = EINVAL;
break;
}
> > From c5dc1bf7b8875788af3c325e618b08e1ff3d90a9 Mon Sep 17 00:00:00 2001
> > From: Eygene Ryabinkin <[email protected]>
> > Date: Fri, 7 Jun 2019 20:23:58 +0300
> > Subject: [PATCH 2/2] bridge(4): simplify interface handling logics
> >
> > - uniformly check for IFT_ETHER in both add-type ioctls:
> > only Ethernet interfaces can nowadays be bridge(4) members
> >
> > - move promiscious mode handling out of IFT_ETHER checks:
> > prior code structure was due to the IFT_MPLSTUNNEL interface
> > types that need no promiscious mode, but now they are gone
> >
> > - don't check for IFT_ETHER in the run-time packet handling:
> > this is now completely redundant.
I don't think I have a good place to test bridge(4) diffs at the moment
but this looks correct to me.
