> As I understand it (I guess you've seen the other posts about this),
> some variable need to be set (which it currently isn't by default in
> m0n0wall) to allow packets to be matched by more than the first rule.
> It has been hinted that Manuel had some good reason for setting this
> variable the way he has (ie. match first rule only), what that reason
> might be I don't know?
I'm really not the expert on the details in how the traffic shaper works,
but I do know that no matter how pretty rules you construct it will be
"lossy" in some sense. This meaning that you will lose responsiveness,
bandwidth or possibly both. Another question might be that it would cost
processing power, but this is probably minimal, at least at DSL speeds.
> This should, however, be easy to change with the right cmd. line
> placed in config.xml (again, assuming there isn't some very good
> reason for not doing this with the way m0n0wall implements the shaper?)
Yep, as previously mentioned the magic word here is:
> Can you elaborate on how the shaper would work when packets can match
> more than one rule (ie.: Will the next match be done before or after
> the packet has been put through the pipe/queue specified in the first
> match? If after: Will the packet then be tested against all the rules
> again, or only those following the first matched rule? etc.)
Shaping rules are just like regular IPFW rules. If not a rule number is
specified, one will be assigned automatically with an increment of 100 (or
whatever number is set as default). All the usual commands such as skipto
works here. One thing I noticed while using the genial idea to shape on both
LAN and WAN interfaces is that you need a skipto rule for all your LAN
addresses, unless you wish to shape them too (usually you don't).
> As was recently suggested, there is a kind of workaround way to
> "simulate" re-insertion, since you could shape a packet on both the
> incomming (such as LAN) and outgoing (such as WAN) interfaces,
> allowing the packet to be matched twice. If there should turn out to
> be a problem with enabling multi-rule matching, I guess this could be
> used instead.
Actually I hadn't even thought of this. Thanks! :D
> I'd be very interested in learning a little about how to do such
> multi-match shaping, and what the benefits are?
Currently my use for it is to first create traffic weighting rules based on
the different packet information, and secondly to distribute bandwidth
evenly amongst the clients. (otherwise it would be distributed based on the
number of connections, which would make the heavy filesharers steal all the
> I'm doing something along these lines myself. Will 0-80 really be
> enough to catch all (non-datacarrying) ACK packets?
This I just stole from someone else's rules. A "clean" ACK should be
something like 5x32 bits = 20 bytes. Since the "0-80" iplen value is
specified in bytes it might even be a little too high! I haven't given this
much thought though since not many packets are in this size range, except
> Doing this too. Will a single rule for outgoing with dest. port 53
> catch all DNS queries? (I got the impression that DNS can/may use
> other ports in some cases?)
Yes. All DNS queries go TO port 53. The source port of the query is what
might use other ports. Old versions of BIND always used source port 53, but
nowadays it's just any port > 1024.
> Should there be a size limit on this rule, or are DNS packets always
> of reasonable size?
I doubt that a size limit would make sense since the risk of abuse is pretty
small. There is some implementation to tunnel IP through a DNS server by
making multiple queries containing the data but this can't be stopped by
using a size limit.
> Will this be relevant for me, if I don't run a DNS server on my LAN?
> (Other than the m0n0wall DNS forwarder, that is.)
> What about a size limit here? (ie. Can SYNs, like ACKs, carry data,
> making them unreasonably large?)
> I'm not currently running a webserver, but just out of curriosity: Why
> would I want to reject incomming ACKs in this situation? Doesn't the
> webserver need those to work optimally?
There's a thread to read about it here:
// Thomas Hertz