d_atfork_on_fork.c
diff -N regress/lib/libpthread/pthread_atfork_on_fork/pthread_atfork_on_fork.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ regress/lib/libpthread/pthread_atfork_on_fork/pthread_atfork_on_fork.c
7 Dec 2022 04:59:10 -
@@ -0,0 +1,94 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2022
We have a winner here. I tested from INIT through to REBINDING and the
behavior matches what's in the RFC now. ok joel@
One cosmetic thing I noticed this time around: log_dhcp_hdr() in
engine.c should be printing dhcp_hdr->xid in host byte order.
.joel
On Fri, Dec 3, 2021 at 5:21 AM Florian Ob
On Wed, Nov 24, 2021 at 4:46 AM Florian Obser wrote:
> Thanks, I had indeed missed this. I went through the RFC and found that
> we MUST NOT send the server identifier in rebooting state. While here I
> also made it explicit that we are not sending server identifier in
> rebinding state. This was
On Fri, Nov 19, 2021 at 1:01 PM Joel Knight wrote:
>
> One thing that got missed in the refactor was that the requested-ip
> option should not be set in a RENEWING or BINDING state (or in other
> words, when ciaddr is set). This chunk on top of your diff also works
> as expec
On Tue, Nov 16, 2021 at 9:56 AM Joel Knight wrote:
>
> Inspecting the REQUEST packets showed that dhclient was setting the
> ciaddr to the existing leased IP address while dhcpleased was not
> setting this field. RFC 2131 4.3.2 (with a nice summary at 4.3.6) is
> pretty strict ab
Hi. On a firewall recently upgraded to 7.0, I noticed that dhcpleased
was not getting a reply from my ISP's DHCP server during renewal at
T1. At T2, dhcpleased would broadcast the REQUEST which would be
answered. Testing with dhclient showed successful renewals at T1.
Inspecting the REQUEST packet
Small fix to the description of the pfCntProtoCksum oid:
Index: share/snmp/OPENBSD-PF-MIB.txt
===
RCS file: /data/cvs-mirror/OpenBSD/src/share/snmp/OPENBSD-PF-MIB.txt,v
retrieving revision 1.5
diff -p -u -r1.5 OPENBSD-PF-MIB.txt
--- s
On Thu, Mar 9, 2017 at 10:02 PM, Joel Knight wrote:
> Hi.
>
> snmpd(8) uses unsigned ints internally to represent the size and used
> space of a file system. The HOST-RESOURCES-MIB defines the valid
> values for those OIDs as 0..2147483647. With sufficiently large file
> syste
Hi.
snmpd(8) uses unsigned ints internally to represent the size and used
space of a file system. The HOST-RESOURCES-MIB defines the valid
values for those OIDs as 0..2147483647. With sufficiently large file
systems, this can cause negative numbers to be returned for the size
and used space OIDs.
; isakmpd already sends the values from the RFC doesn't it?
>
> On 2 February 2014 00:23:19 GMT+00:00, Joel Knight
> wrote:
> >Hi.
> >
> >I found an old post of sthen's to tech@ about NAT-T interop between
> >isakmpd(8) and Cisco ASA. In summary, when isakmpd
Hi.
I found an old post of sthen's to tech@ about NAT-T interop between
isakmpd(8) and Cisco ASA. In summary, when isakmpd negotiates NAT-T with
ASA, it doesn't send the proper encapsulation mode (as per RFC 3947).
Original post is here:
http://openbsd.7691.n7.nabble.com/isakmpd-NAT-T-interoperabi
.2 2013/03/11 19:49:37 sthen Exp $
--
--- Copyright (c) 2004-2012 Joel Knight
+-- Copyright (c) 2004-2013 Joel Knight
--
-- Permission to use, copy, modify, and distribute this document for any
-- purpose with or without fee is hereby granted, provided that the above
@@ -43,6 +43,8 @@ pf
On Thu, May 24, 2012 at 8:16 AM, Kenneth R Westerback
wrote:
> Calling mib_carpget() seems a tad over complex. Wouldn't the diff
> below make it cleaner? Untested except by gcc.
>
> And doesn't the socket 's' leak too, or does SIOCGVH returning -1
> mean 's' was closed?
Ken,
Your diff looks goo
On Sat, Feb 18, 2012 at 5:02 PM, Peter N. M. Hansteen wrote:
> Joel Knight writes:
>
>> Looks like there's an issue pulling the diff with lynx or curl. If you
>> use Firefox or Chrome it seems to work fine. Not sure what's going on.
>
> looks clean when f
Looks like there's an issue pulling the diff with lynx or curl. If you
use Firefox or Chrome it seems to work fine. Not sure what's going on.
The diff is also on dropbox now.
http://dl.dropbox.com/u/34631638/snmpd.pf.diff
On Sat, Feb 18, 2012 at 2:34 PM, Joel Knight wrote:
> H
Hi,
Here's the patch to bring the PF-MIB to snmpd. It provides the same
OIDs that my patches for net-snmp provide. Some differences:
- This implementation uses the OpenBSD enterprise number (30155)
instead of a private/reserved number
- Many of the OID names have been changed to make them less am
Hi,
If the kernel sensor doesn't have a description, snmpd should fill
something into that column to avoid an empty value. An empty value
makes it really hard to tell what the sensor is.
Before:
SNMPv2-SMI::enterprises.30155.2.1.2.1.2.1 = ""
SNMPv2-SMI::enterprises.30155.2.1.2.1.2.2 = ""
SNMPv2-
On Fri, Jan 13, 2012 at 2:53 PM, Joel Knight wrote:
> Hi,
>
> This diff integrates my existing snmp MIB for carp(4) into the base
> snmpd. I brought the MIB straight across with no changes. The only
> limitation I'm aware of is that it doesn't support the multiple
> c
On Fri, Jan 13, 2012 at 2:53 PM, Joel Knight wrote:
> Hi,
>
> This diff integrates my existing snmp MIB for carp(4) into the base
> snmpd. I brought the MIB straight across with no changes. The only
> limitation I'm aware of is that it doesn't support the multiple
> c
Hi,
This diff integrates my existing snmp MIB for carp(4) into the base
snmpd. I brought the MIB straight across with no changes. The only
limitation I'm aware of is that it doesn't support the multiple
carpnodes style loadbalancing; it only reports status on the main
carpnode.
http://www.packetm
20 matches
Mail list logo