Hello Sven,
your change makes me wonder: 'what is the actual problem you are trying to
solve'?
the reason I'm asking is that latency is just one factor, which contributes to
TCP connection performance. The other factor (and perhaps more important) is to
guess amount of retransmitted data. Process
On Mon, Dec 21, 2020 at 11:34:04PM +0100, Alexander Bluhm wrote:
> Hi,
>
> A while ago we decided to pass EACCES to uerland if pf blocks a
> packet. IPv6 still has the old EHOSTUNREACH code.
>
> Use the same errno for dropped IPv6 packets as in IPv4.
>
> ok?
>
looks good to me.
OK sashan
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 me
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 inter
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 b
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.
>
> Refacto
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
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 userlan
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 thro
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.
> > >
> > >
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 transla
Hello,
looks good to me.
OK sashan
On Mon, Jan 11, 2021 at 05:49:10PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Sometimes an uid is logged in pflog(4) although the logopt of the
> rule does not specify it. Check the option again for the log rule
> in case another rule has triggered a socket look
Hello,
proposed diff follows stuff discussed here [1] (pf route-to issues). I think
we've reached a consensus to change route-to/reply-to such the only supported
option will be next-hop (and list and table of next-hop addresses).
I think bluhm@ and dlg@ have committed part of that change already
Hello,
On Fri, Jan 15, 2021 at 06:26:48PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 12, 2021 at 08:45:22PM +0100, Alexandr Nedvedicky wrote:
> > I think bluhm@ and dlg@ have committed part of that change already.
>
> I have only commited a refactoring change. Next step in kerne
Hello,
On Mon, Jan 18, 2021 at 04:47:08PM +0100, Alexander Bluhm wrote:
> Hi,
>
> pflog(4) tries to log the translated packet with rdr-to, nat-to,
> and af-to applied. Therefore it creates a mbuf chain on the stack
> with a partial copy. This might have been a good idea for plain
> IPv4 10 yea
Hello,
On Mon, Jan 18, 2021 at 07:47:56PM +0100, Alexander Bluhm wrote:
> Hi,
>
> tcpdump pflog with addresses rewritten by rdr-to, nat-to, or af-to
> is broken.
>
> 1. Fix address family of the packet in af-to rules:
>
> before:
> 19:26:37.620926 169.254.0.14 > 169.254.0.14: icmp: echo request
hello,
On Fri, Jan 22, 2021 at 05:32:47PM +1000, David Gwynne wrote:
> I tried this diff, and it broke the ability to use dynamic addresses.
> ie, the following rules should work:
>
> pass in on gre52 inet proto icmp route-to (gre49:peer)
> pass in on vmx0 inet proto icmp route-to (gre:peer)
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, other
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:
> >
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 ta
hello,
>
> > +pf_route(struct pf_pdesc *pd, struct pf_state *s)
> ...
> > + if (pd->dir == PF_IN) {
> > if (pf_test(AF_INET, PF_OUT, ifp, &m0) != PF_PASS)
>
> Yes, this is the correct logic. When the packet comes in, pf
> overrides forwarding, tests the out rules, and sends it.
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 cut
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,
> >
> >
> > 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
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, &m0) !=
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);
> return;
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
> > > +++ sys/conf/GENERIC
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.
> > > There
On Wed, Jan 27, 2021 at 11:13:12AM +1000, David Gwynne wrote:
> when pf_route (and pf_route6) are supposed to handle forwarding the
> packet (ie, for route-to or reply-to rules), they take the mbuf
> away from the calling code path. this is done by clearing the mbuf
> pointer in the pf_pdesc struct
On Wed, Jan 27, 2021 at 11:31:27AM +1000, David Gwynne wrote:
> this was discussed as part of the big route-to issues thread. i think
> it's easy to break out and handle separately now.
>
> the diff does what the subject line says. it seems to work as expected
> for me. i don't see weird state iss
Hello,
On Wed, Jan 27, 2021 at 04:41:01PM +1000, David Gwynne wrote:
> at the moment if the route is invalid, we drop the packet. this
> generates an icmp error.
>
> ok?
looks good to me.
ok sashan
>
> Index: pf.c
> ===
> RCS
Hello,
On Thu, Jan 28, 2021 at 11:47:30AM +1000, David Gwynne wrote:
> i think these code chunks are around the wrong way.
>
> pfsync may want to defer the transmission of a packet. it does this so
> it can try and get a state over to a peer firewall before a host may
> send a reply to the peer,
Hello David,
thanks for nice wrap up of the story...
>
> this change does the following:
>
> - stores the route info in the state instead of the pf rule
>
> this allows route-to to keep working when the ruleset changes, and
> allows route-to info to be sent over pfsync. there's enough spa
Hello,
On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote:
>
> however, like most things relating to route-to/reply-to/dup-to, im
> pretty sure at this point it's not used a lot, so the impact is minimal.
> a lot of changes in this space have already been made, so adding another
> simp
Hello,
> pass in on em0 from v.x.y.z/n to a.b.c.d/m \
> route-to o.p.q.r nat-to (em2)
>
> > then this needs to be converted to two rules:
> >
> > match in on em0 from v.x.y.z/n to a.b.c.d/m nat-to(em2)
> > pass in on em0 from v.x.y.z/n to a.b.c.d/m route-to o.p.q.r
>
Hello Dominik,
thanks for reporting a bug. I'll take a look at it later today.
your proposed fix re-introduces a recursion to PF, which we want to avoid,
hence we let icmp_send() to dispatch outbound ICMP response to task.
We really need to fix ip_send() such the output task will handle IP optio
Hello,
> We really need to fix ip_send() such the output task will handle IP options
> properly.
took a look at bug reported by Dominik earlier today. Looks like
there are two issues:
1) ip_insertoptions() does not update length of IP header (ip_hl)
2) ip_hl is being o
Hello,
> > 1) ip_insertoptions() does not update length of IP header (ip_hl)
> >
> > 2) ip_hl is being overridden anyway later in ip_output() called
> > by ip_send_dispatch() to send ICMP error packet out. Looks
> > like ip_send_dispatch() should use IP_RAWOUTPUT fla
Hello,
>
> You missed the initialization of ipsendraw_mq. Otherwise, ICMP with and
> without IP options work for me with the diff.
>
> I don't know how this is usually handled here and it is probably a bit
> nit-picky, but I introduced a new function to remove the duplicate code
> in ip_send_dis
Hello,
> > @@ -790,6 +795,7 @@ ip_insertoptions(struct mbuf *m, struct mbuf *opt, int
> > *phlen)
> > memcpy(ip + 1, p->ipopt_list, optlen);
> > *phlen = sizeof(struct ip) + optlen;
> > ip->ip_len = htons(ntohs(ip->ip_len) + optlen);
> > + ip->ip_hl += (optlen >> 2
Hello,
On Mon, Mar 29, 2021 at 08:44:26AM +, Schreilechner, Dominik wrote:
> Hi,
>
>
>
> > yes, you are right. below is updated diff I would like to commit.
> > >
> > > Appart from that, adding a special task seems the way to go.
> >
> > I think so too. Alternative way would be to p
Hello,
On Mon, Mar 29, 2021 at 11:56:40AM +, Schreilechner, Dominik wrote:
>
>
> > > I think the changes in ip_insertoptions() can be dropped completely,
> > > because the if-statement uses ip-ip_hl, which might not be initialized.
> >
> > yes, you are right, I think we should rather go
Hello,
On Tue, Jul 19, 2022 at 10:58:08PM +0200, Alexander Bluhm wrote:
> On Tue, Jul 19, 2022 at 07:18:54PM +0200, Moritz Buhl wrote:
> > A solution would be to move the allocation of the pf_anchor struct
> > into a pool. One final question would be regarding the size of the
> > hiwat or hardlim
Hello,
below is a final version of patch for NAT issue discussed at bugs@ [1].
Patch below is updated according to feedback I got from Chris, claudio@
and hrvoje@.
The summary of changes is as follows:
- prevent infinite loop when packet hits NAT rule as follows:
pass out on em0 from
Hello,
On Thu, Jul 21, 2022 at 11:13:28AM +0200, Moritz Buhl wrote:
> Hi tech,
>
> for the other two DIOCX ioctls syzkaller showed that it is possible
> to grab netlock while doing copyin.
>
> The same problem should exist for DIOCXCOMMIT but syzkaller didn't
> find it yet.
>
> In case anybody
Hello,
On Mon, Aug 01, 2022 at 06:37:58PM +0200, Hrvoje Popovski wrote:
> On 20.7.2022. 22:27, Alexandr Nedvedicky wrote:
> > Hello,
> >
> > below is a final version of patch for NAT issue discussed at bugs@ [1].
> > Patch below is updated according to feedback I got f
Hello,
diff looks good to me as far as I can tell.
OK sashan@
Hello,
On Wed, Aug 10, 2022 at 02:38:16PM +, Stefan Butz wrote:
> Hi everyone,
>
> this mail includes a patch to store pf rules in a red-black tree.
> Currently they are stored in a linked list.
> My system configured with 16000 rules takes about 10 minutes
> to print them out using `pfctl -
Hello,
On Thu, Aug 11, 2022 at 11:59:55AM +0200, Alexander Bluhm wrote:
> Hi,
>
> ip_fragment() and ip6_fragment() do nearly the same thing, but they
> are implemented differently.
>
> The idea of this diff is to move things around. Then only differences
> from the IP standards but not in codin
Hello,
On Thu, Aug 11, 2022 at 09:42:54PM +0200, Alexander Bluhm wrote:
> Hi,
>
> The IPv6 routing header type 0 check should modify *offp only in
> case of an error, so that the genrated icmp6 packet has the correct
> pointer. After successful return, *offp should not be modified.
makes se
Hello Stefan,
On Wed, Aug 10, 2022 at 02:38:16PM +, Stefan Butz wrote:
> Hi everyone,
>
> this mail includes a patch to store pf rules in a red-black tree.
> Currently they are stored in a linked list.
> My system configured with 16000 rules takes about 10 minutes
> to print them out using `p
Hello,
On Mon, Aug 22, 2022 at 08:45:29PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Hrvoje managed to crash the kernel in pf fragment reassembly.
>
> > r620-1# pfctl -e
> > pf enabled
> > r620-1# pfctl -f /etc/pf.conf
> > uvm_fault(0x824b9278, 0xb7, 0, 2) -> e
> > kernel: page fault trap,
surre, looks good to me.
OK sashan
On Tue, Aug 30, 2022 at 09:45:17PM +0200, Sebastian Benoit wrote:
> ok?
>
> diff --git sys/net/pf_lb.c sys/net/pf_lb.c
> index 588115cbff7..905af42e463 100644
> --- sys/net/pf_lb.c
> +++ sys/net/pf_lb.c
> @@ -519,13 +519,18 @@ pf_map_addr(sa_family_t af, struct
Hello,
diff below fixes my a tiny glitch I've introduced with
commit [1] back in May. Fortunately the impact is hardly
noticeable (I think).
The current code reads as follows:
1495 pfr_add_tables(struct pfr_table *tbl, int size, int *nadd, int flags)
1496 {
1507 for (i = 0; i < size;
Hello,
On Mon, Oct 10, 2022 at 06:52:00AM +0200, Bjorn Ketelaars wrote:
>
> (reply also send to tech@)
>
> In 2011 henning@ removed fiddling with the ip checksum of normalised
> packets in sys/net/pf_norm.c (r1.131). Rationale was that the checksum
> is always recalculated in all output paths a
On Sun, Nov 06, 2022 at 10:42:49PM +1000, David Gwynne wrote:
> this is a small chunk to help sashan@ out with some of the pf ioctl work
> he is doing.
>
> he is looking at allocating config over multiple ioctls, and would like
> to be able to throw it away in situations like if the userland progr
Hello,
>
> claudio had some questions about numbers used by the diff. some of the
> maths here is set up so that every pf state purge run is guaranteed to
> do a MINUMUM amount of work. by default pf is configured with a purge
> interfval of 10 seconds, bu the pf state purge processing runs ever
On Sun, Nov 06, 2022 at 01:06:02PM +, Klemens Nanni wrote:
> Just like bpf(4)... except bpf actually also creates bpf0 still.
>
> $ ls -1 /dev/{b,}pf*
> /dev/bpf
> /dev/bpf0
> /dev/pf
>
> OK?
looks ok to me, I think no on one expects to create /dev/pf0, /dev/pf1 .
On Sun, Nov 06, 2022 at 04:48:11PM +, Klemens Nanni wrote:
> On Sun, Nov 06, 2022 at 05:43:15PM +0100, Alexandr Nedvedicky wrote:
> > On Sun, Nov 06, 2022 at 01:06:02PM +, Klemens Nanni wrote:
> > > Just like bpf(4)... except bpf actually also creates bpf0 still.
>
Hello,
diff below is the first step to make pfioctl() _without_ NET_LOCK().
Currently pf_if.c seems to be the only blocker which prevents us
from removing all NET_LOCK()/NET_UNLOCK() calls we have in pf(4).
diff below passed very basic smoke test. OK to commit?
thanks and
regards
sashan
--
Hello,
diff below simplifies handling of 'once' rules in pf(4).
Currently matching packet marks 'once' rule as expired
and puts it to garbage collection list, where the rule
waits to be removed from its ruleset by timer.
diff below simplifies that. matching packet marks
once rule as expired and l
Hello,
resending the same diff, just updated to current.
(pointed out by dlg@)
thanks and
regards
sashan
8<---8<---8<--8<
diff --git a/sys/net/pf.c b/sys/net/pf.c
index 2c6124e74f2..6295b4eb9d7 100644
--- a/sys/net/pf.c
+++ b/sys/net/pf.c
@
Hello,
updated diff. It buys suggestions from Klemens:
pf.conf(5) section which covers once rules reads as follows:
onceCreates a one shot rule. The first matching packet marks rule as
expired. The expired rule is never evaluated then. pfctl(8)
does not r
On Wed, Nov 09, 2022 at 12:09:50AM +1000, David Gwynne wrote:
> i'm hacking on pfsync(4) at the moment, and i wasted way too much time
> wondering how i broke the pfsync ioctls after i didn't the pfsync_status
> output. turns out if you don't have a sync interface set, it skips
> output.
>
> i thi
hello,
diff below adds a mutex to pf_state. It fixes a NULL pointer dereference panic
reported by Hrvoje sometime ago [1]. Besides adding a mutex to state the diff
addresses a race between pfsync and state purge thread. What happened in this
particular case was that state expired and its state ke
Hello,
David (dlg@) asked me to shrink the scope of the change. The new diff
introduces a mutex to pf_state and adjust pf_detach_state() to utilize the
newly introduced mutex. I've also added annotation to pf_state members. The
members with '?' needs our attention. We need to verify if they are
Hello,
Diff below changes KASSERT() to if (). We have to prevent
packets to insert state to snapshot queue multiple times.
Hrvoje@ can trigger situation where state updates to pfsync
peer are more frequent than we are able to send out.
OK to go for this simple fix/workaround ?
thanks and
regards
Hello,
with state key mutex in a tree [1]. I'd like to add yet another diff.
during h2k22 David and I split original change [2] into two chunks.
OK to commit diff below?
thanks and
regards
sashan
[1] https://marc.info/?l=openbsd-cvs&m=166817856414079&w=2
[2] https://marc.info/?l=openbsd-bugs&m
Hello,
this change is required to unhook pf(4) from NET_LOCK().
therefore I'd like to get it in.
On Mon, Nov 07, 2022 at 04:51:59AM +1000, David Gwynne wrote:
>
>
> > On 7 Nov 2022, at 4:12 am, Alexandr Nedvedicky wrote:
> >
> > Hello,
> >
> > dif
Hello,
On Thu, Nov 24, 2022 at 08:51:51AM +1000, David Gwynne wrote:
> im ok with this, but you need sashan@ to ok it too. he's been working up to
> this anyway.
>
> dlg
>
> > On 24 Nov 2022, at 06:18, Vitaliy Makkoveev wrote:
> >
> > On Wed, Nov 23, 2022 at 02:59:05PM -0500, David Hill wrote
Hello Hrvoje,
On Fri, Nov 25, 2022 at 09:57:15AM +0100, Hrvoje Popovski wrote:
> Hi,
>
> I think that this is similar problem as what David Hill send on tech@
> with subject "splassert on boot"
>
> I've checkout tree few minutes ago and in there should be
> mvs@ "Remove netlock assertion within
Hello,
On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
> I just need to say that with all pf, pfsync and with pf_purge diffs
> after hackaton + this diff on tech@
> https://www.mail-archive.com/tech@openbsd.org/msg72582.html
> my production firewall seems stable and it wasn't wit
Hello,
On Thu, May 25, 2023 at 07:14:54AM +, Klemens Nanni wrote:
> On Thu, May 25, 2023 at 03:28:45AM +, Klemens Nanni wrote:
> > On Thu, May 25, 2023 at 03:20:04AM +, Klemens Nanni wrote:
> > > pfsync_in_bus() looks like the only place where the static array
> > > pf_pool_limits[] is
Hello,
On Sun, Jun 18, 2023 at 06:29:28PM -0600, Ashlen wrote:
> On Sun, 18 Jun 2023 20:35 +0200, Stephan Neuhaus wrote:
> > Hi list
> >
> > I think I have found a typo in the pf NAT FAQ here:
> > https://www.openbsd.org/faq/pf/nat.html. In the
> > "Configuring NAT" section it says:
> >
> > Th
Hello,
The new code looks much better. It's huge leap forward. I don't mind if this
big diff will get committed. Hrvoje did test the whole diff. Trying to split it
to smaller changes might bring in code which is not tested enough. We don't
know how individual pieces work independently.
I've got
Hello,
On Thu, Jun 29, 2023 at 01:48:27PM +1000, David Gwynne wrote:
> On Mon, Jun 26, 2023 at 01:16:40AM +0200, Alexandr Nedvedicky wrote:
>
> > net/if_pfsync.c
> > the diff currently uses two slices (PFSYNC_NSLICES). is there a plan to
> > scale it up?
Hello,
I went through the recent diff one more time. I could not spot
anything wrong. Also my home router was happy with it for
quite some time. Unfortunately I'm not using pfsync.
However I'm sure hrvoje@ done his best to try to make it
to crash and no luck diff survived.
Having said earlier it
Hello,
diff below updates pf(4) manpage to reflect changes [1] which
were committed earlier today.
does update to pf(4) read OK?
thanks and
regards
sashan
[1] https://marc.info/?l=openbsd-cvs&m=168848058603797&w=2
https://marc.info/?l=openbsd-cvs&m=168847042626997&w=2
8<---
Hello Jason,
thank you for taking a look. More comments in-line.
On Tue, Jul 04, 2023 at 09:03:29PM +0100, Jason McIntyre wrote:
> > @@ -48,12 +48,25 @@ and retrieve statistics.
> > The most commonly used functions are covered by
> > .Xr pfctl 8 .
> > .Pp
> > -Manipulations like loading a rule
Hello,
On Wed, Jul 05, 2023 at 11:10:11AM +0200, Alexandr Nedvedicky wrote:
>
> thanks for your help to put my update to pf(4) to shape.
> updated diff is below.
>
diff in my earlier email was wrong. this one is the right one.
sorry for extra noise.
regards
sasha
Hello,
diff below includes suggestions from jmc@ and kn@
I'll commit it later today.
thanks and
regards
sashan
8<---8<---8<--8<
diff --git a/share/man/man4/pf.4 b/share/man/man4/pf.4
index 92eeb45f657..e9d4231fe97 100644
--- a/share/man/man
Hello,
the issue has been reported by Gianni Kapetanakis month ago [1]. It took
several emails to figure out relayd(8) exists after hosts got disabled
by 'relayctl host dis ...'
The thing is that relayd(8) relies on pf(4) to create persistent
tables (PFR_TFLAG_PERSIST) as relayd requests that:
Hello,
On Tue, Aug 22, 2023 at 12:21:59AM +0200, Alexander Bluhm wrote:
> On Thu, Aug 17, 2023 at 12:02:35PM +1000, David Gwynne wrote:
> > there are links between the pcb/socket layer and pf as an optimisation,
> > and links on mbufs between both sides of a forwarded connection.
> > these links l
Hello,
On Mon, Oct 09, 2023 at 08:07:35PM +0200, Alexander Bluhm wrote:
> Hi,
>
> pf_pull_hdr() allows to pass an action pointer parameter as output
> value. This is never used, all callers pass a NULL argument. Remove
> ACTION_SET() entirely.
>
> The logic if (fragoff >= len) in pf_pull_hdr()
On Tue, Oct 10, 2023 at 02:53:15PM +0200, Alexander Bluhm wrote:
> Hi,
>
> The behaviour of the PFRULE_SRCTRACK and max_states check was
> unintentionally changed by this commit.
>
>
> revision 1.964
> date: 2016/01/25 18:49:57; author: sashan; state: Exp; lines: +
Hello,
I'm fine with it.
OK sashan
On Wed, Oct 11, 2023 at 12:28:20AM +0200, Alexander Bluhm wrote:
> Hi,
>
> If a packet is malformed, it is dropped by pf(4). The rule referenced
> in pflog(4) is the default rule. As the default rule is a pass
> rule, tcpdump prints "pass" although the packe
Hello,
> When I check my pflog files in WireShark, I note that WireShark displays
> this in the "Info" column:
>
> [pass vio0/-1]
>
yes, this can be default rule. snippet below comes from pfattach():
239 /* default rule should never be garbage collected */
240 pf_def
Hello,
I've applied diff to 7.3. it works I can paste to serial console,
hitting tab, etc.. Everything seems to work as expected.
thanks and
regards
sashan
On Mon, Oct 09, 2023 at 10:51:05AM -0400, Dave Voutila wrote:
> Looking for folks that use the serial console connection in vmd(8) and
> ex
Hello,
patch below is a fairly large change, which reduces a scope of PF_LOCK().
Whenever pf(4) needs to send state table update to its peer, it must grab
a PF_LOCK() to serialize access to internal pfsync(4) queues. The patch
below adds a mutex to every queue pfsync's queue, so PF_LOCK() is no lo
Hello,
my apologize to resend the same diff [1]. I'm not sure I got OK or not.
It can be the case the privately received OK got lost.
The change is required to allow multiple instances of pf_test() running
concurrently. Without this change in, PF trips 'KASSERT(sk->reverse == NULL);'
thanks and
Hello,
The issue has been found by Chris Cappuccio. The good news is it can not be
triggered by default. To trigger the bug one has to build kernel with
'WITH_PF_LOCK' option. PF_STATE_ENTER_WRITE(), which is no-op by default,
becomes operational, when WITH_PF_LOCK is defined.
the 'pfctl -L state
Hallo,
On Sun, Apr 12, 2020 at 07:02:43PM +0200, Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Sun, 12 Apr 2020 10:28:59 -0600
> >
> > > + if ((p->p_flag & P_SYSTEM) &&
> > > + (strncmp(p->p_p->ps_comm, "softnet", 7) == 0))
> >
> > Wow that is ugly.
>
> A better approa
Hello,
On Thu, Apr 16, 2020 at 10:57:42AM +0200, Martin Pieuchot wrote:
> On 14/04/20(Tue) 10:08, Martin Pieuchot wrote:
> > On 13/04/20(Mon) 03:20, Alexandr Nedvedicky wrote:
> > > On Sun, Apr 12, 2020 at 07:02:43PM +0200, Mark Kettenis wrote:
> > > > > From: &qu
Hello,
> That's a bug, updated diff below.
>
OK I see. the diff looks better then.
> If there's a consensus that this is a way to move forward, it would make
> sense to commit it after unlock.
>
I have not spot anything else. I think this change should go in.
OK sashan@
Hello,
the question has popped up while on recent code review of some Solaris specific
bug fixes: do we still need a code in diff below or is it OK to proceed
and commit the diff?
The chunk below uses bytes 2 and 3 to derive a scope of link local address. It
seems to me those bytes/octets are al
Hello JCA,
thanks for the pointers.
> about this specific piece of code in pfctl, but the "kame hack" is still
> here and you really want to double check before removing such chunks in
...so pfctl is the wrong place to start with removal.
thanks and
regards
sashan
Hello Jonathan,
I think it makes sense to turn it on on inbound path. we certainly
get a performance boost if HW verifies header checksums for us.
I'm not sure about outbound path. chksum offload on outbound side got killed
back in 2016 (I think). All that logic behind dealing with various HW did
Hello Yasuoka,
I'm OK with your change.
However I would like to ask you to do yet another test. I wonder if things
will eventually work on unfixed PF if rules will be constructed as follows:
pfctl -a test -t LB -T add 10.0.0.11@pair102
echo 'pass in on rdomain 102 quick proto tcp to 10
Hello,
just a quick question:
was pf(4) enabled while running those tests?
if pf(4) was enabled while those tests were running,
what rules were loaded to to pf(4)?
my guess is pf(4) was not enabled when running those tests. if I remember
correctly I could see performance boost by fa
Hello,
people who will be running pf(4) with bluhm's diff [1], may trip
one of the asserts triggered by pf_state_key_link_reverse() here:
7366 void
7367 pf_state_key_link_reverse(struct pf_state_key *sk, struct pf_state_key
*skrev)
7368 {
7369 /* Note that sk and skrev may be equal, then
1 - 100 of 619 matches
Mail list logo
