dhcpleased(8): handle gateway outside configured address prefix
I hear there are circuses out there where the dhcp server hands us a /32
and so the default gateway is not reachable.
The comment in sbin/dhclient/kroute.c suggests that the Google Clown
Platform operates in this way. I seem to recall mumblings that Hetzner
does something similar on their VPS.
Currently dhcpleased(8) will not work in such setups, I think this diff
fixes it. Could someone tests this please in the real world?
(This is currently two diffs in one, a bunch of deck chair shuffling and
fixing the actual problem. I'll work on classes static routes option
next to see if the deck chairs have been shuffled sufficiently. Not
asking for OKs just yet.)
diff --git dhcpleased.c dhcpleased.c
index 46685012402..14bd26eb01b 100644
--- dhcpleased.c
+++ dhcpleased.c
@@ -77,7 +77,9 @@ void open_bpfsock(uint32_t);
voidconfigure_interface(struct imsg_configure_interface *);
voiddeconfigure_interface(struct imsg_configure_interface *);
voidpropose_rdns(struct imsg_propose_rdns *);
-voidconfigure_gateway(struct imsg_configure_interface *, uint8_t);
+voidconfigure_routes(uint8_t, struct imsg_configure_interface *);
+voidconfigure_route(uint8_t, uint32_t, int, struct sockaddr_in *, struct
+sockaddr_in *, struct sockaddr_in *, struct sockaddr_in *, int);
voidread_lease_file(struct imsg_ifinfo *);
static int main_imsg_send_ipc_sockets(struct imsgbuf *, struct imsgbuf *);
@@ -683,9 +685,8 @@ configure_interface(struct imsg_configure_interface *imsg)
if (ioctl(ioctl_sock, SIOCAIFADDR, ) == -1)
fatal("SIOCAIFADDR");
- /* XXX check weird shit in dhclient/kroute.c set_routes() */
if (imsg->router.s_addr != INADDR_ANY)
- configure_gateway(imsg, RTM_ADD);
+ configure_routes(RTM_ADD, imsg);
}
req_sin_addr->sin_port = ntohs(CLIENT_PORT);
if ((udpsock = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
@@ -774,7 +775,7 @@ deconfigure_interface(struct imsg_configure_interface *imsg)
memset(, 0, sizeof(ifaliasreq));
if (imsg->router.s_addr != INADDR_ANY)
- configure_gateway(imsg, RTM_DELETE);
+ configure_routes(RTM_DELETE, imsg);
if (if_indextoname(imsg->if_index, ifaliasreq.ifra_name) == NULL) {
log_warnx("%s: cannot find interface %d", __func__,
@@ -795,14 +796,66 @@ deconfigure_interface(struct imsg_configure_interface
*imsg)
}
}
+/* XXX check weird shit in dhclient/kroute.c set_routes() */
+void
+configure_routes(uint8_t rtm_type, struct imsg_configure_interface *imsg)
+{
+ struct sockaddr_in dst, gw, mask, ifa;
+ in_addr_taddrnet, gwnet;
+
+ memset(, 0, sizeof(ifa));
+ memcpy(_addr, >addr, sizeof(ifa.sin_addr));
+ ifa.sin_family = AF_INET;
+ ifa.sin_len = sizeof(struct sockaddr_in);
+
+ addrnet = imsg->addr.s_addr & imsg->mask.s_addr;
+ gwnet = imsg->router.s_addr & imsg->mask.s_addr;
+ if (addrnet != gwnet) {
+ /*
+ The gateway for the default route is outside the configured
+ prefix. Install a direct cloning route for the gateway to
+ make the default route reachable.
+ */
+ memset(, 0, sizeof(dst));
+ memcpy(_addr, >router, sizeof(gw.sin_addr));
+ dst.sin_family = AF_INET;
+ dst.sin_len = sizeof(struct sockaddr_in);
+
+ memset(, 0, sizeof(mask));
+ mask.sin_family = AF_INET;
+ mask.sin_addr.s_addr = 0x;
+ mask.sin_len = sizeof(struct sockaddr_in);
+
+ configure_route(rtm_type, imsg->if_index, imsg->rdomain, ,
+ , , , RTF_CLONING);
+ }
+
+ memset(, 0, sizeof(dst));
+ dst.sin_family = AF_INET;
+ dst.sin_len = sizeof(struct sockaddr_in);
+
+ memset(, 0, sizeof(gw));
+ memcpy(_addr, >router, sizeof(gw.sin_addr));
+ gw.sin_family = AF_INET;
+ gw.sin_len = sizeof(struct sockaddr_in);
+
+ memset(, 0, sizeof(mask));
+ mask.sin_family = AF_INET;
+ mask.sin_len = sizeof(struct sockaddr_in);
+
+ configure_route(rtm_type, imsg->if_index, imsg->rdomain, , ,
+ , , RTF_GATEWAY);
+}
+
#defineROUNDUP(a) \
(((a) & (sizeof(long) - 1)) ? (1 + ((a) | (sizeof(long) - 1))) : (a))
void
-configure_gateway(struct imsg_configure_interface *imsg, uint8_t rtm_type)
+configure_route(uint8_t rtm_type, uint32_t if_index, int rdomain, struct
+sockaddr_in *dst, struct sockaddr_in *gw, struct sockaddr_in *mask, struct
+sockaddr_in *ifa, int rtm_flags)
{
struct rt_msghdr rtm;
struct sockaddr_rtlabel rl;
- struct sockaddr_in dst, gw, mask, ifa;
struct iovec iov[12];
long
setitimer(2): increase interval upper bound to UINT_MAX seconds
Hi,
setitimer(2) has a one hundred million second upper bound for timers.
Any timer interval larger than this is considered invalid and we set
EINVAL.
There is no longer any reason to use this particular limit. Kclock
timeouts support the full range of a timespec, so we can trivially
increase the upper bound without any practical risk of overflow.
This patch increases the upper bound to UINT_MAX seconds.
Why UINT_MAX? UINT_MAX is the largest possible input to alarm(3). We
could then simplify the alarm(3) manpage and the libc alarm.c code in
a subsequent patch. POSIX says alarm(3) "is always successful". Our
implementation can fail. It would be nicer/simpler if ours were free
of failure modes.
ok?
Index: kern_time.c
===
RCS file: /cvs/src/sys/kern/kern_time.c,v
retrieving revision 1.153
diff -u -p -r1.153 kern_time.c
--- kern_time.c 11 Jun 2021 16:36:34 - 1.153
+++ kern_time.c 11 Jun 2021 17:13:49 -
@@ -709,15 +709,16 @@ out:
int
itimerfix(struct itimerval *itv)
{
+ struct timeval max_interval = { .tv_sec = UINT_MAX, .tv_usec = 0 };
struct timeval min_interval = { .tv_sec = 0, .tv_usec = tick };
if (itv->it_value.tv_sec < 0 || !timerisvalid(>it_value))
return EINVAL;
- if (itv->it_value.tv_sec > 1)
+ if (timercmp(>it_value, _interval, >))
return EINVAL;
if (itv->it_interval.tv_sec < 0 || !timerisvalid(>it_interval))
return EINVAL;
- if (itv->it_interval.tv_sec > 1)
+ if (timercmp(>it_interval, _interval, >))
return EINVAL;
if (!timerisset(>it_value))
Document missing pledge promises
Here's my take at documenting the missing pledge promises in pledge.2
and placing them in a reasonable order with the others. Each of these
just enabled various ioctl or sysctl interfaces.
I'm unhappy with the explanation for drm, but don't know how to
explain the purpose of these ioctls, and could not find any man page
to .Xr which documents these ioctl commands.
diff db8264de5e686d467fdfaede154dd2a2b3b1dc3d /usr/src
blob - 5794003962d7bc22bb4bb10471ed6f3381383cdf
file + lib/libc/sys/pledge.2
--- lib/libc/sys/pledge.2
+++ lib/libc/sys/pledge.2
@@ -498,6 +498,24 @@ programs like
.Xr top 1
and
.Xr vmstat 8 .
+.It Va vmm
+Allows a subset of
+.Xr ioctl 2
+operations on the
+.Xr vmm 4
+device:
+.Pp
+.Dv VMM_IOC_CREATE ,
+.Dv VMM_IOC_RUN ,
+.Dv VMM_IOC_INFO ,
+.Dv VMM_IOC_TERM ,
+.Dv VMM_IOC_RESETCPU ,
+.Dv VMM_IOC_INTR ,
+.Dv VMM_IOC_READREGS ,
+.Dv VMM_IOC_WRITEREGS ,
+.Dv VMM_IOC_READVMPARAMS ,
+.Dv VMM_IOC_WRITEVMPARAMS ,
+.Dv VMM_IOC_MPROTECT_EPT
.It Va id
Allows the following system calls which can change the rights of a
process:
@@ -579,12 +597,27 @@ devices:
.Dv VIDIOC_STREAMON ,
.Dv VIDIOC_TRY_FMT ,
.Dv VIDIOC_REQBUFS
+.It Va drm
+Allows a subset of
+.Xr ioctl 2
+operations on
+.Xr drm 4
+devices.
.It Va bpf
Allow
.Dv BIOCGSTATS
operation for statistics collection from a
.Xr bpf 4
device.
+.It Va disklabel
+Allow enough
+.Xr sysctl 2
+interfaces to allow inspection of
+.Xr disklabel 5
+partitions by programs like
+.Xr disklabel 8
+and
+.Xr fdisk 8 .
.It Va unveil
Allow
.Xr unveil 2
blob - a8e23adf2a48afcb82c4118a45b76ad3060c1069
file + sys/sys/pledge.h
--- sys/sys/pledge.h
+++ sys/sys/pledge.h
@@ -100,18 +100,18 @@ static const struct {
{ PLEDGE_SETTIME, "settime" },
{ PLEDGE_PS,"ps" },
{ PLEDGE_VMINFO,"vminfo" },
+ { PLEDGE_VMM, "vmm" },
{ PLEDGE_ID,"id" },
{ PLEDGE_PF,"pf" },
{ PLEDGE_ROUTE, "route" },
{ PLEDGE_WROUTE,"wroute" },
{ PLEDGE_AUDIO, "audio" },
{ PLEDGE_VIDEO, "video" },
+ { PLEDGE_DRM, "drm" },
{ PLEDGE_BPF, "bpf" },
+ { PLEDGE_DISKLABEL, "disklabel" },
{ PLEDGE_UNVEIL,"unveil" },
{ PLEDGE_ERROR, "error" },
- { PLEDGE_DISKLABEL, "disklabel" },
- { PLEDGE_DRM, "drm" },
- { PLEDGE_VMM, "vmm" },
{ 0, NULL },
};
#endif
Re: pcidevs + azalia: patch for new intel audio
Jonathan Gray writes: > I can't find 0xf0c8 in the datasheets either. > > I've committed this but moved the added line in pcidevs to maintain > ordering by device id. Thanks for the patch. Great, thank you!
Re: ssh/sshd configuration parsing
I do not consider it necessarily a bug so I did not send this bugs@, but this did impact ProxyJump in my ~/.ssh/config. I'd formerly had: ProxyJump host, anotherhost This currently/now fails with "Invalid ProxyJump". Re-checking the ssh_config manual page though I saw the clarification of "separated by comma" - not "comma and whitespace". That combined with IRC pointing me here got me back running again once I removed the whitespace and went to: ProxyJump host,anotherhost Not a complaint just wanted to make breadcrumbs for anyone else searching for the same new behaviour.
Re: pcidevs + azalia: patch for new intel audio
Friendly ping.
Ashton Fagg writes:
> My new Intel Z590-based machine seems to have some different kind of
> Intel audio device onboard.
>
> I couldn't find very much online about it (all the usual pci id
> databases don't seem to have it yet). The only really useful thing I
> found was this:
>
> https://github.com/torvalds/linux/commit/f84d3a1ec375e46a55cc3ba85c04272b24bd3921#diff-bfe681fff464a07274400d493ba696cc6e10649a993ae7c1cfc1c29a106feda0
>
> This doesn't give much info but seems to indicate that it's a variant of
> some existing chip.
>
> I gave this the not very descriptive name of
> "PCI_PRODUCT_INTEL_500SERIES_HDA_2", since that's about all I could come
> up with, since I'm assuming it's a variant of
> "PCI_PRODUCT_INTEL_500SERIES_HDA".
>
> Patch which defines device in pcidevs and tells azalia how to
> configure it is attached. Playback was the only thing I could readily
> test and that's working - so my itch here has been scratched.
>
> I've also attached a dmesg output and a pcidump output (dmesg has also
> been sent to dmesg@).
>
> Feedback greatly welcomed.
>
> Before:
>
> azalia0 at pci0 dev 31 function 3 vendor "Intel", unknown product 0xf0c8 rev
> 0x11: msi
> azalia0: codecs: Realtek/0x0897, 0x/0x, using Realtek/0x0897
> audio0 at azalia0
>
> After:
>
> azalia0 at pci0 dev 31 function 3 "Intel 500 Series HD Audio" rev 0x11: msi
> azalia0: codecs: Realtek/0x0897, 0x/0x, using Realtek/0x0897
> audio0 at azalia0
Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.262
diff -u -p -u -p -r1.262 azalia.c
--- sys/dev/pci/azalia.c 30 May 2021 02:54:36 - 1.262
+++ sys/dev/pci/azalia.c 1 Jun 2021 01:20:42 -
@@ -470,6 +470,7 @@ azalia_configure_pci(azalia_t *az)
case PCI_PRODUCT_INTEL_400SERIES_LP_HDA:
case PCI_PRODUCT_INTEL_495SERIES_LP_HDA:
case PCI_PRODUCT_INTEL_500SERIES_HDA:
+ case PCI_PRODUCT_INTEL_500SERIES_HDA_2:
case PCI_PRODUCT_INTEL_500SERIES_LP_HDA:
case PCI_PRODUCT_INTEL_C600_HDA:
case PCI_PRODUCT_INTEL_C610_HDA_1:
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1970
diff -u -p -u -p -r1.1970 pcidevs
--- sys/dev/pci/pcidevs 19 May 2021 05:20:48 - 1.1970
+++ sys/dev/pci/pcidevs 1 Jun 2021 01:20:42 -
@@ -5371,6 +5371,7 @@ product INTEL 500SERIES_PCIE_22 0x43c5 5
product INTEL 500SERIES_PCIE_23 0x43c6 500 Series PCIE
product INTEL 500SERIES_PCIE_24 0x43c7 500 Series PCIE
product INTEL 500SERIES_HDA 0x43c8 500 Series HD Audio
+product INTEL 500SERIES_HDA_2 0xf0c8 500 Series HD Audio
product INTEL 500SERIES_THC_0 0x43d0 500 Series THC
product INTEL 500SERIES_THC_1 0x43d1 500 Series THC
product INTEL 500SERIES_AHCI_1 0x43d2 500 Series AHCI
Index: sys/dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1964
diff -u -p -u -p -r1.1964 pcidevs.h
--- sys/dev/pci/pcidevs.h 19 May 2021 05:21:24 - 1.1964
+++ sys/dev/pci/pcidevs.h 1 Jun 2021 01:20:42 -
@@ -5376,6 +5376,7 @@
#define PCI_PRODUCT_INTEL_500SERIES_PCIE_23 0x43c6 /* 500 Series PCIE */
#define PCI_PRODUCT_INTEL_500SERIES_PCIE_24 0x43c7 /* 500 Series PCIE */
#define PCI_PRODUCT_INTEL_500SERIES_HDA 0x43c8 /* 500 Series HD Audio */
+#define PCI_PRODUCT_INTEL_500SERIES_HDA_2 0xf0c8 /* 500 Series HD Audio */
#define PCI_PRODUCT_INTEL_500SERIES_THC_0 0x43d0 /* 500 Series THC */
#define PCI_PRODUCT_INTEL_500SERIES_THC_1 0x43d1 /* 500 Series THC */
#define PCI_PRODUCT_INTEL_500SERIES_AHCI_1 0x43d2 /* 500 Series AHCI */
Index: sys/dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1959
diff -u -p -u -p -r1.1959 pcidevs_data.h
--- sys/dev/pci/pcidevs_data.h 19 May 2021 05:21:24 - 1.1959
+++ sys/dev/pci/pcidevs_data.h 1 Jun 2021 01:20:43 -
@@ -18912,6 +18912,10 @@ static const struct pci_known_product pc
"500 Series HD Audio",
},
{
+ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_HDA_2,
+ "500 Series HD Audio",
+ },
+ {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_THC_0,
"500 Series THC",
},
Re: Document missing pledge promises
Regarding the vmm chunk -- as I said in my other reply, these
explanations are too precise. They risk becoming outdated as things
change. Furthermore, some of those ioctl may work in one way, but not
another way. Which would be too complicated to describe also. I urge
simple messaging:
.It Va vmm
Operations required by
.Xr vmd 8 .
It is accurate. If someone later wanted to use those operations, they
would figure it out by reading kernel and vmd source.
Josh Rickmar wrote:
> Here's my take at documenting the missing pledge promises in pledge.2
> and placing them in a reasonable order with the others. Each of these
> just enabled various ioctl or sysctl interfaces.
>
> I'm unhappy with the explanation for drm, but don't know how to
> explain the purpose of these ioctls, and could not find any man page
> to .Xr which documents these ioctl commands.
>
> diff db8264de5e686d467fdfaede154dd2a2b3b1dc3d /usr/src
> blob - 5794003962d7bc22bb4bb10471ed6f3381383cdf
> file + lib/libc/sys/pledge.2
> --- lib/libc/sys/pledge.2
> +++ lib/libc/sys/pledge.2
> @@ -498,6 +498,24 @@ programs like
> .Xr top 1
> and
> .Xr vmstat 8 .
> +.It Va vmm
> +Allows a subset of
> +.Xr ioctl 2
> +operations on the
> +.Xr vmm 4
> +device:
> +.Pp
> +.Dv VMM_IOC_CREATE ,
> +.Dv VMM_IOC_RUN ,
> +.Dv VMM_IOC_INFO ,
> +.Dv VMM_IOC_TERM ,
> +.Dv VMM_IOC_RESETCPU ,
> +.Dv VMM_IOC_INTR ,
> +.Dv VMM_IOC_READREGS ,
> +.Dv VMM_IOC_WRITEREGS ,
> +.Dv VMM_IOC_READVMPARAMS ,
> +.Dv VMM_IOC_WRITEVMPARAMS ,
> +.Dv VMM_IOC_MPROTECT_EPT
> .It Va id
> Allows the following system calls which can change the rights of a
> process:
> @@ -579,12 +597,27 @@ devices:
> .Dv VIDIOC_STREAMON ,
> .Dv VIDIOC_TRY_FMT ,
> .Dv VIDIOC_REQBUFS
> +.It Va drm
> +Allows a subset of
> +.Xr ioctl 2
> +operations on
> +.Xr drm 4
> +devices.
> .It Va bpf
> Allow
> .Dv BIOCGSTATS
> operation for statistics collection from a
> .Xr bpf 4
> device.
> +.It Va disklabel
> +Allow enough
> +.Xr sysctl 2
> +interfaces to allow inspection of
> +.Xr disklabel 5
> +partitions by programs like
> +.Xr disklabel 8
> +and
> +.Xr fdisk 8 .
> .It Va unveil
> Allow
> .Xr unveil 2
> blob - a8e23adf2a48afcb82c4118a45b76ad3060c1069
> file + sys/sys/pledge.h
> --- sys/sys/pledge.h
> +++ sys/sys/pledge.h
> @@ -100,18 +100,18 @@ static const struct {
> { PLEDGE_SETTIME, "settime" },
> { PLEDGE_PS,"ps" },
> { PLEDGE_VMINFO,"vminfo" },
> + { PLEDGE_VMM, "vmm" },
> { PLEDGE_ID,"id" },
> { PLEDGE_PF,"pf" },
> { PLEDGE_ROUTE, "route" },
> { PLEDGE_WROUTE,"wroute" },
> { PLEDGE_AUDIO, "audio" },
> { PLEDGE_VIDEO, "video" },
> + { PLEDGE_DRM, "drm" },
> { PLEDGE_BPF, "bpf" },
> + { PLEDGE_DISKLABEL, "disklabel" },
> { PLEDGE_UNVEIL,"unveil" },
> { PLEDGE_ERROR, "error" },
> - { PLEDGE_DISKLABEL, "disklabel" },
> - { PLEDGE_DRM, "drm" },
> - { PLEDGE_VMM, "vmm" },
> { 0, NULL },
> };
> #endif
>
Re: Document missing pledge promises
Theo de Raadt writes: > Regarding the vmm chunk -- as I said in my other reply, these > explanations are too precise. They risk becoming outdated as things > change. Furthermore, some of those ioctl may work in one way, but not > another way. Which would be too complicated to describe also. I urge > simple messaging: > > .It Va vmm > Operations required by > .Xr vmd 8 . > > It is accurate. If someone later wanted to use those operations, they > would figure it out by reading kernel and vmd source. I agree simpler is better. The actual ioctls are documented in vmm.4 and this is currently an all-or-nothing thing. You either get to perform all operations on the vmm(4) device or none. -dv
Re: pcidevs + azalia: patch for new intel audio
On Fri, Jun 11, 2021 at 10:03:07AM -0400, Ashton Fagg wrote:
> Friendly ping.
>
> Ashton Fagg writes:
>
> > My new Intel Z590-based machine seems to have some different kind of
> > Intel audio device onboard.
> >
> > I couldn't find very much online about it (all the usual pci id
> > databases don't seem to have it yet). The only really useful thing I
> > found was this:
> >
> > https://github.com/torvalds/linux/commit/f84d3a1ec375e46a55cc3ba85c04272b24bd3921#diff-bfe681fff464a07274400d493ba696cc6e10649a993ae7c1cfc1c29a106feda0
> >
> > This doesn't give much info but seems to indicate that it's a variant of
> > some existing chip.
I can't find 0xf0c8 in the datasheets either.
I've committed this but moved the added line in pcidevs to maintain
ordering by device id. Thanks for the patch.
> >
> > I gave this the not very descriptive name of
> > "PCI_PRODUCT_INTEL_500SERIES_HDA_2", since that's about all I could come
> > up with, since I'm assuming it's a variant of
> > "PCI_PRODUCT_INTEL_500SERIES_HDA".
> >
> > Patch which defines device in pcidevs and tells azalia how to
> > configure it is attached. Playback was the only thing I could readily
> > test and that's working - so my itch here has been scratched.
> >
> > I've also attached a dmesg output and a pcidump output (dmesg has also
> > been sent to dmesg@).
> >
> > Feedback greatly welcomed.
> >
> > Before:
> >
> > azalia0 at pci0 dev 31 function 3 vendor "Intel", unknown product 0xf0c8
> > rev 0x11: msi
> > azalia0: codecs: Realtek/0x0897, 0x/0x, using Realtek/0x0897
> > audio0 at azalia0
> >
> > After:
> >
> > azalia0 at pci0 dev 31 function 3 "Intel 500 Series HD Audio" rev 0x11: msi
> > azalia0: codecs: Realtek/0x0897, 0x/0x, using Realtek/0x0897
> > audio0 at azalia0
>
> Index: sys/dev/pci/azalia.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> retrieving revision 1.262
> diff -u -p -u -p -r1.262 azalia.c
> --- sys/dev/pci/azalia.c 30 May 2021 02:54:36 - 1.262
> +++ sys/dev/pci/azalia.c 1 Jun 2021 01:20:42 -
> @@ -470,6 +470,7 @@ azalia_configure_pci(azalia_t *az)
> case PCI_PRODUCT_INTEL_400SERIES_LP_HDA:
> case PCI_PRODUCT_INTEL_495SERIES_LP_HDA:
> case PCI_PRODUCT_INTEL_500SERIES_HDA:
> + case PCI_PRODUCT_INTEL_500SERIES_HDA_2:
> case PCI_PRODUCT_INTEL_500SERIES_LP_HDA:
> case PCI_PRODUCT_INTEL_C600_HDA:
> case PCI_PRODUCT_INTEL_C610_HDA_1:
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1970
> diff -u -p -u -p -r1.1970 pcidevs
> --- sys/dev/pci/pcidevs 19 May 2021 05:20:48 - 1.1970
> +++ sys/dev/pci/pcidevs 1 Jun 2021 01:20:42 -
> @@ -5371,6 +5371,7 @@ product INTEL 500SERIES_PCIE_22 0x43c5 5
> product INTEL 500SERIES_PCIE_23 0x43c6 500 Series PCIE
> product INTEL 500SERIES_PCIE_24 0x43c7 500 Series PCIE
> product INTEL 500SERIES_HDA 0x43c8 500 Series HD Audio
> +product INTEL 500SERIES_HDA_20xf0c8 500 Series HD Audio
> product INTEL 500SERIES_THC_00x43d0 500 Series THC
> product INTEL 500SERIES_THC_10x43d1 500 Series THC
> product INTEL 500SERIES_AHCI_1 0x43d2 500 Series AHCI
> Index: sys/dev/pci/pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1964
> diff -u -p -u -p -r1.1964 pcidevs.h
> --- sys/dev/pci/pcidevs.h 19 May 2021 05:21:24 - 1.1964
> +++ sys/dev/pci/pcidevs.h 1 Jun 2021 01:20:42 -
> @@ -5376,6 +5376,7 @@
> #define PCI_PRODUCT_INTEL_500SERIES_PCIE_23 0x43c6 /* 500
> Series PCIE */
> #define PCI_PRODUCT_INTEL_500SERIES_PCIE_24 0x43c7 /* 500
> Series PCIE */
> #define PCI_PRODUCT_INTEL_500SERIES_HDA 0x43c8 /* 500 Series
> HD Audio */
> +#define PCI_PRODUCT_INTEL_500SERIES_HDA_2 0xf0c8 /* 500
> Series HD Audio */
> #define PCI_PRODUCT_INTEL_500SERIES_THC_0 0x43d0 /* 500
> Series THC */
> #define PCI_PRODUCT_INTEL_500SERIES_THC_1 0x43d1 /* 500
> Series THC */
> #define PCI_PRODUCT_INTEL_500SERIES_AHCI_1 0x43d2 /* 500
> Series AHCI */
> Index: sys/dev/pci/pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1959
> diff -u -p -u -p -r1.1959 pcidevs_data.h
> --- sys/dev/pci/pcidevs_data.h19 May 2021 05:21:24 - 1.1959
> +++ sys/dev/pci/pcidevs_data.h1 Jun 2021 01:20:43 -
> @@ -18912,6 +18912,10 @@ static const struct pci_known_product pc
> "500 Series HD Audio",
> },
> {
> + PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_HDA_2,
> + "500 Series HD Audio",
> +
Re: snmpd(8) Better traphandler flow
any takers?
On Fri, 2021-06-04 at 22:11 +0200, Martijn van Duren wrote:
> ping
>
> On Fri, 2021-05-28 at 08:19 +0200, Martijn van Duren wrote:
> > As the original comment said:
> > /*
> > * This should probably go into parsevarbinds, but that's for a
> > * next refactor
> > */
> >
> > This moves the pdu parsing of traps into parsevarbinds.
> > Added bonus, we can now see the packets in debugging mode:
> > startup
> > snmpe: listening on udp 127.0.0.1:162
> > ktable_new: new ktable for rtableid 0
> > snmpe_parse: 127.0.0.1:162: SNMPv2 'public' pdutype SNMPv2-Trap request
> > 1329591927
> > snmpe_parse: 127.0.0.1:162: SNMPv1 'public' pdutype Trap request 0
> >
> > OK?
> >
> > martijn@
> >
> > Index: snmpd.h
> > ===
> > RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
> > retrieving revision 1.95
> > diff -u -p -r1.95 snmpd.h
> > --- snmpd.h 20 May 2021 08:53:12 - 1.95
> > +++ snmpd.h 28 May 2021 06:17:16 -
> > @@ -776,6 +776,7 @@ int proc_flush_imsg(struct privsep *, e
> >
> > /* traphandler.c */
> > int traphandler_parse(struct snmp_message *);
> > +int traphandler_v1translate(struct snmp_message *, int);
> > int traphandler_priv_recvmsg(struct privsep_proc *, struct imsg *);
> > void trapcmd_free(struct trapcmd *);
> > int trapcmd_add(struct trapcmd *);
> > Index: snmpe.c
> > ===
> > RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
> > retrieving revision 1.71
> > diff -u -p -r1.71 snmpe.c
> > --- snmpe.c 20 May 2021 08:53:12 - 1.71
> > +++ snmpe.c 28 May 2021 06:17:16 -
> > @@ -368,6 +368,10 @@ snmpe_parse(struct snmp_message *msg)
> > msg->sm_errstr = "trapv1 request on !SNMPv1
> > message";
> > goto parsefail;
> > }
> > + /* Internally we work with SNMPv2-Traps */
> > + if (traphandler_v1translate(msg, 0) == -1)
> > + goto fail;
> > + a = msg->sm_pdu->be_sub;
> > case SNMP_C_TRAPV2:
> > if (msg->sm_pdutype == SNMP_C_TRAPV2 &&
> > !(msg->sm_version == SNMP_V2 ||
> > @@ -390,16 +394,9 @@ snmpe_parse(struct snmp_message *msg)
> > goto fail;
> > }
> > stats->snmp_intraps++;
> > - /*
> > - * This should probably go into parsevarbinds, but that's
> > for a
> > - * next refactor
> > - */
> > - if (traphandler_parse(msg) == -1)
> > - goto fail;
> > - /* Shortcircuit */
> > - return 0;
> > + break;
> > default:
> > - msg->sm_errstr = "invalid context";
> > + msg->sm_errstr = "invalid pdutype";
> > goto parsefail;
> > }
> >
> > @@ -450,7 +447,14 @@ snmpe_parsevarbinds(struct snmp_message
> > struct ber_element *pvarbind = NULL, *end;
> > char buf[BUFSIZ];
> > struct ber_oid o;
> > - int i;
> > + int i = 1;
> > +
> > + if (msg->sm_pdutype == SNMP_C_TRAP ||
> > + msg->sm_pdutype == SNMP_C_TRAPV2) {
> > + if (traphandler_parse(msg) == -1)
> > + goto varfail;
> > + return 0;
> > + }
> >
> > msg->sm_errstr = "invalid varbind element";
> >
> > @@ -458,7 +462,7 @@ snmpe_parsevarbinds(struct snmp_message
> > msg->sm_varbindresp = NULL;
> > end = NULL;
> >
> > - for (i = 1; varbind != NULL && i < SNMPD_MAXVARBIND;
> > + for (; varbind != NULL && i < SNMPD_MAXVARBIND;
> > varbind = varbind->be_next, i++) {
> > if (ober_scanf_elements(varbind, "{oeS$}", , ) ==
> > -1) {
> > stats->snmp_inasnparseerrs++;
> > @@ -543,7 +547,7 @@ snmpe_parsevarbinds(struct snmp_message
> > msg->sm_errorindex = 0;
> >
> > return 0;
> > - varfail:
> > +varfail:
> > log_debug("%s: %s:%hd: %s, error index %d", __func__,
> > msg->sm_host, msg->sm_port, msg->sm_errstr, i);
> > if (msg->sm_error == 0)
> > @@ -790,18 +794,18 @@ snmpe_recvmsg(int fd, short sig, void *a
> > void
> > snmpe_dispatchmsg(struct snmp_message *msg)
> > {
> > - if (msg->sm_pdutype == SNMP_C_TRAP ||
> > - msg->sm_pdutype == SNMP_C_TRAPV2) {
> > - snmp_msgfree(msg);
> > - return;
> > - }
> > /* dispatched to subagent */
> > /* XXX Do proper error handling */
> > (void) snmpe_parsevarbinds(msg);
> >
> > - /* respond directly */
> > - msg->sm_pdutype = SNMP_C_GETRESP;
> > - snmpe_response(msg);
> > + if (msg->sm_pdutype == SNMP_C_TRAP ||
> >
Re: Document missing pledge promises
Dave Voutila wrote: > Theo de Raadt writes: > > > Regarding the vmm chunk -- as I said in my other reply, these > > explanations are too precise. They risk becoming outdated as things > > change. Furthermore, some of those ioctl may work in one way, but not > > another way. Which would be too complicated to describe also. I urge > > simple messaging: > > > > .It Va vmm > > Operations required by > > .Xr vmd 8 . > > > > It is accurate. If someone later wanted to use those operations, they > > would figure it out by reading kernel and vmd source. > > I agree simpler is better. The actual ioctls are documented in vmm.4 and > this is currently an all-or-nothing thing. You either get to perform all > operations on the vmm(4) device or none. What you just said is the truth. But once you put it in a manual page, in the future the code may change, and some ioctl might be exposed without "vmm". it is better to be vague.
Re: Document missing pledge promises
On Fri, Jun 11, 2021 at 09:16:46AM -0600, Theo de Raadt wrote: > Dave Voutila wrote: > > > Theo de Raadt writes: > > > > > Regarding the vmm chunk -- as I said in my other reply, these > > > explanations are too precise. They risk becoming outdated as things > > > change. Furthermore, some of those ioctl may work in one way, but not > > > another way. Which would be too complicated to describe also. I urge > > > simple messaging: > > > > > > .It Va vmm > > > Operations required by > > > .Xr vmd 8 . > > > > > > It is accurate. If someone later wanted to use those operations, they > > > would figure it out by reading kernel and vmd source. > > > > I agree simpler is better. The actual ioctls are documented in vmm.4 and > > this is currently an all-or-nothing thing. You either get to perform all > > operations on the vmm(4) device or none. > > What you just said is the truth. But once you put it in a manual page, > in the future the code may change, and some ioctl might be exposed > without "vmm". it is better to be vague. > Agreed, simpler is better in the pledge docs.
fix isascii(3) manpage
All the is*() ctype.h functions take an int as argument, but valid values are only EOF, and the range of values of `unsigned char'. All, but one: the XPG4 isascii(), which has no such restriction. Quoting https://pubs.opengroup.org/onlinepubs/9699919799/ : ``The isascii() function is defined on all integer values.'' Hence the following diff. Index: isascii.3 === RCS file: /OpenBSD/src/lib/libc/gen/isascii.3,v retrieving revision 1.13 diff -u -p -r1.13 isascii.3 --- isascii.3 17 Jul 2013 05:42:11 - 1.13 +++ isascii.3 11 Jun 2021 09:54:13 - @@ -77,11 +77,3 @@ The .Fn isascii function first appeared in .At v7 . -.Sh CAVEATS -The argument to -.Fn isascii -must be -.Dv EOF -or representable as an -.Li unsigned char ; -otherwise, the result is undefined.
Re: hvn(4): don't input mbufs if interface is not running
On 12/05/2021 15:15, Patrick Wildt wrote: > Hi, > > when hvn(4) attaches it sends commands and waits for replies to come > back in, hence the interrupt function is being polled. Unfortunately > it seems that the 'receive pipe' has both command completion and data > packets. As it turns out, while hvn(4) is just setting up the pipes, > it can already receive packets, which I have seen happening on Hyper-V. > > This essentially means that if_input() is being called *before* the > card is set up (or UP). This seems wrong. Apparently on drivers like > em(4) we only read packets if IFF_RUNNING is set. I think in the case > of hvn(4), we should drop packets unless IFF_RUNNING is set. > > Opinions? > Hi Patrick, You're right that hvn needs to have the receiving path setup to exchange commands with the hypervisor. This diff LGTM and should be committed if it wasn't. Cheers, Mike > Patrick > > diff --git a/sys/dev/pv/if_hvn.c b/sys/dev/pv/if_hvn.c > index f12e2f935ca..4306f717baf 100644 > --- a/sys/dev/pv/if_hvn.c > +++ b/sys/dev/pv/if_hvn.c > @@ -1470,7 +1470,10 @@ hvn_rndis_input(struct hvn_softc *sc, uint64_t tid, > void *arg) > } > hvn_nvs_ack(sc, tid); > > - if_input(ifp, ); > + if (ifp->if_flags & IFF_RUNNING) > + if_input(ifp, ); > + else > + ml_purge(); > } > > static inline struct mbuf * >
sysupgrade reset option
I am likely going to simply track file changes and revert them for a reset to factory defaults facilitation, rather than maintaining a build system for a custom bsd.rd. One assumption that I have made is that newfs and dd altroot to root and reboot in rc.securelevel would fail or be problematic? Is there any chance that OpenBSD would be interested in patches to add an unattended install option similar to how an auto_upgrade.conf is detected but where an /auto_install.conf is detected? I believe that the current autoinstall procedure requires interactivity (A) key or netboot.
