Given IPPROTO_IPV4, IPPROTO_IPV6 and IPPROTO_ETHERIP have different
protocol numbers, then it is perfect valid to tunnel IPv4, IPv6 and
Ethernet frames in IPv[46] datagrams by the same interface. Since
gif(4) has already utilized the inbound csum_data field to carry
address family, also teach bridge(4) to do that, rather than checking
if a gif(4) interface is member of a bridge(4) interface.
Without this fix, the IPv[46] in IPv[46] setup will not work when the
gif(4) interface is member of a bridge(4) interface, aka the EtherIP
setup, as the address family passed from gif_output() will be overwrote
with the wrong one AF_LINK by gif_transmit(), and end up with incorrectly
encapsulated packets.
PR: 227450
Tested by: meta
Fixes: 8a0308722372 gif(4): Assert that gif_output() isn't called for EtherIP
MFC after: 2 weeks