Page MenuHomeFreeBSD

EtherIP: Fix passing the address family to gif(4)
ClosedPublic

Authored by zlei on Fri, Aug 1, 4:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Aug 8, 12:05 PM
Unknown Object (File)
Fri, Aug 8, 12:01 PM
Unknown Object (File)
Fri, Aug 8, 10:19 AM
Unknown Object (File)
Thu, Aug 7, 2:16 AM
Unknown Object (File)
Wed, Aug 6, 11:20 PM
Unknown Object (File)
Tue, Aug 5, 8:31 AM
Unknown Object (File)
Tue, Aug 5, 5:33 AM
Unknown Object (File)
Tue, Aug 5, 3:37 AM

Details

Summary

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 overwritten
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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

zlei requested review of this revision.Fri, Aug 1, 4:17 PM
zlei edited the summary of this revision. (Show Details)

Again, this worked fine for me. I hope this will be merged soon and included in 15.0-RELEASE.

This revision is now accepted and ready to land.Wed, Aug 6, 9:40 AM

Again, this worked fine for me. I hope this will be merged soon and included in 15.0-RELEASE.

Landed. Thanks for testing the fix !