Re: Fix ipsp_spd_lookup() for transport mode

I don't know much about l2tp, pipex or npppd. So I cannot say if the new logic is correct. But I guess you have tested that. The tdb mutex and ref counting looks correct. > + struct tdb *tdb, *tdblocal = NULL; The variable names tdb and tdbp are used very inconsistently within IPsec.

Re: com(4) at acpi(4) on amd64

> Date: Fri, 10 Dec 2021 07:56:44 +0100 > From: Anton Lindqvist > > On Tue, Dec 07, 2021 at 01:08:45PM +0100, Mark Kettenis wrote: > > > Date: Tue, 7 Dec 2021 11:30:48 +0100 > > > From: Anton Lindqvist > > > > > > On Mon, Dec 06, 2021 at 10:25:34PM +0100, Mark Kettenis wrote: > > > > > Date:

cat(1): drop "rpath" promise in no-file case

We don't need the "rpath" promise if there are no file arguments. We drop this promise in other utilities that default to stdin in the no-file case. If we consolidate raw_args() and cook_args() into a single function, cat_file(), we can drop the "rpath" promise in main(), in a single place in

Re: cat(1): always use a 64K buffer

I think Todd is right, and this doesn't need to change. Todd C. Miller wrote: > On Sun, 12 Dec 2021 19:15:51 -0600, Scott Cheloha wrote: > > > cat(1) sizes its I/O buffer according to the st_blksize of the first > > file it processes. We don't do this very often in the tree. I'm not > > sure

Re: cat(1): always use a 64K buffer

On Sun, 12 Dec 2021 19:15:51 -0600, Scott Cheloha wrote: > cat(1) sizes its I/O buffer according to the st_blksize of the first > file it processes. We don't do this very often in the tree. I'm not > sure if we should trust st_blksize. It sizes the buffer based on st_blksize of stdout, not the

Re: unveil(2) usbhidaction(1)

Hi, and of course this was also missing unveil(NULL, NULL). ok now? this one opens the default table file "/usr/share/misc/usb_hid_usages" through hid_start(3) from libusbhid, then `dev' (will have the fd used on the ioctls) and finally `conf' which is the file with the actions to be monitored.

Re: unveil(2) usbhidctl(1)

Hi, of course it needs that, sorry. ok now? a little bit more of info here, hid_start(3) opens `table' through libusbhid, then usbhidctl(1) itself opens `dev', after that it's just performing ioctls on the fd left opened by the latter in this case `hidfd'. Index: usbhid.c

Re: msk(4) not working with trunk(4) (Marvell Yukon 88E8042)

Friendly reminder. I really would like to proceed in debugging this issue with a more suitable report, but I definitely need directions... Copying tech@, hoping to attract the attention of some developers. All the best On 2021-12-07 19:39, Alessandro De Laurenzis wrote: Greetings, I

iked: cleanup libcrypto *_free calls

Hey, tb@ noticed that we do a lot of redundant explicit NULL checks before calling libcrypto *_free() functions. A few of the free() calls can also be avoided by using X509_get0_pubkey() instead of X509_get_pubkey(). ok? Index: ca.c

Re: ipsec ipo tdb mutex

On 12.12.2021. 16:37, Hrvoje Popovski wrote: > On 11.12.2021. 20:03, Alexander Bluhm wrote: >> On Sat, Dec 11, 2021 at 12:53:35AM +0100, Alexander Bluhm wrote: >>> To cache lookups, the policy ipo is linked to its SA tdb. There >>> is a list of SAs that belong to a policy. To make it MP safe we

dhcpleased(8): keep xid

Only generate a new xid on state change. When we first request a lease (INIT or REBOOTING state) we run with very short timeouts. If the dhcp server is slow to respond we already have a new xid and ignore the server's response. This goes on until we increase the timeout high enough. If we just

Re: dhcpleased(8): use struct assignment

On Mon, Dec 13, 2021 at 11:25:02AM +0100, Florian Obser wrote: > Replace struct member assignment with struct assignment to make the code > more compact. No binary change (on amd64). > > OK? Or is there a reason not to do this? Looks good to me and I also see no reason why this should not be

Re: dhcpleased(8): network byte order for xid

On Mon, Dec 13, 2021 at 11:27:20AM +0100, Florian Obser wrote: > Treat xid as a uint32_t in network byte order on the wire. > > Internally this doesn't matter since we only care about equality. > This makes logging output comparable to tcpdump(8). > > Pointed out by joel@ > > OK? OK claudio@

dhcpleased(8): network byte order for xid

Treat xid as a uint32_t in network byte order on the wire. Internally this doesn't matter since we only care about equality. This makes logging output comparable to tcpdump(8). Pointed out by joel@ OK? diff --git engine.c engine.c index 60f81d6f3c8..4fbdf2f16ef 100644 --- engine.c +++ engine.c

dhcpleased(8): use struct assignment

Replace struct member assignment with struct assignment to make the code more compact. No binary change (on amd64). OK? Or is there a reason not to do this? diff --git dhcpleased.c dhcpleased.c index c8cc8e14d04..00bbffc1699 100644 --- dhcpleased.c +++ dhcpleased.c @@ -785,16 +785,14 @@

Re: cat(1): always use a 64K buffer

On Mon, Dec 13, 2021 at 02:52:50AM -0600, Scott Cheloha wrote: > > On Dec 13, 2021, at 01:13, Otto Moerbeek wrote: > > > > On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote: > > > >> cat(1) sizes its I/O buffer according to the st_blksize of the first > >> file it processes. We

Re: DNS in acme-client

Change of plans... I went throught the code and it seems to handle multiple addresses correct through all the calls / processes. (It is beyond me why it passes IP addresses as strings around though.) OK florian On 2021-12-13 01:56 +01, Jeremie Courreges-Anglas wrote: > On Sun, Dec 12 2021,

Re: cat(1): always use a 64K buffer

> On Dec 13, 2021, at 01:13, Otto Moerbeek wrote: > > On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote: > >> cat(1) sizes its I/O buffer according to the st_blksize of the first >> file it processes. We don't do this very often in the tree. I'm not >> sure if we should trust