Bug 222768 - ipfw can't distinguish an inbound packets forwarded via if_bridge
Summary: ipfw can't distinguish an inbound packets forwarded via if_bridge
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.1-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ipfw mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2017-10-04 08:01 UTC by Alexander Zagrebin
Modified: 2017-10-07 22:04 UTC (History)
1 user (show)

See Also:


Attachments
patch (1.59 KB, patch)
2017-10-04 08:01 UTC, Alexander Zagrebin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Zagrebin 2017-10-04 08:01:09 UTC
Created attachment 186898 [details]
patch

By default (when net.link.bridge.pfil_bridge=1), the packet, forwarded via if_bridge, has to be processed by ipfw 4 times. Suppose such configuration:

em0 <-> bridge0 <-> em1

ipfw will process packet, forwarded from em0 to em1, in the following sequence:
in[em0], in[bridge0], out[bridge0], out[em1].

We can expect, that inbound packets can be matched with the following ipfw rule options:

in[em0]     - 'in recv em0' or 'in via em0'
in[bridge0] - 'in via bridge0'

For example,

ipfw add 1 count ip from any to any in via em0
ipfw add 2 count ip from any to any in via bridge0

but this doesn't work as expected: each single packet matches 2 times to the rule 1 and not matches to the rule 2 at all.

The reason in the following: despite that if_bridge sends information about corresponding interface to the pfil_run_hooks(), the ipfw doesn't uses it while processing inbound packets.

The attached patch fixes issue:
If the interface on which ipfw processes packet does not match an 'received' interface, then this interface saved and used later in the processing of 'via' rule option.