I would like to move snmpd(8) to a more modular dispatch/transport map
system, but that's going to be quite the undertaking. To make things a
little better to grok I'd like to split of the trap receiver components
out of struct address as a first step. While doing this I can also
greatly simplify
Does this filter actually work for you? Not by my testing, nor my
understanding of filters. Filter-dkimsign works during the
filter-dataline phase, so you'd have to circumvent that one, which is
not supported.
Personally I'd sign the domain anyway, since it gives the receiver
some additional
I still want to move udp/tcp handling out of snmpe, so that there's
better layering, but my previous diff never got any response and might
do with some more polishing.
For now, lets remove listen_sock from snmpd, since there's a 1:1
correlation with struct address. This saves a couple of
On Sun, 2020-07-26 at 04:15 +0100, ropers wrote:
> On 25/07/2020, Martijn van Duren wrote:
> > This function is used throughout the OpenBSD tree and I think it's
> > fine as it is. This way it's clearer to me that it's about byte
> > 7 and 8
>
> You mean bits 7 and
This function is used throughout the OpenBSD tree and I think it's
fine as it is. This way it's clearer to me that it's about byte
7 and 8 and not have to do the math in my head to check if we
might have botched it.
Also compilers should be smart enough to optimize this out at
compile-time
Any takers?
On Wed, 2020-06-24 at 13:27 +0200, Martijn van Duren wrote:
> Moving to tech@
>
> On Tue, 2020-06-23 at 22:17 -0900, Philip Guenther wrote:
> > Nope. This is a grep of a single file, so procfile() must be overflowing
> > and this only 'fixes' it by relying on s
When r1.28 converted join(1) to getline(3) it left the old intermediate
line variable. This means using an additional memcpy and reallocing.
I reckon this is wasted cycles and screen filling.
Major difference is that our getline allocates to the next power of 2,
while the current code overcommits
I'm not quite sure yet where I want to move with snmpe_parsevarbinds,
but the current implementation just gives me a headache every time I
read it. There's still of plenty of issues in here, like not fully
complient gathering of statistics, relying on synchronous handling of
varbinds (required
I gave a quick look at replacing prompt with readpassphrase(3), but that
would be more trouble than it's worth. (adjusting pledge, semantics
change in where the "?..." would be printed).
Minor nits inline, but either way OK martijn@
On Thu, 2020-07-16 at 21:49 +0200, Ingo Schwarze wrote:
> Hi
On Wed, 2020-07-01 at 10:59 -0400, Johan Huldtgren wrote:
> hello,
>
> On 2017-11-27 10:31, Gerhard Roth wrote:
> > On Sat, 25 Nov 2017 11:42:07 -0700 Joel Knight
> > wrote:
> > > On Thu, Mar 9, 2017 at 10:02 PM, Joel Knight
> > > wrote:
> > > > Hi.
> > > >
> > > > snmpd(8) uses unsigned
this better?
martijn@
>
>
> On Tue, Jun 23, 2020 at 9:58 PM Martijn van Duren <
> open...@list.imperialat.at> wrote:
>
> > This seems to fix the issue for me.
> >
> > OK?
> >
> > martijn@
> >
> > On Tue, 2020-06-23 at 19:29 -0700, Jorda
And of course I still had a potential buffer overflow in there...
On Sat, 2020-06-13 at 09:16 +0200, Martijn van Duren wrote:
> Minor change: I forgot to forward the display_hint flag to
> smi_displayhint_os. Now -OQ and -Oq work as well.
>
> On Thu, 2020-06-11 at 21:17 +0200, Marti
Minor change: I forgot to forward the display_hint flag to
smi_displayhint_os. Now -OQ and -Oq work as well.
On Thu, 2020-06-11 at 21:17 +0200, Martijn van Duren wrote:
> Hello Ingo,
>
> Thanks for looking into this.
>
> On Sun, 2020-05-31 at 16:32 +0200, Ingo Schwarze wrote:
Hello Ingo,
Thanks for looking into this.
On Sun, 2020-05-31 at 16:32 +0200, Ingo Schwarze wrote:
> Hi Martijn,
>
> Martijn van Duren wrote on Tue, May 19, 2020 at 10:25:37PM +0200:
>
> > So according to RFC2579 an octetstring can contain UTF-8 characters if
> > so
On Fri, 2020-06-05 at 14:20 +0100, Stuart Henderson wrote:
> On 2020/06/05 13:50, Denis Fondras wrote:
> > On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> > > Dear all:
> > >
> > > just in case this appears useful to you: I found some redundant code
> > > lines in the
OK martijn@
On Fri, 2020-06-05 at 13:50 +0200, Denis Fondras wrote:
> On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> > Dear all:
> >
> > just in case this appears useful to you: I found some redundant code
> > lines in the following files.
> >
> > sys/net/pipex.h:
After updating today I noticed a couple of new extent messages in my
dmesg, which I apparently missed last upgrade. Luckily the dmesg buffer
is large enough to find the first mention.
The machine runs just fine, but I just wanted to post it here, because
it does stand out and I don't know how
So according to RFC2579 an octetstring can contain UTF-8 characters if
so described in the DISPLAY-HINT. One of the main consumers of this is
SnmpAdminString, which is used quite a lot.
Now that we trimmed a little fat from snmp's oid, I wanted to fill it
up again and implemented the bare
Anyone feeling like trimming a little fat?
On Fri, 2020-05-08 at 11:41 +0200, Martijn van Duren wrote:
> Diff below removes fields from struct oid used by snmpd but not useful
> for snmp(1). Minus 503LoC and -200kb on installed binary.
> No functional change intended.
>
> O
Clang is smart enough to know that the usage of the variables is
guarded, gcc apparently is not.
No functional change, just silence some compiler warnings.
OK?
martijn@
Index: snmpc.c
===
RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
Diff below removes fields from struct oid used by snmpd but not useful
for snmp(1). Minus 503LoC and -200kb on installed binary.
No functional change intended.
OK?
martijn@
Index: mib.c
===
RCS file: /cvs/src/usr.bin/snmp/mib.c,v
Moving to tech@
On 5/1/20 5:17 PM, Steven Surdock wrote:
> I see that snmpd.conf supports "read-write disabled", but this doesn't seem
> to _completely_ disable the private community. If I set "read-write
> disabled" I can still poll values using the 'private' community. Is this a
> bug or a
Looks fine to me. And I don't expect the tool to be widely used on
OpenBSD. Anyone objects/OK?
Small sidenote: Could you attach your diffs inline in the future? It's
the standard way of doing things here. I've added it here, so people
who don't want to open the file can see it.
martijn@
On
On 4/8/20 6:15 PM, Joerg Jung wrote:
>
>> On 8. Apr 2020, at 17:19, Eric Faurot wrote:
>>
>> Some users had issues with report events for MAIL FROM and RCPT TO
>> when "|" appear in the mail address (yes, it seems to happen), because
>> that's also the field separator. To make parsing the
This came up during u2k20 while discussing tempfiles for gotweb inside a
chroot. At the moment we don't include it by default and ports have to
create it themselves. Since I assume we want web applications to run
inside a /var/www chroot as much as possible and even some libc
functions depend on
When playing worm(6) and you crash there's a sleep of 2 seconds that
still allows input to be put into the terminal buffer that doesn't get
read until the application stops.
A similar case is possible in a more limited timespan if you win the
game.
The diff below flushes the input buffer just
We currently abuse sysORTable to display information in a way that it
shouldn't. According to SNMPv2-MIB:
"The (conceptual) table listing the capabilities of
the local SNMP application acting as a command
responder with respect to various MIB modules.
snmpd's normal socket is pretty much deprecated and the restricted
variant is even more useless. In other words lets pick it apart one
step at a time. This diff removes the restricted keyword and related
code.
While here I also removed the unimplemented IMSG_CTL_RELOAD logic.
For those wondering
Included millert, since he imported this code.
He might shed some more light on what's intended.
On 3/15/20 11:27 PM, 0xef967...@gmail.com wrote:
> On Sun, Mar 15, 2020 at 07:32:52PM +0100, Martijn van Duren wrote:
>> tl;dr new diff below
>
> Check with:
>
> OPTS=r-
tl;dr new diff below
On 3/15/20 11:21 AM, 0xef967...@gmail.com wrote:
> On Sun, Mar 15, 2020 at 09:30:22AM +0100, Martijn van Duren wrote:
>>> --- lib/libc/stdlib/getopt_long.c~
>>> +++ lib/libc/stdlib/getopt_long.c
>>> @@ -418,15 +418,8 @@
>>> }
&
On 3/12/20 2:40 AM, 0xef967...@gmail.com wrote:
> $ cat > opts.c <<'EOT' && cc -Wall -W opts.c -o opts
> #include
> #include
> int main(int ac, char **av){
> int c, i;
> while((c = getopt(ac, av, "q")) != -1)
> if(c != '?' && c != ':') printf("OPT %c\n", c);
>
ng for OKs. :-)
martijn@
On 3/10/20 1:43 PM, Jan Klemkow wrote:
> On Tue, Mar 10, 2020 at 01:13:46PM +0100, Martijn van Duren wrote:
>> On 3/10/20 10:21 AM, Jan Klemkow wrote:
>>> On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
>>>> Looking at RFC1157 section 4
On 3/10/20 10:21 AM, Jan Klemkow wrote:
> On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
>> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
>> varbindlist.
>>
>> Could you test the diff below?
>
> Is also OK for m
Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
varbindlist.
Could you test the diff below?
martijn@
On 3/9/20 11:38 PM, Jan Klemkow wrote:
> Hi,
>
> The following diff fixes the use of the uninitialized pointer iter
> in trapcmd_exec().
>
> iter is just initialized in
Committed, thanks.
On 3/4/20 9:11 PM, Robert Klein wrote:
> Hi,
>
> On Tue, 3 Mar 2020 20:45:17 +0100
> Martijn van Duren wrote:
>
>> I don't agree with this diff, even though you're right with it being
>> broken. Right now the regress test uses it/tries to use it
This reads fine to me and fixes the regress test location.
Does anyone else want to chime in?
martijn@
On 3/4/20 9:11 PM, Robert Klein wrote:
> Hi,
>
> On Tue, 3 Mar 2020 20:45:17 +0100
> Martijn van Duren wrote:
>
>> I don't agree with this diff, even though you'r
I don't agree with this diff, even though you're right with it being
broken. Right now the regress test uses it/tries to use it and even
though someone trying to run regress on an actual production machine
somewhat deserves to get shot in the foot, I don't think we should
make that our goal.
I agree that returning Operations Error is the wrong return value.
I don't agree that we should *always* return invalidCredentials,
however, acting like the other LDAP servers on an invalid entry seems
reasonable to me. One option I do see is if we can't create an imsg
to the parent process
On 2/27/20 9:51 AM, Reyk Floeter wrote:
>
>> Am 27.02.2020 um 08:56 schrieb Martijn van Duren
>> :
>>
>> On 2/12/20 7:48 AM, Martijn van Duren wrote:
>>> Hello tech@,
>>>
>>> Working on something else, this bit of code is somewhat in my way
ping
On 2/17/20 8:19 AM, Martijn van Duren wrote:
> On 2/17/20 8:12 AM, Martijn van Duren wrote:
>> jan@ found some issues with this diff during u2k20.
>> Here's an updated diff. Changes since previous diff are:
>> - If we don't know the protocol yet, we can't assume a p
ping.
On 2/15/20 12:33 PM, Martijn van Duren wrote:
> This diff does the following:
> - Push the network handling to their own files.
> This helps with readability and allows for easier addition of other
> transport layers if we ever choose to (unix socket, ssh, dtls, ...)
> -
On 2/12/20 7:48 AM, Martijn van Duren wrote:
> Hello tech@,
>
> Working on something else, this bit of code is somewhat in my way and it
> feels like an early testing feature instead of actually being useful.
>
> Is anyone actually using this, or can it be removed?
>
>
No, "?" is not always under "/", this is just for the US layout.
One example that comes to mind is the Belgian AZERTY keyboard
layout, where "?" on the same key as "," and there are probably more
examples out there.
martijn@
On 2/18/20 1:56 AM, Ryan Lennox wrote:
> Hi,
>
> As a new cwm user, I
On 2/17/20 8:12 AM, Martijn van Duren wrote:
> jan@ found some issues with this diff during u2k20.
> Here's an updated diff. Changes since previous diff are:
> - If we don't know the protocol yet, we can't assume a port is
> specified.
> - If we can create a ip6? socket don't
thrown at it, but it's still extremely
finicky, so more scrutiny/testing is welcome.
OK?
martijn@
On 1/13/20 12:48 PM, Martijn van Duren wrote:
> So apparently I use IPv6 more often than the end-users.
> This diff allows us to actually skip the {ud,tc}p6 prefix if we actually
> presen
++;
+ if (msg->sm_conn != NULL) {
+ msg->sm_reply(msg->sm_conn, ptr, len);
+ stats->snmp_outpkts++;
}
-
done:
snmp_msgfree(msg);
}
@@ -816,12 +628,12 @@ snmpe_response(struct snmp_message *msg)
void
snmp_msgfree(struct snmp_mes
Apparently not many people check the error count in their snmp stats.
This appears to been here since day 1.
OK?
martijn@
Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.60
diff -u -p -r1.60
Hello tech@,
Working on something else, this bit of code is somewhat in my way and it
feels like an early testing feature instead of actually being useful.
Is anyone actually using this, or can it be removed?
martijn@
Index: mps.c
You're right, this diff does some massive pointer juggling that I
overlooked.
I'll drop the diff.
On 1/22/20 10:59 AM, Otto Moerbeek wrote:
> On Wed, Jan 22, 2020 at 10:51:45AM +0100, Martijn van Duren wrote:
>
>> Trying to wrap my head around some of the snmpd code I foun
Trying to wrap my head around some of the snmpd code I found this pearl
that appears to do nothing more than warm up the room.
OK?
martijn@
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
retrieving revision 1.16
On 1/13/20 4:30 PM, Anders Andersson wrote:
> On Mon, Jan 13, 2020 at 3:00 PM leeb wrote:
>>
>> Hello,
>>
>> I had an itch, so I scratched it.
>>
>> The umb(4) driver has a FIXME in if_umb.c for user name
>> and passphrase support. My LTE provider happens to require
>> this so I thought I'd have
Currently we only support noSuchObject by overloading BER_TYPE_EOC.
This is wrong.
Diff below adds support for all 3 exception cases.
OK?
martijn@
Index: smi.c
===
RCS file: /cvs/src/usr.bin/snmp/smi.c,v
retrieving revision 1.6
So apparently I use IPv6 more often than the end-users.
This diff allows us to actually skip the {ud,tc}p6 prefix if we actually
present an IPv6 address as described in the manpage and done by
net-snmp.
While here I also made it possible possible to do a retry if
IPv6-address:port fails by
I'm on the fence about this. So if you feel strongly about this go
ahead if it works.
I am however somewhat confused about your description. You say it
times out, but considering it (by default) only retrieves 10 entries
per packet it should return somewhat quick and not cause a timeout.
If you
On 10/30/19 6:45 AM, Martijn van Duren wrote:
> In copying over the net-snmp semantics for snmp-v3/USM I got a bit too
> lenient in handling the keys. This diff tries to rectify that.
>
> This diff does basically two things:
> 1) Try to push people to use passphrases from stdin
In copying over the net-snmp semantics for snmp-v3/USM I got a bit too
lenient in handling the keys. This diff tries to rectify that.
This diff does basically two things:
1) Try to push people to use passphrases from stdin.
2) Clean up keying material (including from the ps listing) as soon as
or the
SHA-2 set of digests can set DES with HMAC-sha1 or HMAC-md5 in
snmpd.conf(5) to keep things working.
On 10/28/19 8:02 AM, Martijn van Duren wrote:
> At the moment we are neither consistent nor really secure in what we
> offer by default for snmp. For snmp(1) we default to MD-5 a
At the moment we are neither consistent nor really secure in what we
offer by default for snmp. For snmp(1) we default to MD-5 and DES and
for snmpd(8) we default to SHA-1 and DES. Both are horrendously out of
date.
Diff below updates both tools to use SHA-256 and AES by default.
SHA-256 should
tl;dr: Can anyone with Cisco equipment with AES-192 and AES-256 support
for snmp test the diff below as much -a variants as possible and report
back to me?
According to the archives there was once an initiative for AES-192 and
AES-256[0]. Unfortunately this was removed after draft 4.
Since
When originally writing snmp(1) I wanted to stay as close to netsnmp as
possible to make sure I didn't introduce anything I would regret.
Now that 6.6 is out the door and I'm feeling more comfortable with the
tool I want to start being a little more lenient. Here's a first step by
allowing the -C
ping
On 10/3/19 6:35 PM, Martijn van Duren wrote:
> So looking closer at Claudio's remark from this morning I found that 'e'
> basically *must* be the last element in the sequence (or weird *beep*
> happens). Also, 'e' never fails, since ber_link_elements doesn't have a
> fail-case.
ping. I think this (or similar) fix should go in before release.
On 10/3/19 5:33 PM, Martijn van Duren wrote:
> As discussed with semarie@ this morning: We're a bit too loose when it
> comes to accessing indexes based directly from the pdu.
>
> Diff below allows only indexes with
On 10/4/19 10:03 AM, gil...@poolp.org wrote:
> October 4, 2019 9:55 AM, "Martijn van Duren"
> wrote:
>>
>> This is similar to the diff I send a few months ago, but still doesn't
>> fix the case when someone sends a standalone '\n' as line-ending.
>>
On 10/4/19 9:36 AM, Gilles Chehade wrote:
> On Fri, Oct 04, 2019 at 08:43:28AM +0200, Martijn van Duren wrote:
>>>> annoying bumps will just be moved around. If we *really* want to fix
>>>> this we need to make it fit within the specifications:
>>>&g
On 10/4/19 8:23 AM, Gilles Chehade wrote:
> On Fri, Oct 04, 2019 at 07:35:39AM +0200, Martijn van Duren wrote:
>> On 10/3/19 9:05 PM, Eric Faurot wrote:
>>> On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
>>>
>>>>> To me, the only rea
On 10/3/19 9:05 PM, Eric Faurot wrote:
> On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
>
>>> To me, the only real problem with '\r' is at the end of lines. It's
>>> confusing
>>> since you never really know whether it's part of the content or the
>>> protocol.
>>>
>>> So I
So looking closer at Claudio's remark from this morning I found that 'e'
basically *must* be the last element in the sequence (or weird *beep*
happens). Also, 'e' never fails, since ber_link_elements doesn't have a
fail-case. So combining this information, if we end a
ber_printf_elements on 'e'
As discussed this morning with Claudio ber_printf_elements might give
the impression that it cleans up everything on failure, while it only
removes the last element before '.', which is (from a quick scan) not
used in our tree.
Since 'e' is the only parameter that gets linked in instead of copied
As discussed with semarie@ this morning: We're a bit too loose when it
comes to accessing indexes based directly from the pdu.
Diff below allows only indexes within the range of the pdu.
If user supplied oid and returned oid on index match the user supplied
input is shown (for easier reference).
On 10/3/19 10:56 AM, Claudio Jeker wrote:
> On Thu, Oct 03, 2019 at 10:42:42AM +0200, Martijn van Duren wrote:
>> On 10/3/19 10:19 AM, Claudio Jeker wrote:
>>> On Thu, Oct 03, 2019 at 10:01:06AM +0200, Martijn van Duren wrote:
>>>> On 10/3/19 9:21 AM, Sebastien Mar
On 10/3/19 10:33 AM, Sebastien Marie wrote:
> On Thu, Oct 03, 2019 at 10:01:06AM +0200, Martijn van Duren wrote:
>>>> Index: snmpc.c
>>>> ===
>>>> RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
>&g
On 10/3/19 10:19 AM, Claudio Jeker wrote:
> On Thu, Oct 03, 2019 at 10:01:06AM +0200, Martijn van Duren wrote:
>> On 10/3/19 9:21 AM, Sebastien Marie wrote:
>>> On Thu, Sep 26, 2019 at 02:33:11PM +0200, Martijn van Duren wrote:
>>>> On 9/26/19 9:54 AM, Martij
On 10/3/19 9:21 AM, Sebastien Marie wrote:
> On Thu, Sep 26, 2019 at 02:33:11PM +0200, Martijn van Duren wrote:
>> On 9/26/19 9:54 AM, Martijn van Duren wrote:
>>> Hello,
>>>
>>> I reckon this will be on of the last major additions.
>>> Adding "
Any feedback on the relayd part?
On 9/25/19 8:58 AM, Martijn van Duren wrote:
> On 9/25/19 8:55 AM, Martijn van Duren wrote:
>> Hello,
>>
>> Mischa found that relayd's agentx support is pretty much unusable for
>> the uninitiated, because you have to know the tables
Anyone willing to look into this one?
Or someone objecting to me committing this?
On 9/26/19 2:33 PM, Martijn van Duren wrote:
> On 9/26/19 9:54 AM, Martijn van Duren wrote:
>> Hello,
>>
>> I reckon this will be on of the last major additions.
>> Adding "snmp set&q
On 9/26/19 9:54 AM, Martijn van Duren wrote:
> Hello,
>
> I reckon this will be on of the last major additions.
> Adding "snmp set" allows us to run snmpd's regress without installing
> netsnmp. :-)
>
> Tested with snmpd's regress test.
>
> Majority of diff
Hello,
I reckon this will be on of the last major additions.
Adding "snmp set" allows us to run snmpd's regress without installing
netsnmp. :-)
Tested with snmpd's regress test.
Majority of diff is moving oid/value parsing from snmp trap to a
separate function.
OK?
martijn@
Index: snmp.1
EHLO,
Recently I moved my mailserver to a new HD resulting in temporary
inaccessibility of my maildir (temporarily root owned because of
recursive copy), leaving smtpd running thinking nothing of it.
This resulted in a few mails being PERMFAIL.
I talked to gilles@ about this and he's somewhat
On 9/25/19 8:55 AM, Martijn van Duren wrote:
> Hello,
>
> Mischa found that relayd's agentx support is pretty much unusable for
> the uninitiated, because you have to know the tables beforehand.
>
> I managed to track it down to two issue with both snmpd and relayd.
> The f
Hello,
Mischa found that relayd's agentx support is pretty much unusable for
the uninitiated, because you have to know the tables beforehand.
I managed to track it down to two issue with both snmpd and relayd.
The fix is far from proper support for agentx, but it's good enough
for going on a
On 9/19/19 5:46 PM, Gilles Chehade wrote:
> Hello,
>
> The RFC for SMTP states the following (section 2.3.8):
>
> In addition, the appearance of "bare" "CR" or "LF" characters in text
> (i.e., either without the other) has a long history of causing
> problems in mail implementations
sizeof(usmcookie->salt) :
(size_t) 0)) == NULL) {
free(usmcookie);
return NULL;
On 9/2/19 9:13 AM, Martijn van Duren wrote:
> This diff adds support for authPriv.
>
> diff --git a/snmp.1 b/snmp.1
> index e810560..fe283a5 100644
> --- a/snmp.1
> +++ b
Found by a colleague and verified against latest tcpdump version.
I don't know where the -1 comes from, but it is wrong.
OK?
martijn@
Index: print-cdp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-cdp.c,v
retrieving revision 1.7
I would like to move forward with this.
Is anyone willing to look at this?
On 9/2/19 9:06 AM, Martijn van Duren wrote:
> 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
On 9/3/19 4:30 PM, Todd C. Miller wrote:
> On Mon, 02 Sep 2019 21:15:23 +0200, Martijn van Duren wrote:
>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
>> {_POSIX_ARG_MAX}
>> Maximum length of argument to the exec functions includ
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, 2
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
>>>
same pattern. So why is it not excluded in the same
> way?
>
> Second questoin: are filter programs going to be in /bin or /usr/sbin?
> If not, why is /bin on this PATH you are defining?
>
> It smell execvp abuse.
>
> Martijn van Duren wrote:
>
>> With filt
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
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
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
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+=
snmp_app->usage == NULL ? "" : " ",
+ " [-c community] [-e secengineid] [-E ctxengineid] [-n
ctxname]\n"
+ "[-O afnqvxSQ] [-r retries] [-t timeout] [-u
user] [-v version]\n"
+
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
derr, "usage: snmp %s%s%s%s\n",
+ fprintf(stderr, "usage: snmp %s%s%s\n",
snmp_app->name,
snmp_app->usecommonopt ?
- " [-c community] [-r retries] [-t timeout] [-v version]\n"
-
On 8/29/19 8:53 AM, gil...@poolp.org wrote:
> 29 août 2019 07:02 "Martijn van Duren" a
> écrit:
>
>> Since we don't support any smtp-out events at time of writing, so we
>> might as well throw an error if people try to register one. This way
>> people w
Since we don't support any smtp-out events at time of writing, so we
might as well throw an error if people try to register one. This way
people won't be surprised if the registration succeeds, but no event
ever arrives.
OK?
martijn@
Index: lka_report.c
On 8/28/19 2:52 PM, gil...@poolp.org wrote:
>
> Yes sorry my bad, but this still covers the textstring argument:
>
> We need to be able to reject at banner and this is going to be implemented
> as a filter phase, so basically if we expect people to need it for filters
> the proper place to pass
On 8/28/19 12:26 PM, Gilles Chehade wrote:
> On Wed, Aug 28, 2019 at 10:33:29AM +0200, Martijn van Duren wrote:
>> On 8/28/19 9:23 AM, gil...@poolp.org wrote:
>>> 28 ao??t 2019 09:04 "Martijn van Duren" a
>>> ??crit:
>>>
>>>> Currentl
On 8/28/19 9:23 AM, gil...@poolp.org wrote:
> 28 août 2019 09:04 "Martijn van Duren" a
> écrit:
>
>> Currently looking into writing an spf filter based on libopensmtpd.
>> While working through the spec I found in RFC7208 section 7.3 that:
>> The "r&q
301 - 400 of 616 matches
Mail list logo
