/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 Joel Knight
+ *
+ * Permission to use
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
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
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
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
---
On Thu, Mar 9, 2017 at 10:02 PM, Joel Knight <knight.j...@gmail.com> 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 su
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 knight.j...@gmail.com
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 negotiates NAT-T
with
ASA
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:
/11 19:49:37 sthen Exp $
--
--- Copyright (c) 2004-2012 Joel Knight knight.j...@gmail.com
+-- Copyright (c) 2004-2013 Joel Knight knight.j...@gmail.com
--
-- Permission to use, copy, modify, and distribute this document for any
-- purpose with or without fee is hereby granted, provided
On Thu, May 24, 2012 at 8:16 AM, Kenneth R Westerback
kwesterb...@rogers.com 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,
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
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 knight.j...@gmail.com wrote
On Sat, Feb 18, 2012 at 5:02 PM, Peter N. M. Hansteen pe...@bsdly.net wrote:
Joel Knight knight.j...@gmail.com 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 fetched
On Fri, Jan 13, 2012 at 2:53 PM, Joel Knight knight.j...@gmail.com 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
carpnodes style
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 =
On Fri, Jan 13, 2012 at 2:53 PM, Joel Knight knight.j...@gmail.com 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
carpnodes style
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.
20 matches
Mail list logo
