On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:
> On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > Hiltjo Posthuma wrote:
> >
> > > Hi,
> > >
> > > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> > >
> > > 1. I noticed when applyin
On Mon, Sep 02, 2019 at 12:43:18AM +0200, Tobias Heider wrote:
> The VMD_DISK_INVALID error code is no longer used since
> https://marc.info/?l=openbsd-cvs&m=153147762830175 and
> can be removed.
>
> Ok?
>
> Index: vmctl/vmctl.c
> ==
Does not run input command by vi editor with vi mode.
I do the following:
1. set vi mode.
$ echo "bind -v" > ~/.editrc
2. launch /usr/bin/ftp command.
$ ftp
3. launch vi editor with ESC + v.
ftp> ESC + v
4. input "help" in vi editor.
i + help + ESC + :wq
5. then 'help' command doe
On Mon, Sep 02, 2019 at 04:47:32PM +0200, Stefan Fritsch wrote:
> Tested with a BCM57412
>
> OK?
ok jmatthew@
>
> diff --git a/sys/dev/pci/if_bnxt.c b/sys/dev/pci/if_bnxt.c
> --- a/sys/dev/pci/if_bnxt.c
> +++ b/sys/dev/pci/if_bnxt.c
> @@ -102,6 +102,7 @@
> #define BNXT_FLAG_NPAR 0x000
If the NIC is in some error state during device attach (seen on a i219LM
when em_read_phy_reg_ex() returns at "MDI Error"), it can happen that we
loop endlessly because the loop variable is modified again down in the
call stack:
em_match_gig_phy() -> em_read_phy_reg() -> em_access_phy_reg_hv()
The following diff introduces the junk action which allows builtin
filters to junk a session or transaction.
The following would junk a session if it doesn't have rdns when it
reaches the helo filtering hook:
match "check-rdns" phase helo match !rdns junk
Currently this is not doable so bui
committed thanks !
August 31, 2019 1:57 PM, "Ross L Richardson" wrote:
> ...unless I'm very mistaken!
>
> Ross
>
>
> Index: smtpc.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/smtpc.c,v
> retrieving revision 1.6
> diff -u -p -r
September 2, 2019 9:15 PM, "Martijn van Duren"
wrote:
> On 9/2/19 9:10 PM, gil...@poolp.org wrote:
>
>> September 2, 2019 7:29 PM, "Martijn van Duren"
>> wrote:
>>
>>> On 9/2/19 6:00 PM, gil...@poolp.org wrote:
>>
>> September 2, 2019 5:55 PM, gil...@poolp.org wrote:
>>
>> September 2, 201
On 9/2/19 9:10 PM, gil...@poolp.org wrote:
> September 2, 2019 7:29 PM, "Martijn van Duren"
> wrote:
>
>> On 9/2/19 6:00 PM, gil...@poolp.org wrote:
>>
>>> September 2, 2019 5:55 PM, gil...@poolp.org wrote:
>>>
September 2, 2019 5:23 PM, "Martijn van Duren"
wrote:
>>>
>>> Gilles shou
September 2, 2019 7:29 PM, "Martijn van Duren"
wrote:
> On 9/2/19 6:00 PM, gil...@poolp.org wrote:
>
>> September 2, 2019 5:55 PM, gil...@poolp.org wrote:
>>
>>> September 2, 2019 5:23 PM, "Martijn van Duren"
>>> wrote:
>>
>> Gilles should probably elaborate, but the way things are now is t
On Mon, Sep 02, 2019 at 07:26:27AM +0200, Otto Moerbeek wrote:
> On Sun, Sep 01, 2019 at 05:01:55PM -0300, Rafael Neves wrote:
>
> > On Wed, Aug 28, 2019 at 03:39:17PM +0200, Otto Moerbeek wrote:
> > > On Sat, Aug 17, 2019 at 12:13:50PM -0300, Rafael Neves wrote:
> > >
> > > > Hi,
> > > >
> > >
On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> Hiltjo Posthuma wrote:
>
> > Hi,
> >
> > I have three questions regarding a behaviour of syspatch(8) with mtree(8).
> >
> > 1. I noticed when applying patches it resets some permissions of new, but
> > also of
> > existing direct
Hiltjo Posthuma wrote:
> Hi,
>
> I have three questions regarding a behaviour of syspatch(8) with mtree(8).
>
> 1. I noticed when applying patches it resets some permissions of new, but
> also of
> existing directories on the system using mtree(8).
>
> In the shellscript syspatch(8) there is
Hi,
I have three questions regarding a behaviour of syspatch(8) with mtree(8).
1. I noticed when applying patches it resets some permissions of new, but also
of
existing directories on the system using mtree(8).
In the shellscript syspatch(8) there is a function:
trap_handler():
# in c
On 9/2/19 6:00 PM, gil...@poolp.org wrote:
> September 2, 2019 5:55 PM, gil...@poolp.org wrote:
>
>> September 2, 2019 5:23 PM, "Martijn van Duren"
>> wrote:
>>
>>> Gilles should probably elaborate, but the way things are now is that
>>> system(3) is used to start the filters, allowing us to run
Hi,
The command line handling code in less/cmdbuf.c is very complicated.
>From the top level function cmd_char(), the stack can go down nine levels
before finally reaching the bottom level function cmd_step_common().
One of the functions traversed during that descent is the recursive
function cmd_
gil...@poolp.org wrote:
> September 2, 2019 5:23 PM, "Martijn van Duren"
> wrote:
>
> > Gilles should probably elaborate, but the way things are now is that
> > system(3) is used to start the filters, allowing us to run any arbitrary
> > (set of) command(s) as a filter.
> >
> > Since the filte
September 2, 2019 5:55 PM, gil...@poolp.org wrote:
> September 2, 2019 5:23 PM, "Martijn van Duren"
> wrote:
>
>> Gilles should probably elaborate, but the way things are now is that
>> system(3) is used to start the filters, allowing us to run any arbitrary
>> (set of) command(s) as a filter.
September 2, 2019 5:23 PM, "Martijn van Duren"
wrote:
> Gilles should probably elaborate, but the way things are now is that
> system(3) is used to start the filters, allowing us to run any arbitrary
> (set of) command(s) as a filter.
>
> Since the filters now in ports are non-interactive comma
Tested with a BCM57412
OK?
diff --git a/sys/dev/pci/if_bnxt.c b/sys/dev/pci/if_bnxt.c
--- a/sys/dev/pci/if_bnxt.c
+++ b/sys/dev/pci/if_bnxt.c
@@ -102,6 +102,7 @@
#define BNXT_FLAG_NPAR 0x0002
#define BNXT_FLAG_WOL_CAP 0x0004
#define BNXT_FLAG_SHORT_CMD 0x0008
+#define BNXT_F
> OK? Or it can be rolled into somebody else's larger "remove gcc
> from armv7" diff.
This is fine with me as-is.
This drops support for building the armv7 kernel with gcc and reduces
the difference to arm64.
I can't test this.
OK? Or it can be rolled into somebody else's larger "remove gcc
from armv7" diff.
Index: arch/armv7/conf/Makefile.armv7
=
Martijn van Duren wrote:
> Gilles should probably elaborate, but the way things are now is that
> system(3) is used to start the filters, allowing us to run any arbitrary
> (set of) command(s) as a filter.
>
> Since the filters now in ports are non-interactive commands I proposed
> to move them
Gilles should probably elaborate, but the way things are now is that
system(3) is used to start the filters, allowing us to run any arbitrary
(set of) command(s) as a filter.
Since the filters now in ports are non-interactive commands I proposed
to move them to /usr/local/libexec/smtpd, which gill
This seems really unconvenitional.
PATH is normally used by interactive commands, or scripts which want
easily accessible programs. libexec has traditionally been excluded.
The idea is that programs which need things in libexec, must hardcode
the path. Intentionally. This is a subdirectory of
With filters most likely defaulting to /usr/local/libexec/smtpd in the
near future I would like to add this as the default PATH, followed by
the usual suspects. I left the usual suspects in place because people
have shown they already implement filters in awk and probably will do
so in /bin/sh in
I just checked 100us on Pinebook one more time,
the boot process is stuck at "root on sd0a [...]" - I think it's the first
time when CPU clock is set. Lowest value (round to 100) that was working
for me was 200us.
But if you think it should be smaller (even 1us like on H3/H5 in this driver
already
> Date: Sat, 31 Aug 2019 23:51:06 +0200
> From: Krystian Lewandowski
>
> I just checked 100us on Pinebook one more time,
> the boot process is stuck at "root on sd0a [...]" - I think it's the first
> time when CPU clock is set. Lowest value (round to 100) that was working
> for me was 200us.
>
>
On 2019-09-01, Christian Weisgerber wrote:
> This removes the support for building kernels and boot loaders with
> gcc on amd64 and i386, simplifying the corresponding Makefiles.
daniel@ has objected directly to me that he'd like to continue to
be able to build the tree with ports gcc for testin
This diff adds support for the HP laserjet. The problem with this device
is that it only returns the engineid on probing, but only returns boots
and time after a packet has been send with full auth/enc.
It's not an intrusive diff and allows us to easily walk this device
without resorting to tcpdu
This diff adds support for authPriv.
diff --git a/snmp.1 b/snmp.1
index e810560..fe283a5 100644
--- a/snmp.1
+++ b/snmp.1
@@ -28,6 +28,7 @@
.Op Fl c Ar community
.Op Fl E Ar ctxengineid
.Op Fl e Ar secengineid
+.Op Fl K Ar localpriv
.Op Fl k Ar localauth
.Op Fl l Ar seclevel
.Op Fl n Ar ctxn
This diff adds support for authNoPriv.
diff --git a/Makefile b/Makefile
index 9eb684b..102582b 100644
--- a/Makefile
+++ b/Makefile
@@ -2,8 +2,8 @@
PROG= snmp
SRCS= mib.c smi.c snmp.c snmpc.c usm.c
-LDADD+=-lutil
-DPADD+=${LIBUTIL}
+LDADD+=
Here's the diff that adds initial SNMPv3 support with USM noAuthNoPriv
support.
diff --git a/Makefile b/Makefile
index 62bb556..9eb684b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.1 2019/08/09 06:17:59 martijn Exp $
PROG= snmp
-SRCS= mib
Here's a diff that restructures packet handling to allow easier addition
of SNMPv3.
diff --git a/snmp.c b/snmp.c
index 7fac777..b2d5cfc 100644
--- a/snmp.c
+++ b/snmp.c
@@ -32,6 +32,10 @@
static struct ber_element *
snmp_resolve(struct snmp_agent *, struct ber_element *, int);
+static char
Hello tech@,
I've worked hard to get SNMPv3 support for snmp(1). Here's the end
result. This mail contains the full diff for people just wanting to
test, the follow up mails will contain the incremental diffs (still
massive beasts) so they're easier to review.
I've implemented Net-SNMP's -A, -a,
35 matches
Mail list logo
