On 30.05.16 07:56, Julian Elischer wrote:
> On 18/05/2016 10:46 PM, Andrey V. Elsukov wrote:
>> Hi All,
>>
>> We have the patch that adds named states support to ipfw.
>
> like it and have wished for this for along time
> this allows per-interface state. Can state name be set to a variable we
> c
On 26/05/2016 6:11 PM, Dmitry Selivanov wrote:
18.05.2016 17:46, Andrey V. Elsukov пишет:
We have the patch that adds named states support to ipfw.
The idea is that we add a symbolic name-label to each dynamic state in
addition to IP addresses, protocol and ports.
This introduces new syntax for
On 18/05/2016 10:46 PM, Andrey V. Elsukov wrote:
Hi All,
We have the patch that adds named states support to ipfw.
like it and have wished for this for along time
this allows per-interface state. Can state name be set to a variable
we can set or something?
then we could have subroutines tha
18.05.2016 17:46, Andrey V. Elsukov пишет:
We have the patch that adds named states support to ipfw.
The idea is that we add a symbolic name-label to each dynamic state in
addition to IP addresses, protocol and ports.
This introduces new syntax for check-state and keep-state rules:
check-state
On 18.05.2016 17:46, Andrey V. Elsukov wrote:
> 1. Is this feature useful?
IMHO, yes.
> 2. How to commit it? Due to changed syntax it can break existing
> rulesets. Probably, we can add some mandatory prefix to state name, e.g.
> ':'.
How about simply disable names which are keywords? Like vari
Hi All,
We have the patch that adds named states support to ipfw.
The idea is that we add a symbolic name-label to each dynamic state in
addition to IP addresses, protocol and ports.
This introduces new syntax for check-state and keep-state rules:
check-state { token | default | any }
keep-st
