On 29.11.2007, at 16:00, Sterling Windmill wrote:
> If I disable and re-enable traffic shaping I see a few extra
> entries in the firewall states that seem to be valid, but no new
> entries show up afterwards.
> I have also verified that traffic shaping does not seem to be
> working, as I have added a small pipe and corresponding rules to
> shape traffic originating from my PC behind the m0n0wall and PIX
> and see no change in throughput.
> Has anyone else experienced problems with 1.3b5 filtering bridge/
> traffic shaper perhaps specifically on the new ALIX hardware?
You're right - on the 1.3b versions, enabling the traffic shaper (or
the captive portal, for that matter) while the filtering bridge is
enabled causes bridged packets not to be filtered.
I've investigated the cause of this issue in the FreeBSD kernel, and
after figuring out why this happens, I searched for FreeBSD PRs. I
was quite surprised when I found one of my own, submitted more than
two years ago, about the exact same issue (but in 5.3-RELEASE):
The problem was introduced with pfil hooks in FreeBSD - since ipfw
also registers a pfil hook, but needs to be called separately from
within BRIDGE code to handle dummynet properly, they just put in a
quick fix to prevent IPFW from running twice. However, that fix
simply jumps over any pfil hooks when bridging if ipfw is loaded
(therefore also circumventing ipfilter).
Apparently nobody cared, and the fix is not trivial... The fact that
BRIDGE has been deprecated in favor of if_bridge probably won't help
getting somebody to fix this issue either. I can try to do it myself,
but to be honest, I'm not that much of a kernel hacker.
The other alternative would be to convert m0n0wall to use if_bridge -
speak up, volunteers! ;)
In the meantime, I've put a notice on http://m0n0.ch/wall/
beta-1.3.php about this issue.
Note that the traffic shaper works properly with (non-filtering)
bridging in 1.3b, but behavior is slightly different from traffic
shaping in normal (routing) mode: as packets are only passed through
the shaper once (on input) when bridging (as opposed to both on input
and output when routing), your traffic shaper rules need to reflect
the fact that they can only match on input (i.e. "direction: out"
will never match for bridged packets). However, this has always been
the case in m0n0wall and is not specific to 1.3b.