Re: time(1): use monotonic clock for computing elapsed time

> On 13 Jul 2017, at 11:16 am, Scott Cheloha wrote: > > Hi, > > The "real" elapsed time for time(1) and the ksh/csh time builtins is > currently computed with gettimeofday(2), so it's subject to changes > by adjtime(2) and, if you're really unlucky, clock_settime(2) or

Re: time(1): use monotonic clock for computing elapsed time

Whoops, prior diff for usr.bin/time/time.c has a dumb typo, corrected diff attached. -- Scott Cheloha Index: usr.bin/time/time.c === RCS file: /cvs/src/usr.bin/time/time.c,v retrieving revision 1.21 diff -u -p -r1.21 time.c ---

time(1): use monotonic clock for computing elapsed time

Hi, The "real" elapsed time for time(1) and the ksh/csh time builtins is currently computed with gettimeofday(2), so it's subject to changes by adjtime(2) and, if you're really unlucky, clock_settime(2) or settimeofday(2). In pathological cases you can get negative values in the output. This

Re: ypldap debugging tweak

Kurt Mosiejczuk writes: > While trying out ypldap (using ypldap -dv) I got a bit confused at one point > because I just saw "flattening trees" and nothing else. My LDAP source does > have a *lot* of users, so thought maybe it was crunching for a bit. Nope. > My config

Re: Remove getopt from vipw

Matthew Martin writes: > As far as I can tell the only thing gained from using getopt is handling > vipw -- > as vipw takes no flags or arguments, is not intended for non-interactive > use, and is not POSIX, I don't see a reason -- should be handled. I don't see a reason

Re: relayd ipv6 ttl check_icmp / check_tcp

Kapetanakis Giannis writes: > On 12/07/17 22:00, Jeremie Courreges-Anglas wrote: >> The tweak I had in mind: consistently use "ttl" for all the >> get/setsockopt calls. >> >> ok? > > nice, > you can also replace sizeof(int) to sizeof(ttl) on the else{} block of > case

Re: relayd ipv6 ttl check_icmp / check_tcp

On 12/07/17 22:00, Jeremie Courreges-Anglas wrote: The tweak I had in mind: consistently use "ttl" for all the get/setsockopt calls. ok? nice, you can also replace sizeof(int) to sizeof(ttl) on the else{} block of case AF_INET6 G Index: check_icmp.c

Re: relayd ipv6 ttl check_icmp / check_tcp

Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2017.07.12 21:00:44 +0200: > Jeremie Courreges-Anglas writes: > > > Kapetanakis Giannis writes: > > > >> On 10/07/17 17:22, Jeremie Courreges-Anglas wrote: > >>> Using -1 for IPV6_UNICAST_HOPS is correct. >

Re: urndis issues

Hi, Thanks I was cooking the same diff. Ok armani@ Le mar. 11 juil. 2017 à 12:32, Mike Belopuhov a écrit : > On Sun, Jul 09, 2017 at 09:57 +0300, Artturi Alm wrote: > > Hi, > > > > anyone else having issues w/urndis(android)? > > victim of circumstances, i have to rely on

Re: armv7 small XXX fix

On Wed, Jul 12, 2017 at 11:06:23PM +0300, Artturi Alm wrote: > On Wed, Jul 12, 2017 at 06:12:34PM +0200, Mark Kettenis wrote: > > > Date: Mon, 10 Jul 2017 23:18:59 +0300 > > > From: Artturi Alm > > > > > > Hi, > > > > > > this does clutter my diffs, and the XXX comment is

Re: armv7 small XXX fix

On Wed, Jul 12, 2017 at 06:12:34PM +0200, Mark Kettenis wrote: > > Date: Mon, 10 Jul 2017 23:18:59 +0300 > > From: Artturi Alm > > > > Hi, > > > > this does clutter my diffs, and the XXX comment is correct, > > It probably isn't. None of the other architectures have

Re: urndis issues

On Tue, Jul 11, 2017 at 12:32:30PM +0200, Mike Belopuhov wrote: > On Sun, Jul 09, 2017 at 09:57 +0300, Artturi Alm wrote: > > Hi, > > > > anyone else having issues w/urndis(android)? > > victim of circumstances, i have to rely on it at times during the summer. > > When i plug phone into usb, and

Re: relayd ipv6 ttl check_icmp / check_tcp

Jeremie Courreges-Anglas writes: > Kapetanakis Giannis writes: > >> On 10/07/17 17:22, Jeremie Courreges-Anglas wrote: >>> Using -1 for IPV6_UNICAST_HOPS is correct. >>> >>> Note that you can also use -1 for IP_TTL on OpenBSD, sadly some systems >>>

