Quick review confirms that they do not, also IPv6 doesn't expect
such a change in mbuf. In IPv4 this appeared in 0aade26e6d061,
which doesn't seem to have a valid explanation why.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 42682 Build 39570: arc lint + arc unit
Event Timeline
Comment Actions
The reason for the change of the interface might be located in the pfil_run_hooks.
May be @kp can tell something more about the magic there.
Comment Actions
Sure, the expectations in 0aade26e6d061 were that pfil(9) might change ifp. However, AFAIK, this doesn't happen with any filter. Also, I would assert that we should not leave such possibility. Look, we already did some ifp checks before pfil_run_hooks() and the packet passed this checks. If the interface changes, what should we do? Any legitimate reason for pkthdr.rcvif to change is decapsulation and thus arrival on some tunnel interface. This decapsulation is never performed by pfil(9) filter. If somebody wants to create such decapsulation as a pfil(9) filter, they shall pass decapsulated packet to netisr, not return it back to ip_input(). In this case decapsulated packet would be processed with correct new rcvif by new invocation of ip_input.
Comment Actions
I've not gone digging to find out why pfil(9) assumed rcvif could change, but I follow Gleb's reasoning. There doesn't seem to be any reason why a firewall might want to change it.
pf and ipfw don't change it (although they do sometimes set it for packets they generate, but that's not relevant for this change), and ipf never even looks at it, so this change is safe.