On Sun, 2021-11-21 at 14:58 +0100, Martijn van Duren wrote:
> On Sun, 2021-11-14 at 14:35 +, Stuart Henderson wrote:
> > On 2021/11/14 11:49, Martijn van Duren wrote:
> > > sthen@ found an issue when using this diff with netsnmp tools.
> > >
> > > The pro
* Z
> /var/log/pflog 600 3 250 * ZB "pkill -HUP -u root -U root -t -
> -x pflogd"
> /var/www/logs/access.log 644 4 *$W0 Z "pkill -USR1 -u root -U
> root -x httpd"
>
>
> -- Forwarded message -
> От: Martijn van D
On Sun, 2021-11-21 at 14:58 +0100, Martijn van Duren wrote:
> On Sun, 2021-11-14 at 14:35 +, Stuart Henderson wrote:
> > On 2021/11/14 11:49, Martijn van Duren wrote:
> > > sthen@ found an issue when using this diff with netsnmp tools.
> > >
> > > The pro
On Sun, 2021-11-14 at 14:35 +, Stuart Henderson wrote:
> On 2021/11/14 11:49, Martijn van Duren wrote:
> > sthen@ found an issue when using this diff with netsnmp tools.
> >
> > The problem was that I put the requestID in the msgID, resulting
> > in a mismatch up
On Sat, 2021-11-20 at 14:17 +, Stuart Henderson wrote:
> On 2021/11/20 10:20, Martijn van Duren wrote:
> > On Sun, 2021-11-14 at 22:30 +0100, Sebastian Benoit wrote:
> > > If there is no obvious reason (i.e. be different because you need it for a
> > > specific featu
;m not afraid of moving the other way in getaddrinfo (that AI_NUMERICHOST
is also subject to the family statement in resolv.conf), because that would
also break all current host_v6 implementations in parse.y, so that would
be an overhaul in all parse.y files anyway.
martijn@
>
> Martijn van Duren(
On Sun, 2021-11-14 at 14:08 +0100, vifino wrote:
> On Wed Nov 10, 2021 at 9:46 AM CET, Martijn van Duren wrote:
> > On Fri, 2021-10-15 at 06:13 +, Klemens Nanni wrote:
> > > On Sun, Oct 03, 2021 at 10:05:56AM +, Klemens Nanni wrote:
> > > > On Sat, Oct 02, 20
+0100, Martijn van Duren wrote:
> So here's (part of) my work from h2k21.
>
> The end-goal is to re-introduce agentx support in snmpd.
>
> Currently snmpd(8) has its varbind logic divided over 4 files:
> - snmpe.c:loop over the varbinds inside the pdu/snmp-package.
>
On Sat, 2021-11-13 at 13:23 +, Stuart Henderson wrote:
> On 2021/08/09 20:55, Martijn van Duren wrote:
> > On Mon, 2021-08-09 at 11:57 +0200, Martijn van Duren wrote:
> > >
> > > This diff fixes all of the above:
> > > - Allow any to be used res
I see no reason to keep it.
OK martijn@ if anyone wants to commit this.
On Wed, 2021-11-10 at 13:37 +0100, Jan Stary wrote:
> Why does who(1) need to setlocale()?
>
> Jan
>
>
> Index: who.c
> ===
> RCS file: /cvs/src/usr.bin
On Fri, 2021-10-15 at 06:13 +, Klemens Nanni wrote:
> On Sun, Oct 03, 2021 at 10:05:56AM +, Klemens Nanni wrote:
> > On Sat, Oct 02, 2021 at 07:03:21PM +0200, vifino wrote:
> > > On Sat Oct 2, 2021 at 6:36 PM CEST, Raf Czlonka wrote:
> > > > On Sat, Oct 02, 2021 at 02:15:53PM BST, vifino wr
Moving to tech@
On Sat, 2021-11-06 at 03:11 -0400, Allan Streib wrote:
> On OpenBSD 7.0-release, comparing the output of OpenLDAP's
> ldapsearch(1) to ldap(1) search, the ldap(1) search output is
> missing the last attribute of each directory entry.
>
> e.g. from a directory I am working on at wo
On Mon, 2021-11-01 at 18:59 +0100, Martijn van Duren wrote:
> So here's (part of) my work from h2k21.
>
And here's the diff to make regress pass again.
Index: usr.bin/snmp/Makefile
===
RCS file: /cvs/src/regr
;
+
msg->sm_pdutype = SNMP_C_RESPONSE;
snmpe_response(msg);
}
Index: snmpe.h
===============
RCS file: snmpe.h
diff -N snmpe.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ snmpe.h 1 Nov 2021 17:47:16 -
@@ -0,0 +1,25
On Fri, 2021-10-29 at 04:52 -0600, Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > > Diff below calls uname(3) only a single time and if the variables
> > > aren't snmpd.conf I simply rebuild it every time.
> >
> > I'm in two minds about this. While it's not something that will happen
> > v
On Wed, 2021-10-27 at 14:14 -0600, Todd C. Miller wrote:
> On Wed, 27 Oct 2021 17:14:28 +0100, Martijn van Duren wrote:
>
> > Trying to search for memory leaks in my new snmpd code I found some
> > harmless, but annoying ones in system from SNMPv2-MIB.
> >
> > We
On Wed, 2021-10-27 at 17:37 +0100, Stuart Henderson wrote:
> On 2021/10/27 17:14, Martijn van Duren wrote:
> > Trying to search for memory leaks in my new snmpd code I found some
> > harmless, but annoying ones in system from SNMPv2-MIB.
> >
> > We call uname(3) every
Trying to search for memory leaks in my new snmpd code I found some
harmless, but annoying ones in system from SNMPv2-MIB.
We call uname(3) every time (even if we don't even need info from
that call) and ones set we save it until forever.
Diff below calls uname(3) only a single time and if the va
Last time when this value was bumped because I ran into SNMP problems
walking net-snmp because of string based indices in USM.
This time I want to bump them one more time because I found the
definition of the upper bound RFC 2578 section 7.1.3. This makes it
easier to parse agentx messages, which a
Thanks for the detailed analysis.
diff below should fix it.
martijn@
On Sun, 2021-10-24 at 22:44 +0100, Stuart Henderson wrote:
> ooops, sorry not trondd, it was jhuldtgren who spotted it!
>
> On 2021/10/24 22:26, Stuart Henderson wrote:
> > trondd noticed a startup problem with snmpd on mips64
libagentx currently allows OIDs with a length of 0.
This isn't wrong from an agentx protocol point of view, but ber encoding
can't handle OIDs with less then 2 elements, which makes it unable to
map the values back to SNMP. netsnmp maps a null-oid to 0.0, but I don't
think we should do that.
This
This diff should be superfluous with the next diff, but I don't think
this should be left as is anyway.
It's not a big problem, since it's a static buffer and it gets
initialized by previous calls, so it's always NUL-terminated, but
it's not accurate.
OK?
martijn@
Index: ax.c
==
RFC2578 section 7.1.1:
The INTEGER type (but not the Integer32 type) may also be used to
represent integer-valued information as named-number enumerations.
RFC3416 section 2.5:
A BITS value is encoded as an OCTET STRING
So these two can go.
There's still plenty opportunity for cleanup her
Right now tcpdump prints noSuchObject/noSuchInstance/endOfMibView as
[P/x/GetRequest]/[P/x/GetNextRequest]/[P/x/GetResponse]. This is because
tcpdump doesn't treat CONTEXT for what it is: context dependent.
I'm not going to untangle this entire mess, but this diff at least gives
us a better output
We moved away from the idea of default community in all of our snmp
tools. Let's give tcpdump the same treatment so that people don't
get the wrong idea.
OK?
martijn@
Index: print-snmp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print
Thanks to benno who found the original reference to this value.
Help out some poor soul who might wander in here in the future.
OK?
martijn@
Index: print-snmp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-snmp.c,v
retrieving revis
On Thu, 2021-10-21 at 15:22 +0100, Stuart Henderson wrote:
> On 2021/10/21 15:08, Martijn van Duren wrote:
> > This one has been bothering me for a while.
> >
> > OK?
> >
> > martijn@
> >
> > Index: smi.c
> > ===
This one has been bothering me for a while.
OK?
martijn@
Index: smi.c
===
RCS file: /cvs/src/usr.sbin/snmpd/smi.c,v
retrieving revision 1.28
diff -u -p -r1.28 smi.c
--- smi.c 4 Jan 2021 07:59:54 - 1.28
+++ smi.c
ping
On Wed, 2021-09-01 at 22:51 +0200, Martijn van Duren wrote:
> Bluhm asked me to rethink the freeing strategy.
> Here's the end result.
>
> On Mon, 2021-08-30 at 12:03 +0200, Martijn van Duren wrote:
> > I missed this one before, since apparently it doesn't sho
ping
On Thu, 2021-09-09 at 21:49 +0200, Martijn van Duren wrote:
> When calling agentx_index_start we short-circuit the call to the agentx
> master when the index is dynamic. This is in accordance with the RFC.
> At the moment we don't do the same thing when calling
> agentx_
ping
On Sun, 2021-09-26 at 10:22 +0200, Martijn van Duren wrote:
> ober_get_nstring writes a pointer to buf and does not overwrite the
> content of buf itself. So pushing an array in there will result in it
> only writing the pointer address to the array, which is not exactly what
>
ping
On Fri, 2021-10-01 at 16:42 +0200, Martijn van Duren wrote:
> Right now ober_oid_cmp has inverted logic compared to other *cmp
> functions. Specifically values greater than 0 are returned when
> a is smaller than b.
> Additionally, the value of 2 is only used b is a child of a,
Right now ober_oid_cmp has inverted logic compared to other *cmp
functions. Specifically values greater than 0 are returned when
a is smaller than b.
Additionally, the value of 2 is only used b is a child of a, but
-1 is returned when a is a child of b.
This makes it harder than needed to use it w
ober_get_nstring writes a pointer to buf and does not overwrite the
content of buf itself. So pushing an array in there will result in it
only writing the pointer address to the array, which is not exactly what
we want to show.
I choose to go for sizeof, instead of using the define to be a little
On Sat, 2021-09-11 at 04:05 +0300, Vitaliy Makkoveev wrote:
> On Fri, Sep 10, 2021 at 07:40:58PM +0200, Alexander Bluhm wrote:
> > Hi,
> >
> > After converting syslogd messages to iov, UDP can use sendmsg(2)
> > instead of snprintf().
> >
> > ok?
> >
>
> I have one question below, but the diff
When calling agentx_index_start we short-circuit the call to the agentx
master when the index is dynamic. This is in accordance with the RFC.
At the moment we don't do the same thing when calling
agentx_index_close. Diff below addresses this.
Largest part is a reindent of agentx_index_close_finali
On Mon, 2021-08-30 at 10:08 +1000, Damien Miller wrote:
> Hi,
>
> RSA/SHA1, a.k.a the "ssh-rsa" signature type is now disabled by default
> in OpenSSH.
>
> While The SSH protocol confusingly uses overlapping names for key and
> signature algorithms, this does not stop the use of RSA keys and ther
On Thu, 2021-09-02 at 13:25 +0200, Ingo Schwarze wrote:
> Hi Tim,
>
> trondd wrote on Wed, Sep 01, 2021 at 08:46:28PM -0400:
> > Ingo Schwarze wrote:
> > > Ingo Schwarze wrote on Wed, Sep 01, 2021 at 04:38:51PM +0200:
>
> > > > Note that the h_hup() and h_term() signal handlers are still unsafe
On Thu, 2021-09-02 at 08:56 +, Job Snijders wrote:
> On Thu, Sep 02, 2021 at 07:23:26AM +0100, Jason McIntyre wrote:
> > > .Ar time
> > > -can be integer or decimal numbers.
> > > +are positive integer or real (decimal) numbers, with an optional
> >
> > can you have a negative timeout?
>
> N
Bluhm asked me to rethink the freeing strategy.
Here's the end result.
On Mon, 2021-08-30 at 12:03 +0200, Martijn van Duren wrote:
> I missed this one before, since apparently it doesn't show up with
> MALLOC_OPTIONS set to "S", but it does if it is empty.
>
> Thi
Via "relayctl reload" agentx can be enabled, disabled, but if it's
enabled->disabled->enabled the final enable won't work because we
never reset the sa.
Also add an extra guard so that we don't accidentally free it
twice.
OK?
martijn@
Index: agentx_control.c
I missed this one before, since apparently it doesn't show up with
MALLOC_OPTIONS set to "S", but it does if it is empty.
This probably effects relayd if the admin has it enabled en then
disables it via a "relayctl reload". However, I'm not able to
reproduce it there and even if it can be triggere
I'll see if I can fit this one in in the next few days.
Feel free to remind me :-)
martijn@
On Sun, 2021-08-29 at 02:54 -0600, Theo de Raadt wrote:
> This does look better.
>
> I appreciate that you are fixing this underlying problem first, before
> overlaying your timer diff.
>
> Is this worki
Ok, I'll drop the diff. I misunderstood our previous conversation.
Sorry for the stir it caused.
On Mon, 2021-08-16 at 12:31 +0200, Ingo Schwarze wrote:
> Hi Martijn,
>
> Martijn van Duren wrote on Sun, Aug 15, 2021 at 11:40:49PM +0200:
> > To quote schwarze in the jot mutua
On Mon, 2021-08-16 at 22:45 +1000, Jonathan Matthew wrote:
> On Tue, Aug 10, 2021 at 12:58:05PM +0200, Martijn van Duren wrote:
> > On Mon, 2021-08-09 at 21:44 +0200, Martijn van Duren wrote:
> > > On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> > > >
On Mon, 2021-08-16 at 08:25 -0600, Todd C. Miller wrote:
> On Sun, 15 Aug 2021 23:56:54 +0200, Andreas Kusalananda
> =?utf-8?B?S8OkaMOkcmk=?
> = wrote:
>
> > But note that this comes out of a discussion on how to do '0,/re/'
> > addressing with OpenBSD sed. Your changes appears to remove one way
To quote schwarze in the jot mutually exclusive thread:
On Fri, 2021-08-13 at 11:48 +0200, Ingo Schwarze wrote:
> In this case, even though this is not a POSIX command, POSIX utility
> convention 12.2.11 is pertinent:
>
> The order of different options relative to one another should not
> matt
Andreas Kähäri gave a nice example on misc@ on how our sed addressing
implemenation differs from gsed[0][1]. While writing my reply I noticed
that POSIX doesn't state how "next cycle" should be interpreted when it
comes to address ranges. So I can't state that our implementation is
wrong per se. Ho
Similar to tb's de Morgan's rule send last night.
Shaves of 4 LoC of putdata and reads easier to me.
regress passes
OK?
martijn@
Index: jot.c
===
RCS file: /cvs/src/usr.bin/jot/jot.c,v
retrieving revision 1.51
diff -u -p -r1.51 jo
Historically 's' presumably stood both for step and seed, but since we
don't support seed anymore I think it's wise to make things a little
more readable and just rename 's' to 'step'.
tb@ already agrees with the concept.
OK?
martijn@
Index: jot.1
===
Looking at tb's diff I fell in the trap of looking at other parts of the
code. Now he's conning me into writing diffs...
So here's the first one:
- When -b is set, but followed by -w it doesn't remove the boring flag
and the -w is interpreted as a -b string
- -c is defined as "This is an abbrevi
On Thu, 2021-08-12 at 15:57 +0200, Ingo Schwarze wrote:
> Hi,
>
> deraadt@ recently pointed out to me in private mail that it is good
> for usability if interactive programs providing line editing
> functionality are consistent what they do with Ctrl-C, ideally
> discard the current input line and
On Wed, 2021-08-11 at 18:59 +0100, Stuart Henderson wrote:
> On 2021/08/11 19:34, Martijn van Duren wrote:
> > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > > Following snmpd, remove the public
On Wed, 2021-08-11 at 18:59 +0100, Stuart Henderson wrote:
> On 2021/08/11 19:34, Martijn van Duren wrote:
> > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > > Following snmpd, remove the public
On Wed, 2021-08-11 at 18:50 +0200, Ingo Schwarze wrote:
> Hi,
>
> in its current state, the editline(3) library is completely unfit
> to work with non-blocking I/O. Neither the API nor the implementation
> are even designed for that purpose.
>
> I do have some candidate ideas to minimally extend
On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> On 2021/08/11 16:35, Martijn van Duren wrote:
> > Following snmpd, remove the public default community and move to snmpv3
> > by default. This is also what net-snmp does. I originally chose this
> > default becaus
Probably not something many people will run into.
$ snmp mibtree -q
snmp: unknown option -- q
usage: snmp mibtree[-O fnS] [oid ...]
$ ./obj/snmp mibtree -q
snmp: unknown option -- q
usage: snmp mibtree [-O fnS] [oid ...]
mibtree is the only one not setting the usecommonopt.
OK?
martijn@
Index:
Following snmpd, remove the public default community and move to snmpv3
by default. This is also what net-snmp does. I originally chose this
default because that's what snmpctl did and it allowed for easier
interoperability with snmpd(8).
Now that snmpd(8) moved on, so should snmp(1).
OK?
martijn
On Mon, 2021-08-09 at 21:44 +0200, Martijn van Duren wrote:
> On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> > This diff allows sending traps in SNMPv3 messages.
> > It defaults to the global seclevel, but it can be specified on a per
> > rule basis.
> &
On Mon, 2021-08-09 at 21:58 +0100, Stuart Henderson wrote:
> On 2021/08/09 22:35, Martijn van Duren wrote:
> > Moving to tech@
> >
> > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > >
Moving to tech@
On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> On 2021/08/09 12:14, Martijn van Duren wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
> >
> > Modified
On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> This diff allows sending traps in SNMPv3 messages.
> It defaults to the global seclevel, but it can be specified on a per
> rule basis.
>
> Diff requires both previous setting engineid and ober_dup diff.
>
>
On Mon, 2021-08-09 at 11:57 +0200, Martijn van Duren wrote:
> On Sun, 2021-08-08 at 14:44 +0100, Stuart Henderson wrote:
> > > This is probably is a bad example.
> > > Reading it like this: you're correct that we listen on all interfaces
> > > by default, but tha
On Mon, 2021-08-09 at 15:17 +0200, Ingo Schwarze wrote:
> Hi Martijn,
>
> Martijn van Duren wrote on Mon, Aug 09, 2021 at 02:15:42PM +0200:
>
> > If we're stripping down fixio to a single function, why not
> > inline the whole thing?
>
> I deliberately t
On Mon, 2021-08-09 at 14:15 +0200, Martijn van Duren wrote:
> On Mon, 2021-08-09 at 13:19 +0200, Ingo Schwarze wrote:
> > Hi,
> >
> > as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> > Fixing that without longjmp(3) requires making edi
On Mon, 2021-08-09 at 13:19 +0200, Ingo Schwarze wrote:
> Hi,
>
> as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> Fixing that without longjmp(3) requires making editline(3) better
> behaved.
>
> Currently, when read(2) from the terminal gets interrupted by a
> signal, editl
On Sun, 2021-08-08 at 14:44 +0100, Stuart Henderson wrote:
> > This is probably is a bad example.
> > Reading it like this: you're correct that we listen on all interfaces
> > by default, but that's not listed in snmpd.conf(5). So that should
> > probably be fixed (including mentioning that setting
Btw, would there be any benefit to declare zero as const in this
context?
On Sun, 2021-08-08 at 13:42 +0200, Ingo Schwarze wrote:
> Hi,
>
> deraadt@ recently reported to me that the editline(3) library, while
> line editing is active - for example inside el_gets(3) - ignores
> the first SIGINT it
On Sun, 2021-08-08 at 13:42 +0200, Ingo Schwarze wrote:
> Hi,
>
> deraadt@ recently reported to me that the editline(3) library, while
> line editing is active - for example inside el_gets(3) - ignores
> the first SIGINT it receives, for example the the first Ctrl-C the
> user presses. I consider
On Sat, 2021-08-07 at 22:47 +0100, Stuart Henderson wrote:
> On 2021/08/07 15:17, Martijn van Duren wrote:
> > Let me give one final pushback, if this doesn't convince you then feel
> > free to commit sthen's diff without my OK, but make sure it stays in
> > sync wit
Let me give one final pushback, if this doesn't convince you then feel
free to commit sthen's diff without my OK, but make sure it stays in
sync with snmp(1).
First let me sum up what defaults have changed since 6.9:
- community authentication disabled (snmpv1/snmpv2c)
- no default community name
On Thu, 2021-08-05 at 09:32 +0100, Stuart Henderson wrote:
> On 2021/08/03 23:46, Martijn van Duren wrote:
> > On Tue, 2021-08-03 at 21:58 +0100, Stuart Henderson wrote:
> > > On 2021/08/03 22:07, Martijn van Duren wrote:
> > > > On Tue, 2021-08-03 at 18:24
On Tue, 2021-08-03 at 21:58 +0100, Stuart Henderson wrote:
> On 2021/08/03 22:07, Martijn van Duren wrote:
> > On Tue, 2021-08-03 at 18:24 +0100, Stuart Henderson wrote:
> > > On 2021/06/15 17:39, Stuart Henderson wrote:
> > > > > Then again, I don't get the
On Tue, 2021-08-03 at 18:24 +0100, Stuart Henderson wrote:
> On 2021/06/15 17:39, Stuart Henderson wrote:
> > > Then again, I don't get the feeling many people use snmpd at this time
> > > and maybe it's a good moment to bite the bullet and go for safest
> > > defaults possible at this time. But if
This diff allows sending traps in SNMPv3 messages.
It defaults to the global seclevel, but it can be specified on a per
rule basis.
Diff requires both previous setting engineid and ober_dup diff.
Tested with netsnmp's snmptrapd and my WIP diff.
The other 2 outstanding diffs are for receiving SNM
Previous diff failed to set the initial bit when not defining engineid
in the config.
On Fri, 2021-07-23 at 15:41 +0200, Martijn van Duren wrote:
> This diff introduces setting the engineid for snmpd(8).
> Although this diff might seem quite excessive at first glance, there's
> a v
This diff introduces setting the engineid for snmpd(8).
Although this diff might seem quite excessive at first glance, there's
a valid reason to do so.
The following things are in effect when sending an SNMPv3 trap:
- SNMP trap packets are unacknowledged; meaning that we don't get a
response -,
This type-O snuck in when merging traphandler into snmpe.
Not a big deal since it's there just for ASN1/SMI strictness, but it
breaks when introducing SNMPv3 support.
OK?
martijn@
Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd
Not an issue with read requests, but will set requests if they contain
snmp application elements such as timeticks.
Definitely needed for upcoming SNMPv3 trap support.
OK?
martijn@
Index: usm.c
===
RCS file: /cvs/src/usr.sbin/snmpd
I'm currently working on adding SNMPv3 support to traps in snmpd(8).
For sending traps we loop over sc_trapreceivers and can send each trap
to 0 or more receivers.
I want to high-jack snmpe_response() to do the heavy lifting for doing
the snmp/usm encoding, but this interface frees the varbindlist
There are equivalents for '+' and '?' in BRE.
OK?
martijn@
Index: re_format.7
===
RCS file: /cvs/src/lib/libc/regex/re_format.7,v
retrieving revision 1.22
diff -u -p -r1.22 re_format.7
--- re_format.7 14 Sep 2015 20:06:58 -
On Fri, 2021-06-11 at 16:13 +0200, Martijn van Duren wrote:
> any takers?
>
> On Fri, 2021-06-04 at 22:11 +0200, Martijn van Duren wrote:
> > ping
> >
> > On Fri, 2021-05-28 at 08:19 +0200, Martijn van Duren wrote:
> > > As the original comment said:
>
On Sun, 2021-06-20 at 09:18 -0600, Theo de Raadt wrote:
> Please don't turn current.html into a series of essays.
>
> At most, the chunks in this page should highlight that something has changed.
> What has changed? Keep it simple. People should be taught to re-read the
> updated manual page. T
On Sun, 2021-06-20 at 12:58 +0100, Stuart Henderson wrote:
> Index: current.html
> ===
> RCS file: /cvs/www/faq/current.html,v
> retrieving revision 1.1071
> diff -u -p -r1.1071 current.html
> --- current.html26 May 2021 12:12:
And here's the diff to change the crypto defaults.
Currently snmp(1) and snmpd(8) don't match up by default since snmp(1)
uses md5/des as per RFC3414 (sha-1 is a should, md5 is a must) and
net-snmpd's defaults, where snmpd(8) uses sha-1/des.
While I haven't heard that md5 and/or sha1 are broken i
On Tue, 2021-06-15 at 17:39 +0100, Stuart Henderson wrote:
> > > > - if the concern is amplification attacks then setting the minlevel to
> > > > authpriv is too high, since you'll silently break logins for users
> > > > that miss the enckey parameter.
> > > > I changed this to always default
On Thu, 2021-06-17 at 08:06 +0200, Martijn van Duren wrote:
> dlg@ asked me for an example output, so here it is:
> 07:52:52.326084 fe80::fce1:baff:fed2:8886.dhcpv6-client >
> ff02::1:2.dhcpv6-server: [udp sum ok] DHCPv6 Solicit xid 0xdc0732
> OPTION_CLIENTID: 00:01:00:01
es in it's configs and knowing how a UID is build up
doesn't give us any useful information imho.
On Wed, 2021-06-16 at 17:03 +0200, Martijn van Duren wrote:
> According to the last commit message to print-dhcp6.c by dlg:
> if someone is interested in making this easier to read, it
According to the last commit message to print-dhcp6.c by dlg:
if someone is interested in making this easier to read, it would
be a straightforward and well contained project to better handle
option printing.
I'm playing around a little with dhcp6 and I heeded the call.
This diff does a few thin
snmpd using hmac-sha256
> though it seems it will work with hmac-sha512..)
I tried to make sure they're compatible and hmac-sha2 suites are properly
defined in RFC 7860:
martijn$ doas grep -v -e '^#' -e '^$' /etc/snmpd.conf
listen_addr="localhost"
listen on $listen
On Tue, 2021-06-15 at 00:30 +0100, Stuart Henderson wrote:
> On 2021/06/14 19:40, Martijn van Duren wrote:
> > On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote:
> > > By default, snmpd responds to the frequently abused community strings
> > > "public
On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote:
> By default, snmpd responds to the frequently abused community strings
> "public" and "private".
>
> To prevent this, at present you must either use "seclevel auth" or
> "seclevel enc" (if you would like to only use SNMPv3), set an explic
any takers?
On Fri, 2021-06-04 at 22:11 +0200, Martijn van Duren wrote:
> ping
>
> On Fri, 2021-05-28 at 08:19 +0200, Martijn van Duren wrote:
> > As the original comment said:
> > /*
> > * This should probably go into parsevarbinds, but that's for a
> >
ping
On Fri, 2021-05-28 at 08:19 +0200, Martijn van Duren wrote:
> As the original comment said:
> /*
> * This should probably go into parsevarbinds, but that's for a
> * next refactor
> */
>
> This moves the pdu parsing of traps into parsevarbinds.
> Added bonu
As the original comment said:
/*
* This should probably go into parsevarbinds, but that's for a
* next refactor
*/
This moves the pdu parsing of traps into parsevarbinds.
Added bonus, we can now see the packets in debugging mode:
startup
snmpe: listening on udp 127.0.0.1:162
ktable_new: new kta
Any takers?
martijn@
On Tue, 2021-03-09 at 19:33 +0100, Martijn van Duren wrote:
> I send out an earlier version of this diff to Anindya with some positive
> feedback. Instead of claiming another binding, why not make help, order
> and view a toggle? I see no reason why this informati
ping
On Fri, 2021-05-07 at 16:18 +0200, Martijn van Duren wrote:
> When moving the traphandler to the snmpe process I overlooked the fact
> that "type" is being saved inside the switch statement under the
> sm_context name. RFC3411 talks about pduType, and the name contex
ping
On Sun, 2021-04-18 at 16:44 +0200, Martijn van Duren wrote:
> Hello tech@,
>
> Currently we accept codepoints 0-0xff in citrus_none, but the C/POSIX
> locale use 7 bit ascii, allowing us currently to return unspecified
> values. From code-inspection, NetBSD does the same thi
Any takers?
Updated diff after previous commit below.
martijn@
On Sun, 2021-04-18 at 23:54 +0200, Martijn van Duren wrote:
> On Sun, 2021-04-18 at 22:53 +0200, Martijn van Duren wrote:
> > On Sun, 2021-04-18 at 17:52 +0200, Martijn van Duren wrote:
> > > I'm always fr
When moving the traphandler to the snmpe process I overlooked the fact
that "type" is being saved inside the switch statement under the
sm_context name. RFC3411 talks about pduType, and the name context means
something completely different in the v3 world.
The diff below moves our naming closer to
101 - 200 of 624 matches
Mail list logo
