pthread_once fix memory leak

2021-05-02 Thread Martijn van Duren
Found this while tracing a memory leak in filter-dkimsign, thanks to libcrypto. The mutex in pthread_once_t is never destroyed, so the memory allocated inside the mutex is never released. The diff below was inspired by Ed Schouten and switches form mutex to futex to prevent any memory allocation.

libagent: fix agentx_context_object_nfind

2021-05-01 Thread Martijn van Duren
The parameters for ax_oid_cmp are swapped. This fixes the few failing regress tests I just committed. OK? martijn@ Index: agentx.c === RCS file: /cvs/src/lib/libagentx/agentx.c,v retrieving revision 1.9 diff -u -p -r1.9 agentx.c

Re: printf(1): support \u and \U

2021-04-18 Thread Martijn van Duren
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 frustrated when a unicode character question comes up and I > > have to look up the UTF-8 byte sequence to reproduce it. When fixing \x > >

Re: printf(1) Fix hex numbers

2021-04-18 Thread Martijn van Duren
On Sun, 2021-04-18 at 12:38 -0900, Philip Guenther wrote: > On Sun, Apr 18, 2021 at 12:04 PM Martijn van Duren > wrote: > > On Sun, 2021-04-18 at 11:17 -0900, Philip Guenther wrote: > > > > > > I'll just throw in a note that the current POSIX spec does not

Re: printf(1) Fix hex numbers

2021-04-18 Thread Martijn van Duren
ied already. > > Philip Guenther > > > On Sun, Apr 18, 2021 at 7:02 AM Martijn van Duren > wrote: > > On Thu, 2021-04-15 at 19:48 -0600, Todd C. Miller wrote: > > > On Fri, 16 Apr 2021 03:34:04 +0200, Martijn van Duren wrote: > > > > >

Re: printf(1): support \u and \U

2021-04-18 Thread Martijn van Duren
On Sun, 2021-04-18 at 17:52 +0200, Martijn van Duren wrote: > I'm always frustrated when a unicode character question comes up and I > have to look up the UTF-8 byte sequence to reproduce it. When fixing \x > I found the \u and \U escape sequences in gprintf, which seem might

Re: printf(1) Fix hex numbers

2021-04-18 Thread Martijn van Duren
On Thu, 2021-04-15 at 19:48 -0600, Todd C. Miller wrote: > On Fri, 16 Apr 2021 03:34:04 +0200, Martijn van Duren wrote: > > > We currently have NetBSD's behaviour when it comes to to no characters, > > so no need to change there imho, but the 2 character limit seems like > &

printf(1): support \u and \U

2021-04-18 Thread Martijn van Duren
I'm always frustrated when a unicode character question comes up and I have to look up the UTF-8 byte sequence to reproduce it. When fixing \x I found the \u and \U escape sequences in gprintf, which seem mighty handy for this exact case. My implementation differs from gprintf in that leading

citrus_none: don't allow codepoints > 0x7f

