On Sun, 2023-10-29 at 20:11 +0100, Martijn van Duren wrote:
> Similar reasoning and questions as the move of SNMPv2-MIB::snmp.
> This moves SNMP-FRAMEWORK-MIB::snmpEngine and
> SNMP-USER-BASED-SM-MIB::usmStats from mib.c to application_internal.c,
> under SNMPv2-SMI::snmpV2
This one is a little more involved than the previous 2. Since the
snmpd.conf's system variables are stored inside a 'struct oid', I want
to move these into their own struct inside 'struct snmpd'.
If we also move mib_tree to smi.c we can completely remove mib.c
As stated in my previous mail, this
Similar reasoning and questions as the move of SNMPv2-MIB::snmp.
This moves SNMP-FRAMEWORK-MIB::snmpEngine and
SNMP-USER-BASED-SM-MIB::usmStats from mib.c to application_internal.c,
under SNMPv2-SMI::snmpV2. The reason for this broader umbrella is that
other backends have no business fiddling
I think the subject says it all. I'm not a 100% convinced that
appl_internal_snmp()
should live in application_internal.c, maybe snmpe.c, where these metrics are
set
is a better place. But since things come from mib.c, let's keep it simply here
and
we can always shuffle the deckchairs later.
_init(void);
+voidappl_internal_shutdown(void);
diff --git a/application_internal.c b/application_internal.c
new file mode 100644
index 000..ff9611e
--- /dev/null
+++ b/application_internal.c
@@ -0,0 +1,271 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2023 Martijn
Right now when we register a region with below that an instance we
can revert back in the tree. When we request below the instance we
currently use appl_region_next() to find the next region and simply
set the to be find oid to the the oid of the new region. In the
situation described above this
On Sat, 2023-10-28 at 09:45 +0200, Martijn van Duren wrote:
> RFC 2741 section 5.2 states that searchrange.end is non-inclusive.
> appl_varbind_valid() and appl_response() currently tests inclusive.
> The appl_varbind_valid() case is for backends that support
> searchrange.end
RFC 2741 section 5.2 states that searchrange.end is non-inclusive.
appl_varbind_valid() and appl_response() currently tests inclusive.
The appl_varbind_valid() case is for backends that support
searchrange.end (like agentx) and the appl_response() case for
those who do not and need a fixup
In most cases when a region is registered we have the full ownership.
As soon as a region has been registered below prior mentioned region we
could loose ownership halfway through. This case currently isn't fully
tested and with indices we can return OIDs >= searchrange.end.
The easiest way is to
On Thu, 2023-10-26 at 21:38 +0200, Theo Buehler wrote:
> On Thu, Oct 26, 2023 at 11:51:00AM +0200, Martijn van Duren wrote:
> > This case is covered by the new regress' backend_get_toofew and
> > backend_get_toomany tests. However, even with MALLOC_OPTIONS cranked
> > to the
This case is covered by the new regress' backend_get_toofew and
backend_get_toomany tests. However, even with MALLOC_OPTIONS cranked
to the max it's really hard to trigger (I had to run
backend_get_wrongorder, backend_get_toofew, backend_get_toomany
sequentially in a tight loop killing snmpd
So here's an elusive one that can be triggered every now and then by the
new regression test. Once an AgentX session is opened and we send an
invalid packet appl_agentx_recv() goes to appl_agentx_free(), since
there's no recovery. appl_agentx_free() tries to neatly close all
open sessions by
OpenBSD 7.4 is here. upgrade72.html already mentions it's deprecation.
OK?
martijn@
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
retrieving revision 1.78
diff -u -p -r1.78 parse.y
--- parse.y 6 Oct 2022
Right now we return the same value for both hrSWRunName and hrSWRunPath.
hrSWRunPath should return the full path of the binary, and hrSWRunName
a description of the running software.
Afaik there's no proper way to retrieve the full path of the running
binary, However, in a lot of cases argv[0]
This diff adds the two entries from the hrSWRunPerfTable:
hrSWRunPerfCPU, and hrSWRunPerfMem. This allows snmptop from the
net-snmp package to work. Math stolen^Wcopied from top/machine.c.
OK?
martijn@
Index: mib.c
===
RCS file:
This diff I'm least convinced about, but I do want to put it out there.
As far as I'm aware RFC2741 places no restrictions on direct mapping of
unregistrations on registrations. Meaning that if I register
1.3.6.1.2.[1-10] and I just unregister 1.3.6.1.2.5 this should leave
1.3.6.1.2.[1-4] and
RFC3416 section 4.2.1 (and others) tells us that if an error occurs the
varbindlist in the response must be identical to the original request.
There might be other edge-cases here, but let's at least make sure that
the OIDs haven't been tampered with.
OK?
martijn@
diff --git a/application.c
Certain error codes are only intended for certain request-types. Add an
appl_error_valid() function to test for this.
OK?
martijn@
diff --git a/application.c b/application.c
index 6ddeb39..53e793d 100644
--- a/application.c
+++ b/application.c
@@ -130,6 +130,7 @@ void
If a backend registers as an instance it must never return OIDs below
their registration. Add a test for this in appl_varbind_valid().
OK?
martijn@
diff --git a/application.c b/application.c
index dfa7220..6ddeb39 100644
--- a/application.c
+++ b/application.c
@@ -128,8 +128,8 @@ void
appl_agentx_session doesn't set ab_range explicitly to 1, and thus
relies on malloc randomness to set it. Sit it explicitly.
OK?
martijn@
diff --git a/application_agentx.c b/application_agentx.c
index 680725d..79900d6 100644
--- a/application_agentx.c
+++ b/application_agentx.c
@@ -548,6 +548,7
According to RFC3416 section 4.2.2 and 4.2.3 case "(2)" when an
endOfMibView is returned the OID must be identical to originally
requested OID. Currently this can fail when the original request
is in a !last registered region and all subsequent regions also
return EOMV.
Store the original OID and
Here's a special case unlikely to be found in the wild:
When opening 2 sessions on an agentx connection (already unusual) and
registering 2 overlapping regions on the different sessions, e.g. by
differing in priority (even more unusual) and we close the underlying
connection with an outstanding
Right now (un)registering a region with range_subid set to !0 will
fail. Apparently nothing in the wild uses this, but let's fix it.
This is the unregister part.
OK? martijn@
diff --git a/application.c b/application.c
index f8709b8..e780025 100644
--- a/application.c
+++ b/application.c
@@
Right now (un)registering a region with range_subid set to !0 will
fail. Apparently nothing in the wild uses this, but let's fix it.
This is the register part.
OK?
martijn@
diff --git a/application.c b/application.c
index a02260b..f8709b8 100644
--- a/application.c
+++ b/application.c
@@
RFC2741 section 6.2.2 says that reasonByManager can only be used by the
agentx master. Treat this reason as a parseerror.
OK?
martijn@
diff --git a/application_agentx.c b/application_agentx.c
index d1efae2..2231d4c 100644
--- a/application_agentx.c
+++ b/application_agentx.c
@@ -576,16
appl_agentx_free() closes any potential open sessions before closing the
connection and cleaning up. This function is called from multiple
contexts and the current APPL_CLOSE_REASONSHUTDOWN is not always
applicable. Add a second reason parameter that can be passed onto
appl_agentx_forceclose().
application.c checks the context where applicable, but not every
agentx-pdu goes through there (e.g. agentx-ping-pdu). Make sure
we always check the context in appl_agentx_recv()
OK?
martijn@
diff --git a/application.c b/application.c
index dd92864..a02260b 100644
--- a/application.c
+++
RFC2741 section 6.1 specifies which PDUs can contain which header flags.
Check that that incoming agentx PDUs have valid flags in
appl_agentx_recv(). While here I cleaned up a few log messages some
minor restructuring to prevent the function growing too large.
OK?
martijn@
diff --git
RFC2741 section 7.1.1 tells us that if a pdu can't be parsed we must
return a parseerror. Section 7.1 gives an example of "An unrecognized
value is encountered". The spec is vague is a bit vague on what
constitutes a parseerror, vs a protocol error, so I don't want to
muddle too much with that
> According to RFC2741 section 6.1.1 an agentx-response-pdu shouldn't have
> the NON_DEFAULT_CONTEXT set. Remove the argument from ax_response().
Here's the libagentx counterpart.
OK?
martijn@
Index: agentx.c
===
RCS file:
> Currently ax.c doesn't check the maximum length of an OID ax_pdutooid.
> This can lead to a buffer overflow. Even though it must be fixed, I
> don't think there's a big risk here, since an attacker would need to have
> access to the agentx socket, which by default is disabled and defaults
> to
According to RFC2741 section 6.1.1 an agentx-response-pdu shouldn't have
the NON_DEFAULT_CONTEXT set. Remove the argument from ax_response().
OK?
martijn@
diff --git a/application_agentx.c b/application_agentx.c
index c7a2a26..0d73e08 100644
--- a/application_agentx.c
+++ b/application_agentx.c
Currently ax.c doesn't check the maximum length of an OID ax_pdutooid.
This can lead to a buffer overflow. Even though it must be fixed, I
don't think there's a big risk here, since an attacker would need to have
access to the agentx socket, which by default is disabled and defaults
to
On Tue, 2023-08-22 at 10:16 +, Gerhard Roth wrote:
> On Tue, 2023-08-22 at 11:16 +0200, Martijn van Duren wrote:
> > On Mon, 2023-08-21 at 07:35 +, Gerhard Roth wrote:
> > > Hi Martijn,
> > >
> > > last November you fixed ber.c so that sequences w
On Mon, 2023-08-21 at 07:35 +, Gerhard Roth wrote:
> Hi Martijn,
>
> last November you fixed ber.c so that sequences won't generate
> an uninitialized subelement.
>
> This revealed another bug in ober_scanf_elements(): it couldn't
> process sequences with an empty list of subelements. The
This one has been irking me for some time. At the moment when decoding a
ber message there is no way for br_application to indicate that the
tag/type is unrecognised and if br_application is not set we default to
BER_TYPE_NULL. In basically all cases any wrong encoding should be
caught by
On Tue, 2022-12-20 at 10:28 +, Gerhard Roth wrote:
> Hi Martijn,
>
> On Tue, 2022-12-20 at 11:10 +0100, Martijn van Duren wrote:
> > On Tue, 2022-12-20 at 10:21 +0100, Matthias Pitzl wrote:
> > > Hi,
> > >
> > > Since the release of OpenBSD 7.2,
On Tue, 2022-12-20 at 10:21 +0100, Matthias Pitzl wrote:
> Hi,
>
> Since the release of OpenBSD 7.2, snmp mibtree is broken:
> > root@host:~# snmp mibtree
> > snmp: No securityName specified
>
> Greetings,
> Matthias
Apparently no one has used this one in a long time (including me).
This got
I received a pcap file from someone containing kuznetzov's pcap format.
According to "upstream" libpcap[0] this format uses
struct pcap_sf_patched_pkthdr, which is:
struct pcap_sf_patched_pkthdr {
struct pcap_timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion
On Wed, 2022-11-23 at 10:03 +, Klemens Nanni wrote:
> On Wed, Nov 23, 2022 at 10:48:22AM +0100, Martijn van Duren wrote:
> > On Wed, 2022-11-23 at 09:25 +, Klemens Nanni wrote:
> > > On Wed, Nov 23, 2022 at 10:15:20AM +0100, Martijn van Duren wrote:
> > > > H
On Wed, 2022-11-23 at 09:25 +, Klemens Nanni wrote:
> On Wed, Nov 23, 2022 at 10:15:20AM +0100, Martijn van Duren wrote:
> > Here's an attempt to remove sed from netstart.
>
> I don't see the point in this.
On Mon, 2022-11-21 at 20:42 -0700, Theo de Raadt wrote:
> Oh, exce
Here's an attempt to remove sed from netstart. Since we use sed in a
simple string replacement without any fancy regex stuff I think we can
relatively easy use something based on shell built-ins.
Risk of the current code is that if someone places search inside
replacement we get an infinite loop,
On Tue, 2022-11-22 at 11:25 +0100, Claudio Jeker wrote:
> On Tue, Nov 22, 2022 at 09:25:08AM +, Stuart Henderson wrote:
> > Need to query (and set $if, which might be used in route commands etc) I
> > think.
> >
>
> I would prefer if people took a step back from configuring interfaces by
>
On Sun, 2022-11-20 at 19:35 -0700, Theo de Raadt wrote:
> Steve Litt wrote:
>
> > Vitaliy Makkoveev said on Mon, 21 Nov 2022 03:48:21 +0300
> >
> > > > On 20 Nov 2022, at 18:06, Odd Martin Baanrud
> > > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > I have a Raspberry Pi 4 with 2 USB NIC’s
On Wed, 2022-11-02 at 18:34 +0100, Claudio Jeker wrote:
> On Wed, Nov 02, 2022 at 05:56:21PM +0100, Martijn van Duren wrote:
> > On Wed, 2022-11-02 at 17:47 +0100, Claudio Jeker wrote:
> > > On Wed, Nov 02, 2022 at 05:25:12PM +0100, Martijn van Duren wrote:
> > > &g
On Wed, 2022-11-02 at 17:47 +0100, Claudio Jeker wrote:
> On Wed, Nov 02, 2022 at 05:25:12PM +0100, Martijn van Duren wrote:
> > On Wed, 2022-11-02 at 17:00 +0100, Claudio Jeker wrote:
> > > On Wed, Nov 02, 2022 at 07:33:14AM +0100, Martijn van Duren wrote:
> > &g
On Wed, 2022-11-02 at 17:00 +0100, Claudio Jeker wrote:
> On Wed, Nov 02, 2022 at 07:33:14AM +0100, Martijn van Duren wrote:
> > I found 2 minor issues in the handling of sequences/sets in
> > ober_read_element():
> > 1) An empty sequence/set (which is basically al
I found 2 minor issues in the handling of sequences/sets in
ober_read_element():
1) An empty sequence/set (which is basically always) unconditionally
creates an (uninitialised) sub-element. Add the same length check
used to check the next element
2) For each sub-element r is only checked for
ping
On Wed, 2022-10-26 at 10:45 +0200, Martijn van Duren wrote:
> Found by Alec on misc@.
> When there's an empty table pfta_get_nextaddr jumps to fail and
> mib.c returns an agentx_varbind_notfound not libagentx, resulting
> in the upper code assuming that the object has no more ent
I should've probably been more clear: This is about OPENBSD-PF-MIB's
pfTblAddrTable.
On Wed, 2022-10-26 at 10:45 +0200, Martijn van Duren wrote:
> Found by Alec on misc@.
> When there's an empty table pfta_get_nextaddr jumps to fail and
> mib.c returns an agentx_varbind_notfound not
Found by Alec on misc@.
When there's an empty table pfta_get_nextaddr jumps to fail and
mib.c returns an agentx_varbind_notfound not libagentx, resulting
in the upper code assuming that the object has no more entries
after that. Note that this is not just an issue of the new code,
but apparently
As pointed out by Alec on misc@, there's a discrepancy between the
name and description of several objects inside the pfIfTable.
Looks like a simple copy-paste error.
OK?
martijn@
Index: OPENBSD-PF-MIB.txt
===
RCS file:
On Fri, 2022-10-14 at 09:31 -0600, Theo de Raadt wrote:
> Martijn van Duren wrote:
>
> > This one got overlooked when all the metrics moved to snmpd_metrics.
> >
> > OK?
> >
> > martijn@
> >
> > Index: Makefile
> > =
This one got overlooked when all the metrics moved to snmpd_metrics.
OK?
martijn@
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile6 Oct 2022
This builds on top of the previous two diffs.
Easiest way to test is to add the following line to vm.conf in
combination with snmpd(8):
agentx context foo
This results in:
[fd:6 sess:4009008336 ctx:foo]: region .1.3.6.1.2.1.236: opening
[fd:6 sess:4009008336 ctx:foo]: region .1.3.6.1.2.1.236:
This one is on top of the don't reset errors diff.
This diff includes a minor bump. Don't know if we're still to close
after unlock.
If certain components (session, agentcaps, region, index, object) are
in a closed state while they are expected to be open, there is no way
to retry them without
There's a couple of cases in libagentx where we call agentx_reset on
error cases returned by the server, which in turn results in the
connection being closed and retried.
There's no reason to expect the server to return another response on
the next try. I think it's better to just keep the
Just before lock mbuhl pointed out a new limit placed in pf, not
exported yet over snmp. Here's a diff to add support for
PF_LIMIT_ANCHORS.
the OPENBSD-PF-MIB.txt DESCRIPTION is adapted from pfLimitMaxTables.
The snmp{,d} parts are there just for pretty printing.
OK?
martijn@
Index:
On Tue, 2022-09-27 at 11:23 +0200, Florian Obser wrote:
> On 2022-09-27 09:26 +02, Martijn van Duren wrote:
> > The caveats section talks about "user-supplied data". These string are
> > constant and don't contain any '%'. Most other daemons in base use the
> >
The caveats section talks about "user-supplied data". These string are
constant and don't contain any '%'. Most other daemons in base use the
setproctitle("title"); format as well.
On Tue, 2022-09-27 at 08:07 +0100, Stuart Henderson wrote:
> These programs seem OK as-is, they are following the
varbind was designed to allow both a ber NULL and a NULL pointer for
value. The ber NULL case is there for when it was received via a PDU.
The NULL pointer case can happen if application.c runs into a timeout
or when a backend runs into problems.
The NULL pointer case however was overlooked in
When a connection is reset while we still have an outstanding request,
the connection from the request to the rest of the structure is removed,
so we don't send any old data over the new connection.
However, the current code dereferences axc at a couple of places before
we check it for NULL.
d can usually be omitted.
.It Ic local prefix Ar address Ns Li / Ns Ar prefix
Set the network prefix that is used to allocate subnets for
local interfaces, see
Index: vm_agentx.c
===
RCS file: vm_agentx.c
diff -N vm_agentx.c
-
I think this one speaks for itself.
OK?
martijn@
? obj
Index: application_agentx.c
===
RCS file: /cvs/src/usr.sbin/snmpd/application_agentx.c,v
retrieving revision 1.2
diff -u -p -r1.2 application_agentx.c
--- application_agentx.c
So right now we disallow allocation of a region if a sub-region has the
subtree flag set. This logic is inverted compared to it's intention,
which is that if you allocate a region with subtree it should check that
the entire region below it is available (application.c:242 should say
"subtree"
Doing overlapping regions is hard...
At application.c:1341 we currently assign region->ar_oid to oid.
However, with overlapping regions this can cause a recursion, because
region might be the parent of the previous region that would cause the
oid to traverse back and cause a loop.
This can
Apparently I mistyped one AgentX as Agentx, and when moving sess_id to
uint32_t (in an early draft) I forgot to adjust the %d in two places.
OK?
martijn@
Index: application_agentx.c
===
RCS file:
Right now we don't allow overlapping regions when the subtree flag is
set, . However I don't see a reason why a single backend can't
make an overlapping region with itself.
I would also like to use this feature when moving mib.c code into an
libagentx based backend.
OK?
martijn@
Index:
I think the subject speaks for itself.
Not a really big problem, since non of the available software that we
currently have in base/ports have overlapping regions, but definitely
worth fixing.
OK?
martijn@
Index: application.c
===
When we have 2 overlapping regions within the same backend the current
code takes the OID of the parent region after the child region returned
an EOMV. This is of course wrong and creates an infinite loop.
OK?
martijn@
Index: application.c
appl_request_downstream_free gets called from 3 locations:
- appl_request_upstream_free: called from appl_request_upstream_reply
and cleans up after a request has been answered, whether all the
downstream requests have been completed or not (when timed out)
- appl_response: When a downstream
This is the snmpd(8) part of searchrange end issue mentioned in my
libagentx diff from yesterday.[0]
Since searchranges are an agentx specific thing I implemented two
cases:
1) Backends that support searchranges set ab_range to 1
(application_agentx.c) and check the av_oid_end in
When doing a getnext/getbulk request, agentx diverges from snmp that it
sends a searchrange, instead of a simple next. The end oid is currently
not correctly handled by both snmpd(8) and libagentx. If a backend has
two ranges with one or more other backends having a region claimed
in between
Diff below is needed for migrating snmpd's mib.c to a libagentx based
environment. Specifically the OPENBSD-MEM-MIB:memIfTable, which relies
on IF-MIB:ifIndex.
The issue bubbles forth from the following behaviour:
In libagentx both an object and an index are enabled (started) based
when their
On Wed, 2022-01-19 at 16:23 +0100, Martijn van Duren wrote:
> The new code uses smi_print_element when debugging is enabled to trace
> calls. Unfortunately the current smi_print_element lacks in quite a few
> departments. This diff rewrites smi_print_element to be more concise
>
On Tue, 2022-06-28 at 12:33 +0200, Martijn van Duren wrote:
> On Tue, 2022-06-28 at 12:21 +0200, Martijn van Duren wrote:
> > On Tue, 2022-06-28 at 10:21 +0200, Martijn van Duren wrote:
> > > Back in 2020 florian@ added the filter-pf-addresses keyword.
> > > Alt
On Tue, 2022-06-28 at 12:21 +0200, Martijn van Duren wrote:
> On Tue, 2022-06-28 at 10:21 +0200, Martijn van Duren wrote:
> > Back in 2020 florian@ added the filter-pf-addresses keyword.
> > Although useful, I always felt it was a bit too case-specific. The diff
> > below
On Tue, 2022-06-28 at 10:21 +0200, Martijn van Duren wrote:
> Back in 2020 florian@ added the filter-pf-addresses keyword.
> Although useful, I always felt it was a bit too case-specific. The diff
> below adds a new blocklist feature/backend, which takes hold of an
> entire subtree,
When playing with the blocklist I noticed that the oid directive only
supports numeric OIDs. So if florian wants to use filter-pf-table in the
future he'd have to set:
blocklist 1.3.6.1.4.1.30155.1.9.129
which is pure insanity, if:
blocklist pfTblAddrTable
could be an option.
Diff below changes
+++ application_blocklist.c 28 Jun 2022 08:18:17 -
@@ -0,0 +1,122 @@
+/* $OpenBSD: application.c,v 1.5 2022/06/27 10:31:17 martijn Exp $ */
+
+/*
+ * Copyright (c) 2022 Martijn van Duren
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby
11:29:36 -0000
@@ -0,0 +1,842 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2021 Martijn van Duren
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission no
When registering a region in appl_region (through appl_register) we
fill oidbuf with strlcat, but we don't start from a clean state and
might have garbage prepended.
This oidbuf is only used on error-conditions, so it's unlikely to
trigger with the current code. Diff below properly initializes
On Wed, 2022-01-26 at 09:18 -0700, Theo de Raadt wrote:
> > However, as things stand interpretation can be broken with the base
> > tools. I can't fix garbage input.
>
> Your proposal builds a mechanism which encourages making decisions based
> upon parsing garbage input.
So let's just focus on
On Wed, 2022-01-19 at 16:23 +0100, Martijn van Duren wrote:
> The new code uses smi_print_element when debugging is enabled to trace
> calls. Unfortunately the current smi_print_element lacks in quite a few
> departments. This diff rewrites smi_print_element to be more concise
>
Thanks for looking into this.
On Sat, 2022-01-22 at 10:05 -0700, Theo de Raadt wrote:
> > Note that this only adds the parsing, the rest of the current behaviour
> > of stays the same. I have another diff in the pipeline for allowing the
> > hostname in the message.
>
> I object to this process.
Currently syslogd(8) doesn't support hostname parsing for incoming
messages. This means that if a sender adds a hostname to a message it
will be interpreted as progname. Additionally, when a message is being
relayed, or there's some form of NATting taking place the originator of
the message will
). Changing it to something more in line with the intended
behaviour of the current code, but still incorrect is not really an
improvement.
I'll revisit this one once more people have been exposed to the new
code.
On Thu, 2022-01-20 at 22:08 +0100, Martijn van Duren wrote:
> When hitting an error c
There's a missing NULL check in appl_response(). This should only happenwhen a
backend is misbehaving, so I only managed to find this because
I'm actively bashing it right now. This should make us a little more
future-proof. Code further down the path already has similar NULL checks
against this
When hitting an error case in mps_get{,next}req, mps assumes that no OID
has been linked to the root element. However, in both the get as well as
the getnext case it's already set when entering the mib.c code, so going
the fail goto path will result in the intended OID/exception pair being
Forgot to mention, I checked all the instances of ober_get_writebuf I
could find and they either don't use it for the actual length, or ber
has been freshly initialised just before. So there's no problem here in
the known consumers.
On Thu, 2022-01-20 at 18:50 +0100, Martijn van Duren wrote
While reading through ber.c I noticed that ober_get_writebuf can return
the wrong length when called multiple times on the same ber instance.
This is because ober_get_writebuf uses br_wend to calculate the length,
while ober_write_elements uses that to determine the size of the buffer.
This was from a sequence of early attempts to work towards a new
application layer. I can give more reasoning behind it, but the bottom
line is that it's currently dead weight.
OK to remove this code again?
martijn@
Index: snmpd.h
The new code uses smi_print_element when debugging is enabled to trace
calls. Unfortunately the current smi_print_element lacks in quite a few
departments. This diff rewrites smi_print_element to be more concise
than what we currently have, without moving into the more complex
territory that
On Mon, 2022-01-10 at 08:21 -0700, Todd C. Miller wrote:
> On Mon, 10 Jan 2022 15:23:42 +0100, Martijn van Duren wrote:
>
> > The lputs case is fairly straight forward and I'd like to get an OK
> > for that part.
>
> I agree that fixing lputs() to honor psl is the b
On Mon, 2022-01-10 at 00:25 -0600, user wrote:
> The commandD1 regression test can be enabled without modifying sed's source
> code, it is no longer failing. The commandl1, commandl2, and commandc1 tests
> fail because the 'c' and 'D' commands assume that setting the correct length
> of the
I fully agree with your reasoning and also prefer this one over the
previous two diff.
OK martijn@
On Sun, 2022-01-09 at 00:45 +0100, Ingo Schwarze wrote:
> Hi,
>
> Martijn van Duren wrote on Sat, Jan 08, 2022 at 08:30:20AM +0100:
>
> > Why not go for the followin
On Fri, 2022-01-07 at 15:00 -0600, Scott Cheloha wrote:
> On Fri, Jan 07, 2022 at 01:43:24PM -0600, Scott Cheloha wrote:
> >
> > [...]
> >
> > Like this?
> >
> > [...]
>
> Updated: make the for-loop update expressions match.
>
Why not go for the following diff?
It has a comparable speed
rver
>
> But using the patched snmpd, I get the following error:
> mib_2 = No Such Object available on this agent at this OID. Using the
> 7.0 version, it works perfectly.
>
> I can send full snmpd logs if you think it's usefull.
>
> Regards,
> Joel C.
>
> On 1/3/22 13:57
MP#213 amd64
SNMPv2-MIB::sysObjectID.0 = OID: OPENBSD-BASE-MIB::openBSDDefaultObjectID
SNMPv2-MIB::sysUpTime.0 = Timeticks: (344136) 0:57:21.36
SNMPv2-MIB::sysContact.0 = STRING: Martijn van Duren
SNMPv2-MIB::sysName.0 = STRING: martijn
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysORLastChange.0 = T
On Mon, 2021-11-08 at 09:51 +0100, Martijn van Duren wrote:
> 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 attrib
1 - 100 of 616 matches
Mail list logo
