Re: snmpd agentx.c cleanup

On Mon, Feb 12, 2018 at 03:03:07PM -0500, Rob Pierce wrote: > This reduces the diff with relayd/agentx.c. A little bit closer now. ok? Index: agentx.c === RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v retrieving revision 1.11 diff

sasyncd: schedule events against monotonic clock

So that events fire punctually even if the system clock is changed. ok? -- Scott Cheloha Index: usr.sbin/sasyncd/sasyncd.c === RCS file: /cvs/src/usr.sbin/sasyncd/sasyncd.c,v retrieving revision 1.27 diff -u -p -r1.27 sasyncd.c ---

snmpd agentx.c cleanup

This reduces the diff with relayd/agentx.c. Ok? Index: agentx.c === RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v retrieving revision 1.11 diff -u -p -r1.11 agentx.c --- agentx.c5 Jan 2018 08:13:32 - 1.11 +++ agentx.c

Re: date: atoll - > strtonum

OK millert@ - todd

Re: hostapd: normalize microsecond limit when parsing

On Mon, 12 Feb 2018 10:08:25 -0600, Scott Cheloha wrote: > I'm unfamiliar with this code, but assigning the microsecond value > without normalizing it for the timeval looks off. That makes sense. There's nothing preventing the user from using values > 100. OK millert@ - todd

date: atoll - > strtonum

ok? Index: bin/date/date.c === RCS file: /cvs/src/bin/date/date.c,v retrieving revision 1.51 diff -u -p -r1.51 date.c --- bin/date/date.c 23 Dec 2017 20:58:14 - 1.51 +++ bin/date/date.c 12 Feb 2018 16:29:24 - @@

hostapd: normalize microsecond limit when parsing

Hi, I'm unfamiliar with this code, but assigning the microsecond value without normalizing it for the timeval looks off. -- Scott Cheloha Index: usr.sbin/hostapd/parse.y === RCS file: /cvs/src/usr.sbin/hostapd/parse.y,v retrieving

Libressl question

Has there been any discussion of packaging libtls separately from libressl for portable use? With my limited skills I was able to write a program to talk to smtpd and starttls using nothing but the manuals. I seriously doubt I could have done so with the gnu tls library. This really shows how

Re: default route and route socket filter on priority

On 2018/02/12 15:23, Martin Pieuchot wrote: > On 12/02/18(Mon) 12:02, Sebastian Benoit wrote: > > routefilter currently filters the default route, > > if it's priority is higher than the filter prio. > > Then why not change the priority of the default route? On a standard machine this is already

Re: default route and route socket filter on priority

On 12/02/18(Mon) 12:02, Sebastian Benoit wrote: > routefilter currently filters the default route, > if it's priority is higher than the filter prio. Then why not change the priority of the default route? > This might not be a good idea - for example you might want to > redistribute a default

Re: ip6_sysctl_soiikey: use IP6_SOIIKEY_LEN instead of hardcoded value

ok Sebastien Marie(sema...@online.fr) on 2018.02.12 10:07:48 +0100: > Hi, > > I think it is preferable to not hardcode IP6_SOIIKEY_LEN in > ip6_sysctl_soiikey(). > > No changes expected, as IP6_SOIIKEY_LEN is 16. > > netinet6/ip6_var.h >295 #define IP6_SOIIKEY_LEN 16 >296 extern

default route and route socket filter on priority

routefilter currently filters the default route, if it's priority is higher than the filter prio. This might not be a good idea - for example you might want to redistribute a default route into ospf, for that you need it in the routing table but it is configured with a low priority (high value)

Re: Fixed sys_socket() plumbing

On Mon, Feb 12, 2018 at 09:22:54AM +0100, Martin Pieuchot wrote: > I found my mistake in the previous diff. `SS_NBIO' was never set on > non blocking sockets. Diff below fixes that by checking `nonblock' > like it is done in sys_socketpair(). > > Tests & oks welcome :) Running with it now on

ip6_sysctl_soiikey: use IP6_SOIIKEY_LEN instead of hardcoded value

Hi, I think it is preferable to not hardcode IP6_SOIIKEY_LEN in ip6_sysctl_soiikey(). No changes expected, as IP6_SOIIKEY_LEN is 16. netinet6/ip6_var.h 295 #define IP6_SOIIKEY_LEN 16 296 extern uint8_t ip6_soiikey[IP6_SOIIKEY_LEN]; Thanks. -- Sebastien Marie Index:

goto in ptrace_ctrl()

Diff below introduce multiple 'goto fail' in ptrace_ctrl(). It is extracted from guenther@'s proctreelk diff because it doesn't introduce any change in behavior. I'd like to get it in to shrink the locking diff. ok? Index: kern/sys_process.c

Fixed sys_socket() plumbing

I found my mistake in the previous diff. `SS_NBIO' was never set on non blocking sockets. Diff below fixes that by checking `nonblock' like it is done in sys_socketpair(). Tests & oks welcome :) Index: kern/uipc_syscalls.c === RCS