On Mon, Dec 11, 2023 at 9:44 AM Stuart Henderson wrote:
>
> There is a working amd64 package from the previous bulk build at
> https://spacehopper.org/mirrors/firefox-120.0.1.tgz
>
> It is just from a backup of the normal packages not a local build, so
> you should expect the signature will
There is a working amd64 package from the previous bulk build at
https://spacehopper.org/mirrors/firefox-120.0.1.tgz
It is just from a backup of the normal packages not a local build, so
you should expect the signature will verify. You should be able to
install by downloading and "pkg_add -D
I've just tested with "block return" instead of "block drop".
The result is the same. In fact, in man pf.conf I see:
max number
Limits the number of concurrent states the rule may create.
When this limit is reached, further packets that would create
state are dropped until existing
On Mon, Dec 11, 2023 at 8:39 AM Matthias Schmidt wrote:
>
> Hi Claudio,
>
> * Claudio Miranda wrote:
> > Hello,
> >
> > I just updated all my packages on both my OpenBSD 7.4-current systems
> > (also updated to the latest snapshot) and I notice that Firefox is not
> > launching. It spits out the
Hi Claudio,
* Claudio Miranda wrote:
> Hello,
>
> I just updated all my packages on both my OpenBSD 7.4-current systems
> (also updated to the latest snapshot) and I notice that Firefox is not
> launching. It spits out the following error when I launch it from the
> terminal.
>
> XPCOMGlueLoad
Hello,
I just updated all my packages on both my OpenBSD 7.4-current systems
(also updated to the latest snapshot) and I notice that Firefox is not
launching. It spits out the following error when I launch it from the
terminal.
XPCOMGlueLoad error for file
On Mon, Dec 11, 2023 at 10:58:22AM +0100, Alexandr Nedvedicky wrote:
> dlg@ and I are basically trying to remove all NET_LOCK() operations from
> pf(4), because we don't want pf(4) to be playing with global NET_LOCK().
> all callers to pf(4) should either obtain NET_LOCK() in case they
On Mon, Dec 11, 2023 at 02:47:49PM +0300, Vitaliy Makkoveev wrote:
> Hi,
>
> > On 11 Dec 2023, at 12:58, Alexandr Nedvedicky wrote:
> >
> >on the other hand if there is a way to implement pflowif_list as
> > lock-less
> >(or move it ouf of NET_LOCK() scope), then this is a preferred
Hi,
> On 11 Dec 2023, at 12:58, Alexandr Nedvedicky wrote:
>
>on the other hand if there is a way to implement pflowif_list as lock-less
>(or move it ouf of NET_LOCK() scope), then this is a preferred way
>forward.
So, I’m going to commit the diff which turns pflowif_list into SMR
Hello,
On Sat, Dec 09, 2023 at 03:10:02AM +0300, Vitaliy Makkoveev wrote:
> On Sat, Dec 09, 2023 at 12:28:10AM +0100, Alexander Bluhm wrote:
> > On Sat, Dec 09, 2023 at 02:07:06AM +0300, Vitaliy Makkoveev wrote:
> > > > > SLIST_ENTRY(pflow_softc) sc_next;
> > > >
> > > > This list is
Seems like you might want to use "return" on your block rule.
--
Sent from a phone, apologies for poor formatting.
On 10 December 2023 20:15:36 Luca Di Gregorio wrote:
Hi, in my /etc/pf.conf I have the line:
set skip on lo
That is why the rules of my previous email don't work.
If I comment
11 matches
Mail list logo
