16 января 2020 г. 9:14:43 GMT+03:00, Theo de Raadt пишет:
>I'll bite, using text from your regress.
>
>> +pass out proto tcp all user 1234:12345 flags S/SA
>> +pass out proto tcp all user 0:12345 flags S/SA
>> +pass out proto tcp all group 1234:12345 flags S/SA
>> +pass out proto tcp all group 0:1
I'll bite, using text from your regress.
> +pass out proto tcp all user 1234:12345 flags S/SA
> +pass out proto tcp all user 0:12345 flags S/SA
> +pass out proto tcp all group 1234:12345 flags S/SA
> +pass out proto tcp all group 0:12345 flags S/SA
What does 1234:12345 mean. It must be uid 1234
Hi all.
I've just found that pfctl doesn't like 'X:Y' syntax for user and group
clauses, despite of the words in manpage. The problem is caused by
parser eating the colon character in STRING version of "uid" and "gid"
rules. The solution is similar to the way ports parsing is done. Now we
have "ui
Hello,
On Thu, Jan 16, 2020 at 12:15:39AM +0100, Klemens Nanni wrote:
> There is no reason to continue on anchor specific paths if the given
> anchor does not exist, so fix the last occurences better error messages:
>
> # pfctl -a regress\* -Fa
> Anchor 'regress' not found.
> p
There is no reason to continue on anchor specific paths if the given
anchor does not exist, so fix the last occurences better error messages:
# pfctl -a regress\* -Fa
Anchor 'regress' not found.
pfctl: pfctl_get_anchors failed to retrieve list of anchors, can't
continue
On Wed, Jan 15, 2020 at 11:12:46PM +0100, Alexandr Nedvedicky wrote:
> rename pfr_strerror() to pf_strerror() and move it from pfctl_radix.c
> to pfctl.c as it becomes more generic now.
Yes, makes sense; "pfr" is not the appropiate namespace here.
Hello,
> There are other occasions as well but those probably need additional
> tweaks, so here's the first round.
>
> Feedback? OK?
I like the idea. Just have one 'bike shedding' suggestion:
rename pfr_strerror() to pf_strerror() and move it from pfctl_radix.c
to pfctl.c
Hi all.
This fixes an issue I'm seeing with a uvideo(4), that doesn't like
commands we're sending to it. The camera simply sends nothing,
and since we're sleeping forever (xfer timeout is 0, which is
USBD_NO_TIMEOUT), we never get out from 'while (bulk_running)' loop,
visible in the scond chunk of
On Wed, Jan 15, 2020 at 07:41:46PM +, Stuart Henderson wrote:
> On 2020/01/14 21:48, Stuart Henderson wrote:
> > > while ((c = getopt(argc, argv, "6dD:nf:vSTt")) != -1) {
> > > switch (c) {
> > > case '6':
> > > - opts |= IKED_OPT_NOIPV6BLOCKING;
> > > +
I strongly agree that we should avoid use of the word 'deprecated'
towards the public. People interpret what it means differently,
so try to be EXACT.
'deprecated' is our choice to make the change, but 'ignored' is
the result of that decision upon the people.
Stuart Henderson wrote:
> On 2020/
On 2020/01/14 21:48, Stuart Henderson wrote:
> > while ((c = getopt(argc, argv, "6dD:nf:vSTt")) != -1) {
> > switch (c) {
> > case '6':
> > - opts |= IKED_OPT_NOIPV6BLOCKING;
> > + log_warnx("the -6 option is deprecated and will be "
>
According to pf(4) all of DIOCGETRULE, DIOCGETRULES and DIOCGETRULESET
return EINVAL if the specified anchor does not exist; I double checked
pf_ioctl.c to verify.
This diff makes pfctl consistently use pfr_strerror() which now handles
EINVAL such that
# pfctl -a nope -sr
pfctl:
On Wed, Jan 15, 2020 at 11:08:04AM +0100, Martin Pieuchot wrote:
> On 14/01/20(Tue) 18:37, Scott Cheloha wrote:
> > Ticks to milliseconds.
> > [...]
> > @@ -303,16 +304,17 @@ lptpushbytes(struct lpt_softc *sc)
> > while (NOT_READY()) {
> > if (++spin
On Wed, Jan 15, 2020 at 04:44:55PM +0100, Klemens Nanni wrote:
> While code in pf/pfctl confusingly uses either anchor or ruleset
> depending on the context, pfctl(8) (both manual and user interface)
> should be consistent. There should be no difference between anchor and
> ruleset for users, impl
On 2020/01/15 12:04, Janne Johansson wrote:
> Den ons 15 jan. 2020 kl 11:57 skrev Christopher Zimmermann <
> chr...@openbsd.org>:
>
> > So I propose to send IPv6 advertisements only when IPv4 is not possible.
> >
> > Why?
> >
> > - Noise can be reduced by using unicast advertisements.
> >This
While code in pf/pfctl confusingly uses either anchor or ruleset
depending on the context, pfctl(8) (both manual and user interface)
should be consistent. There should be no difference between anchor and
ruleset for users, implying there is one only makes for confusion:
# pfctl -a regress
Some of those tweaks were mentioned first in
https://marc.info/?l=openbsd-tech&m=157672366409171&w=2
* Fix setjmp vs volatile usage:
- "buf" shouldn't be modified after setjmp, else we break the setjmp
contract:
--8<--
All accessible objects have values as of the time the longjmp() routi
On Wed, Jan 15, 2020 at 04:26:20PM +0100, Klemens Nanni wrote:
> Less nesting for clearer code.
>
> OK?
>
> The macro backslashes got adjusted but diff with `-w' for ease of review.
>
OK sashan
Less nesting for clearer code.
OK?
The macro backslashes got adjusted but diff with `-w' for ease of review.
Index: pfctl_table.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_table.c,v
retrieving revision 1.82
diff -u -p -w -r1.82 pfctl_
More specifically, I'm running with this patch
The specific choice of keywords to deprecate is up for grabs, the
infrastructure for actually being able to error out on these keywords is
probably something I should commit anyhow.
diff --git a/gnode.h b/gnode.h
index 283fead..04e5462 100644
---
On 14/01/20(Tue) 17:30, Martin Pieuchot wrote:
> On 14/01/20(Tue) 10:34, Jonathan Gray wrote:
> > On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > > I'm facing a lock ordering issue while profiling the scheduler which
> > > cannot be solved without using a different lock for the
Christopher Zimmermann(chr...@openbsd.org) on 2020.01.15 11:55:43 +0100:
> Hi,
>
> as far as I can see a dual stack carp interface does not care whether it
> receives advertisements addressed to IPv4 or IPv6. Any one will do.
> So I propose to send IPv6 advertisements only when IPv4 is not possib
On January 15, 2020 12:04:56 PM GMT+01:00, Janne Johansson
wrote:
>Den ons 15 jan. 2020 kl 11:57 skrev Christopher Zimmermann <
>chr...@openbsd.org>:
>
>> So I propose to send IPv6 advertisements only when IPv4 is not
>possible.
>>
>> Why?
>>
>> - Noise can be reduced by using unicast advertis
Den ons 15 jan. 2020 kl 11:57 skrev Christopher Zimmermann <
chr...@openbsd.org>:
> So I propose to send IPv6 advertisements only when IPv4 is not possible.
>
> Why?
>
> - Noise can be reduced by using unicast advertisements.
>This is only possible for IPv4 by ``ifconfig carppeer``.
>I don
Hi,
as far as I can see a dual stack carp interface does not care whether it
receives advertisements addressed to IPv4 or IPv6. Any one will do.
So I propose to send IPv6 advertisements only when IPv4 is not possible.
Why?
- Noise can be reduced by using unicast advertisements.
This is only
On 14/01/20(Tue) 18:37, Scott Cheloha wrote:
> Ticks to milliseconds.
> [...]
> @@ -303,16 +304,17 @@ lptpushbytes(struct lpt_softc *sc)
> while (NOT_READY()) {
> if (++spin < sc->sc_spinmax)
> continue;
> -
26 matches
Mail list logo
