> There's no reason for this to be a tunable. It's perfectly safe to
> change this at runtime.
Well, RWTUN would have enabled both boot and runtime which is also
"perfectly safe". :)
Cheers,
Franco
___
freebsd-pf@freebsd.org mailing list
https://lis
Hi,
> On 27. Dec 2019, at 6:45 PM, Kristof Provost wrote:
>
> What are you trying to accomplish?
Some people believe that "last match" is a great metric to audit rules for
intrusion detection and all sorts ruleset optimisation and refinement.
In OPNsense the question has popped up a few times
> On 06 Oct 2016, at 3:32 PM, Kristof Provost wrote:
>
> OpenBSD seem to just always preserve the ECN bits (so there’s no dscp
> keyword).
> Perhaps we should do the same.
The following will import the OpenBSD code regarding the subject.
I retained the old manual style that is in FreeBSD to ma
> On 06 Oct 2016, at 3:32 PM, Kristof Provost wrote:
>
> On 6 Oct 2016, at 15:01, Mark Martinec wrote:
>> Just adding recognition to a parser for a couple of DSCP constants
>> to be mapped to TOS is not the solution. Keep in mind that DSCP
>> is a 6-bit field, and TOS is an 8-bit field. The rema
Hi,
> On 06 Oct 2016, at 10:10 AM, Kristof Provost wrote:
>
> On 6 Oct 2016, at 6:57, Eugene M. Zheganin wrote:
>> pf still lacks the DSCP handling, will it be difficult/expensive to add
>> this ? AFAIK ipfw got this recently.
>>
> pf has set-tos and tos keywords. What is it not letting you do?
Hi Kristof,
> On 28 Sep 2016, at 3:36 PM, Kristof Provost wrote:
>
> On 28 Sep 2016, at 13:53, Franco Fichtner wrote:
>> The main culprit of pfil not working correctly is pf's
>> route-to and reply-to (and the tag formerly known as fastroute)
>> as they woul
Hi all,
The review can be found here:
https://reviews.freebsd.org/D8058
The larger motivation is to start work to align pf with pfil
packet flow in order to make pf and ipfw more useful in
combination with each other as e.g. pf offers powerful policy-
routing and ipfw offers a multitude of dummy