2021-04-18 Thread Martijn van Duren
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 thing we do (since they also use citrus, that's to be expected), but FreeBSD (from code-

Re: wcwidth of soft hyphen

2021-04-16 Thread Martijn van Duren
On Thu, 2021-04-15 at 14:20 +0200, Martijn van Duren wrote: > I did some archeology today and found that it used to behave as > non-printable, but it got broken in release 334 (august 2018), when > CharWidth was introduced. Before that my_wcwidth was used directly. > > Since there

printf(1) Fix hex numbers

2021-04-15 Thread Martijn van Duren
Hello tech@, When toying with SHY I found (thanks to sthen@) that printf(1) supports \x syntax, but if I use isxdigit(3) characters as suffix I found the behaviour somewhat surprising: all extra characters were consumed. Looking at our closest neighbours: - FreeBSD: doesn't support \x - NetBSD:

Re: wcwidth of soft hyphen

2021-04-15 Thread Martijn van Duren
on the situation and maybe get some context. Answer pending. On Wed, 2021-04-14 at 21:25 +0200, Martijn van Duren wrote: > On Wed, 2021-04-14 at 20:10 +0300, Lauri Tirkkonen wrote: > > Since the discussion seems to have died out, I take my patch will not be > > accepted. > > >

Re: wcwidth of soft hyphen

2021-04-14 Thread Martijn van Duren
On Wed, 2021-04-14 at 20:10 +0300, Lauri Tirkkonen wrote: > Since the discussion seems to have died out, I take my patch will not be > accepted. > > The decision appears to be that OpenBSD is right and everyone else is wrong in > this matter. Given that, and the calls to change the behavior of

Re: vi: don't expandtab when we're in command mode.

2021-04-13 Thread Martijn van Duren
On Tue, 2021-04-13 at 09:02 -0600, Todd C. Miller wrote: > On Tue, 13 Apr 2021 16:56:52 +0200, Martijn van Duren wrote: > > > When adding a TRACE() I see that that case is only called incidentally > > and / works for me as is. However, it still doesn't work when > > in

Re: vi: don't expandtab when we're in command mode.

2021-04-13 Thread Martijn van Duren
When adding a TRACE() I see that that case is only called incidentally and / works for me as is. However, it still doesn't work when in command-mode (e.g. ":%s// /g" still requires ^V escape). So either I'm not clear on which case this is trying to solve or it doesn't work as advertised.

Re: dhcpleased rescale rebinding and renewal time on invalid values

2021-04-09 Thread Martijn van Duren
On Fri, 2021-04-09 at 09:47 +0200, Florian Obser wrote: > On Fri, Apr 09, 2021 at 09:41:24AM +0200, Florian Obser wrote: > > I think it would be better (and less ugly) to treat invalid values as > > if they had not been set. Could you pull the two checks up before > > if(renewal_time == 0) and do

dhcpleased rescale rebinding and renewal time on invalid values

2021-04-09 Thread Martijn van Duren
Hello tech@, I´m currently faced with a Comtrend VI-3223u router, which sends out dhcp leases with: DHO_DHCP_LEASE_TIME 86400s DHO_DHCP_RENEWAL_TIME 43200s DHO_DHCP_REBINDING_TIME 86400s This trips up dhcpleased and I´m stuck without an IP-address (unless I move back to dhclient). I know that

Re: wcwidth of soft hyphen

2021-04-06 Thread Martijn van Duren
On Tue, 2021-04-06 at 13:27 +0100, Stuart Henderson wrote: > On 2021/04/06 13:09, Martijn van Duren wrote: > > I´m also not convinced that the other wcwidth implementations might be > > on to something and that the unicode consortium is having inertia > > problems

Re: wcwidth of soft hyphen

2021-04-06 Thread Martijn van Duren
On Mon, 2021-04-05 at 20:30 +0200, Ingo Schwarze wrote: > Hi, > > Martijn van Duren wrote on Thu, Apr 01, 2021 at 09:30:36AM +0200: > > So going by this phrase the character should not be printed > > When formatting a document, for example for printing on paper or > th

Re: wcwidth of soft hyphen

2021-04-06 Thread Martijn van Duren
On Thu, 2021-04-01 at 10:39 +0300, Lauri Tirkkonen wrote: > On Thu, Apr 01 2021 09:30:36 +0200, Martijn van Duren wrote: > > However, based on the description by the Unicode Consortium I think > > OpenBSD does the right thing and xterm and others should be fixed, > >

Re: wcwidth of soft hyphen

2021-04-01 Thread Martijn van Duren
When it comes to these discussions I prefer to go back to the standards and not just looking at the surrounding discussions. The standard[0] states the following in section 23.2: Hyphenation. U+00AD soft hyphen (SHY ) indicates an intraword break point, where aline break is preferred if a word

Re: uvideo(4) new quirk flag UVIDEO_FLAG_NOATTACH

2021-03-26 Thread Martijn van Duren
I'm in no way qualified to OK this, but I'd like to see this get in, because it does help me out :-) martijn@ On Mon, 2021-03-15 at 08:35 +0100, Marcus Glocker wrote: > martijn@ has recently reported that in his machine he has two cams > of which one is doing IR, which isn't really supported by

Re: systat(1) sticky help

2021-03-23 Thread Martijn van Duren
ping 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 information should

Re: snmp(1) Fix some ranges and types

2021-03-23 Thread Martijn van Duren
Any takers? On Tue, 2021-03-02 at 22:50 +0100, Martijn van Duren wrote: > Live and learn. While working on a regress test I found that I > misunderstood some types when I wrote this code. According to RFC2578: > - timeticks is a 32 bit unsigned int > - counter32 is a 32 bit

snmp(1) adjust for OPENBSD-PF-MIB

