Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Aug 2016 12:36:56 +0800
From:      Julian Elischer <>
To:        Ian Smith <>
Cc:        "Andrey V. Elsukov" <>,,, "Alexander V. Chernikov" <>
Subject:   Re: IPFW: more "orthogonal? state operations, push into 11?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <> <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 5/08/2016 2:14 AM, Ian Smith wrote:
> On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote:
>   > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote:
>   > > On 04.08.16 06:42, Julian Elischer wrote:
>   > > > so it's a combination of #1 and #2 in my list.  I think I originally
>   > > > thought of having just #1.
>   > > >
>   > > > A combination is less useful for me as you need to do:
>   > > >
>   > > > 20 skipto 400 tcp from table(2) to me setup record-state
>   > > > 21 skipto 400 tcp from table(2) to me setup
>   > > > to make the entire session do the same thing.
>   > > So, in your example what wrong with just using keep-state?
>   > > "record-state without immediate action" == "keep-state without implicit
>   > > check-state" needed to solve issues with NAT or something similar, that
>   > > was described by Lev.
>   > >
>   > because keep-state is a check-state for ALL packets going past, regardless of
>   > whether they match the pattern.
>   >
>   > at least that's what I have observed.
> Except now(?) with named states/flows/whatever, isn't it the case that
> check-state [flowname] only affects packets with same state/flowname? So
> you can clearly separate, say, packets on different interfaces, packets
> coming or going on any interface, and such?
> If I'm understanding that right - quite possibly not! - then only those
> packets will match, and others with other names (including 'default')
> won't match states with that name.  I'm not sure I'm expressing this at
> all well, because I'm only just starting to get any sort of grip, but
> I'm liking the idea and wondering if it's sufficient for starters.
wellll  not quite..
Only the given state table will be looked at, but all packets will 
still be matched with it.

> To me, orthogonality implies the least number of commands/instructions
> that will accomplish the desired functionality.  First, let's find out
> what can and cannot be accomplished with named states/flows .. I'm yet
> to understand what record-state-without-action can accomplish apart from
> that .. it could work only for the first packet I suppose, since once
> state is established, further packets will match and follow state, no?
> Again, I find concrete examples - like the use of valtype skipto,fib
> mentioned above - really helpful, essential really, for bears of such
> little brain as I ..
ok, so sometimes I like to do some processing on a packet (e.g. divert 
it somewhere for munging) after I've set up a state for it.
so I don't want to necessarily Act on the state immediately.  but the 
packet may get changed in the munging, so I need to set the state 
before hand., or I can't match it.

here's a real example that I couldn't do because I couldn't
store  a state without actually doing it.
I wanted all packets from a process on the local machine (identified 
it has a unique group, used for just this purpose) to be forwarded to a
particular other machine for "vetting',  however the machine I am doing
this has outgoing NAT using a modified natd that also does some added 
After the NAT I can no longer recognise the packets that came from 
that process
as they moved out of the kernel to userland and back, yet I still need 
ackets to go through the natd.
So I need to identify them first, before the nat in order to set a 
state entry for
them.   Since they are local packets NAT will not have changed their 
so  AFTER the NAT I could have done the associated check-state which 
the stored  action (forwarding to another location).

I ended up having to do this via an ugly use of skiptos where packets
I wanted to forward, were identified early and then sent to a 
duplicate set of
rules which also did the divert,  but then did the forward. I think 
there were
about 25 rules duplicated.

Having said that, "store without do" is the least important of the 
Store (do or not) without a prior checkstate is more important to me.

state name are a wonderful addition that I have yet to use in all my 
I just haven't had time yet.

> cheers, Ian

Want to link to this message? Use this URL: <>