Re: SSHFP with EDNS0/DNSSEC

Eric Faurot writes: > On Wed, Jul 12, 2017 at 07:45:36AM +0200, Christian Barthel wrote: >> Hi, >> >> earlier this year, jca@ worked on support for DNSSEC and the EDNS0 >> extension [1] and committed this work at [2] (thanks!). I tried this >> with SSHFP records to check

Re: Use modesetting driver on i965 and up

> From: "Ted Unangst" > Date: Mon, 10 Jul 2017 17:36:00 -0400 > > Mark Kettenis wrote: > > This diff has been in snaps for a while now. This matches what > > several major Linux distros do. > > > > ok? > > for those of us who haven't memorized hex PCI IDs, can we add a

Re: armv7 small XXX fix

> Date: Mon, 10 Jul 2017 23:18:59 +0300 > From: Artturi Alm > > Hi, > > this does clutter my diffs, and the XXX comment is correct, It probably isn't. None of the other architectures have those macros in their . > currently used _C_LABEL() is nothing, and i find it's

Re: Potential DoS attack on PF due to infinite loop

On Tue, Jul 11, 2017 at 12:29:33PM -0700, Jingmin Zhou wrote: > Recently we discovered a potential bug in pf_lb.c. I have commited a fix. Thanks for the report and analysis. bluhm

Re: Potential DoS attack on PF due to infinite loop

On Wed, Jul 12, 2017 at 02:40:58PM +0200, Alexander Bluhm wrote: > On Tue, Jul 11, 2017 at 12:29:33PM -0700, Jingmin Zhou wrote: > > The problem is at line 224. When a LB rule is configured to have 65535 as > > the high port, and uint16 variable tmp reaches it, ++(tmp) will wrap around > > and

Re: Potential DoS attack on PF due to infinite loop

On Tue, Jul 11, 2017 at 12:29:33PM -0700, Jingmin Zhou wrote: > The problem is at line 224. When a LB rule is configured to have 65535 as > the high port, and uint16 variable tmp reaches it, ++(tmp) will wrap around > and hence potentially enter into an infinite loop. Of course, it only > happens

Re: first stab at RFC 7217: random but stable link local addresses

On Wed, Jul 12, 2017 at 01:45:36PM +1000, David Gwynne wrote: > On Tue, Jul 11, 2017 at 11:48:47AM +, Florian Obser wrote: > > On Tue, Jul 11, 2017 at 11:08:23AM +0100, Stuart Henderson wrote: > > > On 2017/07/11 07:45, Florian Obser wrote: > > > > The way I want to move forward with this is:

Re: SSHFP with EDNS0/DNSSEC

On Wed, Jul 12, 2017 at 07:45:36AM +0200, Christian Barthel wrote: > Hi, > > earlier this year, jca@ worked on support for DNSSEC and the EDNS0 > extension [1] and committed this work at [2] (thanks!). I tried this > with SSHFP records to check authenticity of hosts with DNSSEC; but ssh >

Re: Remove accents from fortunes

On Wed, Jul 12, 2017 at 12:07:47AM -0600, Anthony J. Bentley wrote: > Ingo Schwarze writes: > > So here is a patch that makes putting UTF-8 characters into > > fortune/datfiles safe. > > And here is a patch that retains the accents in the datfiles as UTF-8. ok one comment: > Index:

Re: Remove accents from fortunes

On Wed, Jul 12, 2017 at 12:07:47AM -0600, Anthony J. Bentley wrote: > Ingo Schwarze writes: > > So here is a patch that makes putting UTF-8 characters into > > fortune/datfiles safe. > > And here is a patch that retains the accents in the datfiles as UTF-8. ok

Re: remove CPU_LIDSUSPEND/machdep.lidsuspend

On Tue, Jul 11, 2017 at 02:40:16PM -0700, Mike Larkin wrote: > On Tue, Jul 11, 2017 at 11:19:17PM +0200, Martin Natano wrote: > > Go ahead replacing machdep.lidsuspend with cpu.lidaction. OpenBSD 6.1 > > cpu.lidaction or machdep.lidaction? machdep.lidaction; I got confused by the #define name.

Re: Remove accents from fortunes

Ingo Schwarze writes: > So here is a patch that makes putting UTF-8 characters into > fortune/datfiles safe. And here is a patch that retains the accents in the datfiles as UTF-8. Index: Notes === RCS file: