Martin, good day.
Sun, Jun 09, 2019 at 11:35:48AM -0300, Martin Pieuchot wrote:
> On 07/06/19(Fri) 20:55, Eygene Ryabinkin wrote:
> > 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?
Reading bridge_ioctl() in /sys/net/if_bridge.c and examining
paths for SIOCBRDGADD/SIOCBRDGADDL and SIOCBRDGADDS I see the
following blocks:
{{{ ADD/ADDL
if (ifs->if_type == IFT_ETHER) {
error = ifpromisc(ifs, 1);
if (error != 0)
break;
} else {
error = EINVAL;
break;
}
}}}
{{{ ADDS
if (ifs->if_type != IFT_ETHER) {
error = EINVAL;
break;
}
}}}
So, ifs->if_type != IFT_ETHER will result in EINVAL. Moreover,
reading gif(4) yields
{{{
Previously, gif supported RFC 3378 EtherIP tunnels over bridge(4)
interfaces. This is now handled by etherip(4).
}}}
and this provides the explicit explanation that gif(4) used to work
with bridge(4), but now etherip(4) took over for Ethernet tunnels
and other gif(4) types seem to have no Ethernet-compatible MACs,
so they can't be used with bridge(4).
--
rea
