On 2021/01/26 09:29, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > >
> > > I'm not sure if proposed scenario real. Let's assume there
> > > is a PF box with three NICs running on this awkward set up
> > >
> > > em1 ... 192.168.1.10
> > >
> > > em0
> > >
> > >
Hello,
On Tue, Jan 26, 2021 at 12:33:25PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > > But what about dup-to? The packet is duplicated for both directions.
> > > I guess the main use case for dup-to is implementing a monitor port.
> > >
On Tue, Jan 26, 2021 at 12:33:25PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > > But what about dup-to? The packet is duplicated for both directions.
> > > I guess the main use case for dup-to is implementing a monitor port.
> > > There you
On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > But what about dup-to? The packet is duplicated for both directions.
> > I guess the main use case for dup-to is implementing a monitor port.
> > There you have to pass packets stateless, otherwise it would not
> > work anyway.
Hello,
On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> On Mon, Jan 25, 2021 at 04:19:11PM +0100, Alexander Bluhm wrote:
> > On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote:
> > > --- sys/conf/GENERIC 30 Sep 2020 14:51:17 - 1.273
> > > +++
Hello,
> > > goto bad;
> >
> > here we do 'goto bad', which does not call if_put().
>
> yes it does. the whole chunk with the diff applied is:
>
> done:
> if (s->rt != PF_DUPTO)
> pd->m = NULL;
> if_put(ifp);
> rtfree(rt);
>
Hello,
>
> i'll need help with "match on em0 route-to $if_em0_peer". or we can do
> that later separately?
may be can we keep this line in pf_route() untouched at least for now:
6041
6042 if (pd->kif->pfik_ifp != ifp) {
6043 if (pf_test(AF_INET, PF_OUT, ifp, ) !=
Hello,
> >
> >
> > I'm not sure if proposed scenario real. Let's assume there
> > is a PF box with three NICs running on this awkward set up
> >
> > em1 ... 192.168.1.10
> >
> > em0
> >
> > em2 ... 192.168.1.10
> >
> > em0 is attached
On Mon, Jan 25, 2021 at 05:38:40PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > Some personal thoughts. I am happy when pf route-to gets simpler.
> > Especially I have never understood what this
On Mon, Jan 25, 2021 at 06:17:02PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> pf_route() might leak a refence to ifp.
oh no :(
> > Index: sys/net/pf.c
> > ===
> > RCS file: /cvs/src/sys/net/pf.c,v
> > retrieving revision 1.1101
On Mon, Jan 25, 2021 at 04:19:11PM +0100, Alexander Bluhm wrote:
> On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote:
> > --- sys/conf/GENERIC30 Sep 2020 14:51:17 - 1.273
> > +++ sys/conf/GENERIC22 Jan 2021 07:33:30 -
> > @@ -82,6 +82,7 @@ pseudo-device
On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Some personal thoughts. I am happy when pf route-to gets simpler.
> Especially I have never understood what this address@interface
> syntax is used for.
even after staring at it for so long, i still don't get it. i do
On Mon, Jan 25, 2021 at 02:30:46PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
...
> >
> > i dont understand the kif lifetimes though. can we just point a
> > pdesc at an arbitrary kif or do we need ot reference count?
> >
>
> as long as we don't release NET_LOCK() (or PF_LOCK() in
Hello,
pf_route() might leak a refence to ifp.
> Index: sys/net/pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1101
> diff -u -p -r1.1101 pf.c
> --- sys/net/pf.c 19 Jan 2021 22:22:23 - 1.1101
>
Hello,
On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Some personal thoughts. I am happy when pf route-to gets simpler.
> Especially I have never understood what this address@interface
> syntax is used for.
>
> I cannot estimate what configuration is used by our
hello,
>
> > +pf_route(struct pf_pdesc *pd, struct pf_state *s)
> ...
> > + if (pd->dir == PF_IN) {
> > if (pf_test(AF_INET, PF_OUT, ifp, ) != PF_PASS)
>
> Yes, this is the correct logic. When the packet comes in, pf
> overrides forwarding, tests the out rules, and sends it.
On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote:
> --- sys/conf/GENERIC 30 Sep 2020 14:51:17 - 1.273
> +++ sys/conf/GENERIC 22 Jan 2021 07:33:30 -
> @@ -82,6 +82,7 @@ pseudo-device msts1 # MSTS line discipl
> pseudo-deviceendrun 1 #
Hi,
Some personal thoughts. I am happy when pf route-to gets simpler.
Especially I have never understood what this address@interface
syntax is used for.
I cannot estimate what configuration is used by our cutomers in
many installations. Simple syntax change address@interface ->
address of next
Hello,
> >
> > If I understand the idea right, then basically 'match out on em0'
> > figures out the new 'outbound interface' so either 'pass out on em1...'
> > or
> > 'pass out on em2...' will kick in. In other words:
> >
> > depending on the destination picked up from
On Mon, Jan 25, 2021 at 01:11:35PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > > I understand that simple is better here, so I won't object
> > > if we will lean towards simplified model above. However I still
> > > would like to share my view on current PF.
> > >
> >
Hello,
> >
> > I understand that simple is better here, so I won't object
> > if we will lean towards simplified model above. However I still
> > would like to share my view on current PF.
> >
> > the way I understand how things (should) work currently is fairly
> > simple:
>
On Sun, Jan 24, 2021 at 11:51 PM David Gwynne wrote:
> On Mon, Jan 25, 2021 at 02:50:12AM +0100, Alexandr Nedvedicky wrote:
> > Hello,
> >
> > >
> > > ok. i don't know how to split up the rest of the change though.
> > >
> > > here's an updated diff that includes the rest of the kernel changes
On Mon, Jan 25, 2021 at 02:50:12AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> >
> > ok. i don't know how to split up the rest of the change though.
> >
> > here's an updated diff that includes the rest of the kernel changes and
> > the pfctl and pf.conf tweaks.
> >
> > it's probably useful
Hello,
>
> ok. i don't know how to split up the rest of the change though.
>
> here's an updated diff that includes the rest of the kernel changes and
> the pfctl and pf.conf tweaks.
>
> it's probably useful for me to try and explain at a high level what
> i think the semantics should be,
On Fri, Jan 08, 2021 at 04:43:39PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> >
> > revision 1.294
> > date: 2003/01/02 01:56:56; author: dhartmei; state: Exp; lines: +27 -49;
> > When route-to/reply-to is used in combination with address translation,
> >
Hello,
>
> revision 1.294
> date: 2003/01/02 01:56:56; author: dhartmei; state: Exp; lines: +27 -49;
> When route-to/reply-to is used in combination with address translation,
> pf_test() may be called twice for the same packet. In this case, make
> sure the
On Tue, Jan 05, 2021 at 10:05:39PM +1000, David Gwynne wrote:
> If the idea is to avoid running most of pf_test again if route-to is
> applied during ip_output, I think this tweaked diff is simpler. Is there
> a valid use case for running some of pf_test again after route-to is
> applied?
I found
Hello,
sorry to come back after while...
On Tue, Jan 05, 2021 at 10:05:39PM +1000, David Gwynne wrote:
> On Mon, Jan 04, 2021 at 06:37:54PM +0100, Alexander Bluhm wrote:
> > On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> > > this chunk pops out as a standalone change.
> > >
> >
On Mon, Jan 04, 2021 at 06:37:54PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> > this chunk pops out as a standalone change.
> >
> > having pf_find_state() return PF_PASS here means the callers short
> > circuit and let the packet go through
Hello,
On Mon, Jan 04, 2021 at 06:37:54PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> > this chunk pops out as a standalone change.
> >
> > having pf_find_state() return PF_PASS here means the callers short
> > circuit and let the packet go
On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> this chunk pops out as a standalone change.
>
> having pf_find_state() return PF_PASS here means the callers short
> circuit and let the packet go through without running it through the
> a lot of the state handling, which includes
Hello,
> My diff removes the kif here ...
>
> > > > - if (rv == 0) {
> > > > - s->rt_kif = r->route.kif;
> > > > + if (rv == 0)
> > > > s->natrule.ptr = r;
> > > > - }
>
> ... and the {}.
>
> Anyway, it should not be commited without the
On Mon, Jan 04, 2021 at 04:32:45PM +0100, Alexandr Nedvedicky wrote:
> so either rt_kif must stay for a while, or your new diff (rebased on top
> of
> stuff committed already) must be expanded by the nit pick I've sent.
The diff I sent contains this bit. I still think the merge bug is
Hello,
I'm sorry I was not clear enough in my earlier email.
On Mon, Jan 04, 2021 at 03:56:45PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 03:26:15PM +0100, Alexandr Nedvedicky wrote:
> > you refactoring diff requires a minor finishing touch to keep the
> > stuff compiling:
>
> Did
On Mon, Jan 04, 2021 at 03:26:15PM +0100, Alexandr Nedvedicky wrote:
> you refactoring diff requires a minor finishing touch to keep the
> stuff compiling:
Did I commit something that does not compile? I just made cvs
update on another machine. There it worked.
The rt_kif in pf_state still
Hello,
On Mon, Jan 04, 2021 at 01:57:24PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 11:46:16AM +0100, Alexandr Nedvedicky wrote:
> > > let's put this in and then i'll have a look. ok by me.
> > bluhm's diff is fine with me.
>
> Refactoring is commited, here is the remaining
Hello,
On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> On Mon, Jan 04, 2021 at 01:57:24PM +0100, Alexander Bluhm wrote:
> > On Mon, Jan 04, 2021 at 11:46:16AM +0100, Alexandr Nedvedicky wrote:
> > > > let's put this in and then i'll have a look. ok by me.
> > > bluhm's diff is
On Mon, Jan 04, 2021 at 01:57:24PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 11:46:16AM +0100, Alexandr Nedvedicky wrote:
> > > let's put this in and then i'll have a look. ok by me.
> > bluhm's diff is fine with me.
>
> Refactoring is commited, here is the remaining kernel diff
On Mon, Jan 04, 2021 at 11:46:16AM +0100, Alexandr Nedvedicky wrote:
> > let's put this in and then i'll have a look. ok by me.
> bluhm's diff is fine with me.
Refactoring is commited, here is the remaining kernel diff after merge.
bluhm
Index: net/if_pfsync.c
> On 4 Jan 2021, at 9:27 pm, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
> there is one more thing, which just came up on my mind.
>
>
>>
>> so i want to change route-to in pfctl so it takes a nexthop instead
>> of an interface. you could argue that pf already lets you do this,
>> because
Hello,
there is one more thing, which just came up on my mind.
>
> so i want to change route-to in pfctl so it takes a nexthop instead
> of an interface. you could argue that pf already lets you do this,
> because there's some bs nexthop@interface syntax. my counter argument
> is that the
Hello,
>
> the stack should provide it on a 4 byte boundary, but it has uint64_t
> members. however, it is also __packed, so the compiler makes no
> assumptions about alignment.
>
> > Is there anything else that can be split out easily?
>
> let's put this in and then i'll have a look. ok by
On Mon, Jan 04, 2021 at 12:58:17AM +0100, Alexander Bluhm wrote:
> On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote:
> > I am currently running a full regress to find more fallout.
>
> These regress tests fail:
>
> sys/net/pf_forward
> sys/net/pf_fragment
> sbin/pfctl
>
> The
On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote:
> On Sun, Jan 03, 2021 at 02:00:00PM +1000, David Gwynne wrote:
> > On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote:
> > We've been running this diff in production for the last couple of
> > months, and it's been solid
On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote:
> I am currently running a full regress to find more fallout.
These regress tests fail:
sys/net/pf_forward
sys/net/pf_fragment
sbin/pfctl
The first two are easy to fix. That means my tests using route-to
work fine with your diff.
On Sun, Jan 03, 2021 at 02:00:00PM +1000, David Gwynne wrote:
> On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote:
> We've been running this diff in production for the last couple of
> months, and it's been solid for us so far. Ignoring the fixes for
> crashes, I personally find it a
On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote:
>
> i am feeling very warm and fuzzy about this diff at the moment.
We've been running this diff in production for the last couple of
months, and it's been solid for us so far. Ignoring the fixes for
crashes, I personally find it a
On Mon, Oct 19, 2020 at 12:33:25PM +0100, Stuart Henderson wrote:
> On 2020/10/19 19:53, David Gwynne wrote:
> > On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > > On 2020/10/19 15:35, David Gwynne wrote:
> > > > every few years i try and use route-to in pf, and every time it
On 2020/10/19 19:53, David Gwynne wrote:
> On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > On 2020/10/19 15:35, David Gwynne wrote:
> > > every few years i try and use route-to in pf, and every time it
> > > goes badly. i tried it again last week in a slightly different
> > >
On Mon, Oct 19, 2020 at 12:28:19PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > > it seems to me 'route-to vs. pfsync' still needs more thought. the
> > > next-hop IP address in route-to may be different for each PF box
> > > linked by pfsync(4). To be honest I have no
Hello,
> >
> > it seems to me 'route-to vs. pfsync' still needs more thought. the
> > next-hop IP address in route-to may be different for each PF box
> > linked by pfsync(4). To be honest I have no answer to address this
> > issue at the moment.
>
> i have thought about that
On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> On 2020/10/19 15:35, David Gwynne wrote:
> > every few years i try and use route-to in pf, and every time it
> > goes badly. i tried it again last week in a slightly different
> > setting, and actually tried to understand the
On Mon, Oct 19, 2020 at 09:46:19AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> disclaimer: I have no chance to run pfsync on production, I'm very
> inexperienced with pfsync(4).
i wrote the defer code in pfsync, and i think i wrote the code in
pfsync that calls pf_route badly, so noones
On 2020/10/19 15:35, David Gwynne wrote:
> every few years i try and use route-to in pf, and every time it
> goes badly. i tried it again last week in a slightly different
> setting, and actually tried to understand the sharp edges i hit
> this time instead of giving up. it turns out there are 2
Hello,
disclaimer: I have no chance to run pfsync on production, I'm very
inexperienced with pfsync(4).
>
> the third problem is that pf_route relies on information from rules to
> work correctly. this is a problem in a pfsync environment because you
> cannot have the same ruleset on both
every few years i try and use route-to in pf, and every time it
goes badly. i tried it again last week in a slightly different
setting, and actually tried to understand the sharp edges i hit
this time instead of giving up. it turns out there are 2 or 3
different things together that have cause me
56 matches
Mail list logo