2021-03-23 Thread Martijn van Duren
Index: mib.h === RCS file: /cvs/src/usr.bin/snmp/mib.h,v retrieving revision 1.9 diff -u -p -r1.9 mib.h --- mib.h 14 Dec 2020 07:44:26 - 1.9 +++ mib.h 23 Mar 2021 20:52:03 - @@ -1193,7 +1193,7 @@ {

Re: OPENBSD-PF-MIB, use DisplayString not OCTET STRING

2021-03-23 Thread Martijn van Duren
On Mon, 2021-03-22 at 09:00 +, Stuart Henderson wrote: > On 2021/03/22 00:20, Martijn van Duren wrote: > > There's two things I'd like to know before going further with this: > > > > 1) according to RFC2578 section 3.6: > > (1)  registration: the definition of a pa

Re: OPENBSD-PF-MIB, use DisplayString not OCTET STRING

2021-03-21 Thread Martijn van Duren
There's two things I'd like to know before going further with this: 1) according to RFC2578 section 3.6: (1) registration: the definition of a particular item is registered as a particular OBJECT IDENTIFIER value, and associated with a particular descriptor. After such a registration,

Re: systat(1) sticky help

2021-03-09 Thread Martijn van Duren
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 information should disappear on the next input. Seems to work fine in my testing. OK? martijn@ On Thu,

snmpd - improve trap handle documentation

2021-03-03 Thread Martijn van Duren
When moving the traphandler code to snpme I overlooked some text in the "trap handle" section. This diff tries to rectify that. While here, try to be a little more clear in the "listen on" segment as well. OK? martijn@ Index: snmpd.conf.5

snmp(1) Fix some ranges and types

2021-03-02 Thread Martijn van Duren
Live and learn. While working on a regress test I found that I misunderstood some types when I wrote this code. According to RFC2578: - timeticks is a 32 bit unsigned int - counter32 is a 32 bit unsigned int - unsigned is "indistinguishable from Gauge32" - integer is a 32 bit integer OK?

Re: systat(1) sticky help

2021-02-28 Thread Martijn van Duren
might already be allocated by one of the views. When submitting your followup, try to make sure that you considered all possible issues, including the keybindings, and show how you came to your conclusion. > > Regards, > Anindya > > On Mon, Mar 01, 2021 at 07:49:49AM +0100, Martijn

Re: systat(1) sticky help

2021-02-28 Thread Martijn van Duren
Although the feature *might* be useful (just woken up, so haven't given it too much thought), the bindings have some problems and need to be reworked if we decide to get this in. Problems that I see from just a few short tests (so there might be others): - Entering sticky: H, which also enters

ober_get_string.3: s/byte/character

2021-02-22 Thread Martijn van Duren
As pointed out by claudio@, it makes more sense to talk about characters for fmt instead of bytes. The .Bl line already was >80 columns, but I don't know how to remedy this situation, so this diff makes that a little worse. martijn@ Index: ober_get_string.3

Re: snmpd: Add end of sequence tests

2021-02-12 Thread Martijn van Duren
On Fri, 2021-02-12 at 11:02 +0100, Claudio Jeker wrote: > On Fri, Feb 12, 2021 at 10:03:21AM +0100, Martijn van Duren wrote: > > ping > > > > On Sun, 2021-01-31 at 11:57 +0100, Martijn van Duren wrote: > > > Now that ober_scanf_elements supports '$' lets use it. &g

Re: snmpd: Add end of sequence tests

2021-02-12 Thread Martijn van Duren
ping On Sun, 2021-01-31 at 11:57 +0100, Martijn van Duren wrote: > Now that ober_scanf_elements supports '$' lets use it. > > Here's a first stab by adding it to snmpd. > Passing regress and a few manual checks. > > 'e' still doesn't consume the element, but I've talked it ove

snmpd: add transaction id to snmp_message

2021-02-02 Thread Martijn van Duren
Carefully taking some first looks into readding agentx master support to snmpd. One of the things we're going to need is a transaction id as per RFC2741 section 6.1 subsection h.transactionID: The transaction ID uniquely identifies, for a given session, the single SNMP

snmpd: Add end of sequence tests

2021-01-31 Thread Martijn van Duren
Now that ober_scanf_elements supports '$' lets use it. Here's a first stab by adding it to snmpd. Passing regress and a few manual checks. 'e' still doesn't consume the element, but I've talked it over with rob@, who said that shouldn't get in the way of using this new feature. OK? martijn@

Re: snmpd: remove print_{verbose,debug}

2021-01-28 Thread Martijn van Duren
ping On Sun, 2021-01-24 at 14:48 +0100, Martijn van Duren wrote: > Nothing seems to use them and I see no reason in the forseeable future > to start using them. > > OK? > > martijn@ > > Index: snmpd.h > =

Re: systat(1): improve parsing of delay value

2021-01-28 Thread Martijn van Duren
On Tue, 2021-01-26 at 16:40 +0100, Alexander Bluhm wrote: > On Mon, Jan 25, 2021 at 11:17:04AM +0100, Martijn van Duren wrote: > > if (argc == 1) { > > -   double del = atof(argv[0]); > > -   if (del == 0) > > +   delay = strto

Re: systat(1): improve parsing of delay value

2021-01-25 Thread Martijn van Duren
On Mon, 2021-01-25 at 10:50 +0100, Martijn van Duren wrote: > On Mon, 2021-01-25 at 08:15 +, Nick Gasson wrote: > > Hi, > > > > I incorrectly ran "systat netstat -N" instead of "systat -N netstat" and > > got confused why it wasn't resolvi

Re: systat(1): improve parsing of delay value

2021-01-25 Thread Martijn van Duren
On Mon, 2021-01-25 at 08:15 +, Nick Gasson wrote: > Hi, > > I incorrectly ran "systat netstat -N" instead of "systat -N netstat" and > got confused why it wasn't resolving host names. The -N gets parsed with > atof to a 0s delay that is then clamped to 5s. The patch below instead > prints an

snmpd: remove print_{verbose,debug}

2021-01-24 Thread Martijn van Duren
Nothing seems to use them and I see no reason in the forseeable future to start using them. OK? martijn@ Index: snmpd.h === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v retrieving revision 1.91 diff -u -p -r1.91 snmpd.h --- snmpd.h

Re: snmpd(8): Remove traphandler process attempt 2

2021-01-18 Thread Martijn van Duren
ping On Tue, 2021-01-05 at 22:24 +0100, Martijn van Duren wrote: > With the traphandler code beaten into submission I was able to keep the > traphandler process removal diff more manageable. This diff does a > couple things. > - "listen on" now accepts any combination of

ber: mandate end of sequence/set

2021-01-08 Thread Martijn van Duren
Right now we don't check for end of sequence or set in most ber places. This means that valid ber, but invalid ASN1 could be passed down the codepath. Since most of the parsing is done with ober_scanf_elements I think it would be a good idea to add a sequence limiter. rob@ likes the idea and

snmpd(8): Remove traphandler process attempt 2

2021-01-05 Thread Martijn van Duren
With the traphandler code beaten into submission I was able to keep the traphandler process removal diff more manageable. This diff does a couple things. - "listen on" now accepts any combination of read, write and notify. This combination removes the traphandler dependency on the generic

libagentx: Add notify (snmp trap) support

2021-01-04 Thread Martijn van Duren
const uint32_t[], size_t, +uint64_t); +void agentx_notify_send(struct agentx_notify *); Index: agentx_internal.h === RCS file: /cvs/src/lib/libagentx/agentx_internal.h,v retrieving revision 1.2 diff -u -p -r1.2 agentx_intern

Re: snmp - remove BER_TYPE_BOOLEAN

2021-01-04 Thread Martijn van Duren
On Mon, 2021-01-04 at 08:15 +0100, Rob Schmersel wrote: > On Sun, 03 Jan 2021 21:59:57 +0100 > Martijn van Duren wrote: > > > ping > > > > On Mon, 2020-12-14 at 12:13 +0100, Martijn van Duren wrote: > > > I can't find any reference in RFC2578 for a

Re: snmp - remove BER_TYPE_BOOLEAN

2021-01-03 Thread Martijn van Duren
ping On Mon, 2020-12-14 at 12:13 +0100, Martijn van Duren wrote: > I can't find any reference in RFC2578 for a boolean type, nor have I > seen it in the wild and the TruthValue diff I just committed give me a > strong indication that this was added without any real reason. > &g

snmpd(8) make traphandler more secure

2021-01-03 Thread Martijn van Duren
Right now snmpd's traphandler_parse and traphandler_v1translate are just weird to me and do very little ASN1 checking. Since I want to remove the traphandler process anyway and the current code structue is in the way, this diff is a logical first step towards that goal. The new

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-30 Thread Martijn van Duren
On Tue, 2020-12-29 at 08:57 +0100, Giovanni Bechis wrote: > On 12/20/20 12:21 AM, gil...@poolp.org wrote: > > December 19, 2020 11:26 PM, "Martijn van Duren" > > wrote: > > > > > Personally I'd rather wait to keep the names in sync, especially since

Re: smtpd: trim down on filter processes

2020-12-27 Thread Martijn van Duren
the SIGCHLD case does: if (WEXITSTATUS(status) != 0) { A little further down we also do: mda_sysexit = WEXITSTATUS(status); But mda_sysexit is only used for CHILD_MDA. So I don't see a reason why this subtle difference matters here. > > Martijn van Duren wrote: > > > Because filters

smtpd: trim down on filter processes

2020-12-27 Thread Martijn van Duren
Because filters use system(3) after forking we get 2 processes for every filter: one for waiting for system(3) to return and one running the actual filter. Since the extra smtpd process does absolutely nothing we can just as easily copy over what system(3) does internally for execve and call the

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-27 Thread Martijn van Duren
crypto API for encrypted queue so not > distinguishing > between crypto api and crypto agent might be confusing. > > Gilles > > > December 27, 2020 5:43 PM, "Martijn van Duren" > wrote: > > > This one reads OK to me, with one minor bikeshed: &g

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-27 Thread Martijn van Duren
. martijn@ On Sat, 2020-12-19 at 23:21 +, gil...@poolp.org wrote: > December 19, 2020 11:26 PM, "Martijn van Duren" > wrote: > > > Personally I'd rather wait to keep the names in sync, especially since > > it's an easy 2 line diff that can easily be incorperated in

Re: extern int optreset not needed

2020-12-27 Thread Martijn van Duren
OK martijn@ On Sat, 2020-12-26 at 23:24 +0100, Jan Stary wrote: > ftpd doesn't need to declare extern int optreset > as that is already done in the included unistd.h > > Jan > > Index: popen.c > === > RCS file:

Re: [diff] src/usr.sbin/smtpd: plug a memory leak in regex lookups

2020-12-23 Thread Martijn van Duren
Committed, thanks. On Wed, 2020-12-23 at 08:54 +0100, Gilles CHEHADE wrote: > Hello, > > The following diff plugs a memory leak in regex lookups. > > Cheers, > > > diff --git a/usr.sbin/smtpd/table.c b/usr.sbin/smtpd/table.c > index 4691..d1578403 100644 > --- a/usr.sbin/smtpd/table.c >

smtp(1) add authentication

2020-12-20 Thread Martijn van Duren
Playing around with the filter API I want an easier way to send mail with authentication instead of doing the transaction manually via openssl or via bloated mailclients. Turns out we already have all the plumbing in place and just need to hook it up. OK? martijn@ Index: smtpc.c

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-19 Thread Martijn van Duren
wrote: > I agree but I thought this should be done in a second time as it is quite > invasive and not required for the change to be visible outside the daemon > > > December 19, 2020 11:13 PM, "Martijn van Duren" > wrote: > > > I'm in favour of this cha

Re: [diff] src/usr.sbin/smtpd: change process names

2020-12-19 Thread Martijn van Duren
I'm in favour of this change, since I like proper nomenclature. But I think you should push this one to its logical conclusion and also rename the enum and potential other pony/klondike references, because with your diff the naming is inconsistent, which is even more confusing. martijn@ On Sat,

doas sprinkle some more CFLAGS

2020-12-18 Thread Martijn van Duren
So I ended up in doas again, this time with the CFLAGS I use for most of my other projects. This popped up a few new not very exciting warnings. Diff below compiles clean with both clang and gcc on amd64. Worth doing? martijn@ Index: Makefile

Re: fortune: allow to use symlinks

2020-12-15 Thread Martijn van Duren
On Tue, 2020-12-15 at 15:10 +0300, Vadim Zhukov wrote: > > I very rarely use fortune and I'm not familiar with the codebase, but > > from some quick testing and code-scanning I found the following: > > is_fortfile appends .dat to the input file and sees if it's accessible. > > Adding a symlink to

Re: fortune: allow to use symlinks

2020-12-15 Thread Martijn van Duren
I very rarely use fortune and I'm not familiar with the codebase, but from some quick testing and code-scanning I found the following: is_fortfile appends .dat to the input file and sees if it's accessible. Adding a symlink to the corresponding .dat file make the thing work perfectly well for me.

snmp - remove BER_TYPE_BOOLEAN

2020-12-14 Thread Martijn van Duren
I can't find any reference in RFC2578 for a boolean type, nor have I seen it in the wild and the TruthValue diff I just committed give me a strong indication that this was added without any real reason. OK to remove? martijn@ Index: usr.bin/snmp/smi.c

Re: snmpd drop traphandler process

2020-12-05 Thread Martijn van Duren
Found some minor issues. Please disregard for now. On Tue, 2020-12-01 at 17:12 +0100, Martijn van Duren wrote: > Hello tech@, > > Long story short: the traphandler process in snmpd annoys me a great > deal and is in the way for overhauling the transport mapping section >

snmpd drop traphandler process

2020-12-01 Thread Martijn van Duren
Hello tech@, Long story short: the traphandler process in snmpd annoys me a great deal and is in the way for overhauling the transport mapping section of snmpe, which is needed for implementing new agentx master support. The current traphandler process is also a joke, since all it does is

Re: cat(1): simplify/flatten argument loops

2020-11-30 Thread Martijn van Duren
This one reads a lot better to me and even shaves of 2LoC. :-) OK martijn@ On Mon, 2020-11-30 at 18:28 -0600, Scott Cheloha wrote: > Hi, > > The cook_args() and raw_args() functions in cat(1) are too clever. > They handle multiple special cases in a single big loop with lots of > branches. 

snmp trap usage

2020-11-30 Thread Martijn van Duren
I missed an argc check which causes snmp trap to segfault if called with too few arguments instead of showing usage. OK? martijn@ Index: snmpc.c === RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v retrieving revision 1.30 diff -u -p

Re: kvm_getfiles and KERN_FILE_BYFILE

2020-11-29 Thread Martijn van Duren
On Sun, 2020-11-29 at 16:15 -0800, Philip Guenther wrote: > On Sun, Nov 29, 2020 at 12:14 PM Martijn van Duren > wrote: > > On Sat, 2020-11-28 at 16:23 -0800, Philip Guenther wrote: > > > On Thu, Nov 26, 2020 at 1:08 PM Martijn van Duren > > > wrote: > > &g

Re: kvm_getfiles and KERN_FILE_BYFILE

2020-11-29 Thread Martijn van Duren
On Sat, 2020-11-28 at 16:23 -0800, Philip Guenther wrote: > On Thu, Nov 26, 2020 at 1:08 PM Martijn van Duren > wrote: > > I'm currently playing around a bit with kvm_getfiles and found that I > > couldn't use KERN_FILE_BYFILE with DTYPE_SOCKET. > > Acc

kvm_getfiles and KERN_FILE_BYFILE

2020-11-26 Thread Martijn van Duren
I'm currently playing around a bit with kvm_getfiles and found that I couldn't use KERN_FILE_BYFILE with DTYPE_SOCKET. According to kvm_getfiles(3): For KERN_FILE_BYFILE the recognized file types are defined in : DTYPE_VNODE files and devices DTYPE_SOCKET

Minor tweak relayd agentx manpage

2020-10-30 Thread Martijn van Duren
I think metrics is a better word than statistics and it might help people if they knew where to query for these metrics. OK? martijn@ Index: relayd.conf.5 === RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v retrieving revision

snmpd(8) Remove old listen on syntax

2020-10-29 Thread Martijn van Duren
6.8 has been released. Time to remove the old syntax. OK? martijn@ ? dispatcher_tm_udp.c Index: parse.y === RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v retrieving revision 1.61 diff -u -p -r1.61 parse.y --- parse.y 10 Sep 2020

relayd(8) remove snmp keyword

2020-10-29 Thread Martijn van Duren
6.8 is out in the wild. I guess this is as good a time as any to remove the old snmp keyword. OK? martijn@ Index: parse.y === RCS file: /cvs/src/usr.sbin/relayd/parse.y,v retrieving revision 1.248 diff -u -p -r1.248 parse.y ---

Re: libagentx add agentx_varbind_unsigned32

2020-10-27 Thread Martijn van Duren
On Tue, 2020-10-27 at 19:09 +0100, Martijn van Duren wrote: > To prevent any future confusion around unsigned ints I'd like to add > agentx_varbind_unsigned32 as an alias to agentx_varbind_gauge32. > > According to RFC 2578 section 2: > -- an unsigned 32-bit quantity > -- indi

libagentx add agentx_varbind_unsigned32

2020-10-27 Thread Martijn van Duren
To prevent any future confusion around unsigned ints I'd like to add agentx_varbind_unsigned32 as an alias to agentx_varbind_gauge32. According to RFC 2578 section 2: -- an unsigned 32-bit quantity -- indistinguishable from Gauge32 OK? Still OK to ride yesterdays bump? martijn@ Index:

libagentx use variable for malloc argument

2020-10-26 Thread Martijn van Duren
OK? martijn@ Index: ax.c === RCS file: /cvs/src/lib/libagentx/ax.c,v retrieving revision 1.2 diff -u -p -r1.2 ax.c --- ax.c26 Oct 2020 16:02:16 - 1.2 +++ ax.c26 Oct 2020 18:07:30 - @@ -69,9 +69,9 @@

Let relayd use libagentx

2020-10-26 Thread Martijn van Duren
Mostly mechanical diff coping with the API-change for libagentx just committed and link it to libagentx instead of using its own copy. This also allows for the removal of {sub,}agentx.[ch] subagentx_internal.h and subagentx_log.c, not included in the diff. OK? martijn@ Index: Makefile

Re: ping(8) put hop_limit warning in verbose mode

2020-10-20 Thread Martijn van Duren
On Tue, 2020-10-20 at 15:59 +0200, Florian Obser wrote: > On Tue, Oct 20, 2020 at 03:46:19PM +0200, Martijn van Duren wrote: > > On Tue, 2020-10-20 at 15:19 +0200, Florian Obser wrote: > > > On Tue, Oct 20, 2020 at 09:20:32AM +0200, Martijn van Duren wrote: > > >

Re: ping(8) put hop_limit warning in verbose mode

2020-10-20 Thread Martijn van Duren
On Tue, 2020-10-20 at 15:19 +0200, Florian Obser wrote: > On Tue, Oct 20, 2020 at 09:20:32AM +0200, Martijn van Duren wrote: > > I have an icinga-instance running on openbsd.amsterdam. Here I found > > that sometimes check_ping from the monitoring-plugins package fails, > >

ping(8) put hop_limit warning in verbose mode

2020-10-20 Thread Martijn van Duren
I have an icinga-instance running on openbsd.amsterdam. Here I found that sometimes check_ping from the monitoring-plugins package fails, because ping(8) sends "failed to get receiving hop limit", but still receives all the ping replies. These packets/annomalies are clearly not meant for us.

Re: Non-const basename: usr.bin/sed

2020-10-10 Thread Martijn van Duren
On Sat, 2020-10-10 at 17:21 +0200, Christian Weisgerber wrote: > Changing basename(3) and dirname(3) to the POSIX-mandated non-const > parameters produces this warnings when compiling sed(1): > > /usr/src/usr.bin/sed/main.c:401:16: warning: passing 'const char *' to > parameter > of type 'char

pthread_spin_unlock and ownership behaviour

2020-10-03 Thread Martijn van Duren
Back in 2012 kurt@ added an abort call for the undefined behaviour cases on pthread_mutex_unlock. This helped me a great deal in examining the cause of some weird behaviour in icinga (or in the case of openbsd, just plain crash). For shits and giggles I deceided to look into pthread_spin_unlock

snmp(1) Add support for printing human readable enums

2020-09-20 Thread Martijn van Duren
SNMP contains quite a few enumerations, which are annoying to read, even if you have the MIB at hand. This diff adds support for integer enumerations. I've only implemented TruthValue for now, but others should be easy to add. I went for a normal linear search since most enums don't even hit 10

Re: Fwd: opensmtpd can't handle long lines in aliases table

2020-09-18 Thread Martijn van Duren
That's what you get if you're doing a quick diff on the job. Missed a free case which is in Edgar's original diff. Noticed by tb@ On Fri, 2020-09-18 at 14:46 +0200, Martijn van Duren wrote: > Could you try the diff below? > It should do exactly the same thing with less code. >

Re: Fwd: opensmtpd can't handle long lines in aliases table

2020-09-18 Thread Martijn van Duren
Could you try the diff below? It should do exactly the same thing with less code. martijn@ On Fri, 2020-09-18 at 08:30 -0400, Aisha Tammy wrote: > Hi, > > Edgar (cc'ed) has kindly provided patches to fix a buffer error in > mailaddr.c > for opensmtpd. > > I've minimally tested it and am

syslogd close higher fds on pipe exec

2020-09-16 Thread Martijn van Duren
I don't think we should keep these fds around on exec. OK? Index: privsep.c === RCS file: /cvs/src/usr.sbin/syslogd/privsep.c,v retrieving revision 1.71 diff -u -p -r1.71 privsep.c --- privsep.c 5 Jul 2019 13:23:27 -

agentx in services

2020-09-15 Thread Martijn van Duren
I currently don't see any reason for adding agentx over tcp support to our daemons, but according to RFC2741 section 8.1.1 it should go over "wel-known port 705". Worth adding or just drop it? martijn@ Index: services === RCS file:

Re: agentx and clang static analyzer

2020-09-15 Thread Martijn van Duren
> > Index: subagentx.c > > === > > RCS file: /cvs/src/usr.sbin/relayd/subagentx.c,v > > retrieving revision 1.1 > > diff -u -p -r1.1 subagentx.c > > --- subagentx.c 14 Sep 2020 11:30:25 - 1.1 > > +++ subagentx.c 15

agentx and clang static analyzer

2020-09-15 Thread Martijn van Duren
There are 3 things that actually look like valid complaints when running clang's static analyzer. 1) A dead store in agentx_recv. 2) sizeof(ipaddress) intead of sizeof(*ipaddress). Since this is ipv4, this is only a problem if sizeof(pointer) is smaller then 4 bytes, which can't happen

snmp request specific OIDs from mibtree

2020-09-14 Thread Martijn van Duren
Sometimes I want to know the OID from a name and vice versa. I'm done doing these by hand. Diff below does this for me: $ ./obj/snmp mibtree -On snmpTrapOID.0 .1.3.6.1.6.3.1.1.4.1.0 OK? martijn@ Index: snmp.1 === RCS file:

Re: smtpd.conf add admd keyword

2020-09-12 Thread Martijn van Duren
Any takers? On Sun, 2020-09-06 at 17:06 +0200, Martijn van Duren wrote: > EHLO, > > RFC8601 defines the authentication-results header which can be used to > show the verification-results of DKIM, SPF, DMARC, and others. > > I can think of quite a few filters that cou

Re: snmpd refactor listen on grammar

2020-09-08 Thread Martijn van Duren
On Tue, 2020-09-08 at 19:33 +0200, Denis Fondras wrote: > On Sun, Sep 06, 2020 at 10:11:02PM +0200, Martijn van Duren wrote: > > Moving towards individual transport mappings, it's becoming more > > convenient to have the protocol directly after the listen on statement. > &g

snmpd refactor listen on grammar

2020-09-06 Thread Martijn van Duren
Moving towards individual transport mappings, it's becoming more convenient to have the protocol directly after the listen on statement. This gives me more flexibility in using mapping-specific APIs, also when other transport mappings might become available in the future it allows for easier

snmpd remove snmpe_dispatch_parent

2020-09-06 Thread Martijn van Duren
going for another easy picking: snmpe_dispatch_parent is just an empty stub. proc.c assigns proc_dispatch_null to p_cb if it's null, which effectively does the same thing. OK? martijn@ Index: snmpe.c === RCS file:

smtpd.conf add admd keyword

2020-09-06 Thread Martijn van Duren
EHLO, RFC8601 defines the authentication-results header which can be used to show the verification-results of DKIM, SPF, DMARC, and others. I can think of quite a few filters that could be build around this header: - the prior mentioned - detecting the header before accepting it into ones ADMD -

Document errno for ober_read_elements

2020-09-03 Thread Martijn van Duren
So here's my attempt at documenting errno for ober_read_elements. martijn@ Index: ober_read_elements.3 === RCS file: /cvs/src/lib/libutil/ober_read_elements.3,v retrieving revision 1.1 diff -u -p -r1.1 ober_read_elements.3 ---

Re: Add more errnos to ober_read_elements

2020-09-03 Thread Martijn van Duren
Apparently I missed one... On Thu, 2020-09-03 at 18:00 +0200, Martijn van Duren wrote: > Just reminded myself of this one. > The manpage says nothing about ober_read_elements setting errno upon > failure, yet it does in most cases. Furthermore, applications like > snm

Add more errnos to ober_read_elements

2020-09-03 Thread Martijn van Duren
Just reminded myself of this one. The manpage says nothing about ober_read_elements setting errno upon failure, yet it does in most cases. Furthermore, applications like snmpd use errno in ober_read_elements to determine if a read is incomplete (checking for ECANCELED), without initializing errno

Re: snmp df, use smi_print_element

2020-09-03 Thread Martijn van Duren
On Thu, 2020-09-03 at 09:49 +0200, Martijn van Duren wrote: > At the moment it's not wise to run "snmp df" against untrusted > instances, since it outputs the hrStorageDescr without checking the > bytes being printed. > > Make use of the new DISPLAY-HINT functional

snmp df, use smi_print_element

2020-09-03 Thread Martijn van Duren
At the moment it's not wise to run "snmp df" against untrusted instances, since it outputs the hrStorageDescr without checking the bytes being printed. Make use of the new DISPLAY-HINT functionality of smi.c to make sure the string is actually DisplayHint compliant. While here add the extra

<    1   2   3   4   5   6   7   >