Re: vmt(4): use shared netlock to protect ifnet data within vmt_tclo_broadcastip()

2023-09-24 Thread YASUOKA Masahiko
On Sat, 23 Sep 2023 15:38:40 +0300 Vitaliy Makkoveev wrote: > This makes ifnet protection consistent. Execute vmt_tclo_tick() timeout > handler in process context to allow context switch within > vmt_tclo_broadcastip(). ok yasuoka > Index: sys/dev/pv/vmt.c > =

fix a wireguard mbuf leak

2023-09-21 Thread YASUOKA Masahiko
A leak may happens when wgpeer is deleted. ok? The state queue should be freeed when wg_peer is destroyed. diff from IIJ. Index: sys/net/if_wg.c === RCS file: /disk/cvs/openbsd/src/sys/net/if_wg.c,v retrieving revision 1.29 diff -u

Re: diff: trigger acpiac_refresh when acpibat notification

2023-09-13 Thread YASUOKA Masahiko
ping. I think we have no reason not having this. Alternatively acpiac_notify_triggered can be deleted and doing the triggering unconditionally is also good because it's simpler. comments? ok? On Thu, 17 Aug 2023 16:12:07 +0900 (JST) YASUOKA Masahiko wrote: > Hi, > > Update the

diff: relayd generate an output rule for "route to"

2023-09-12 Thread YASUOKA Masahiko
Hi, After 6.9 packets passed by "route-to" started to be evaluated when output. As the result, states are created for output direction, because it is not considered about "direct server return", has some problems (eg. the state is deleted because the state tracking is failed.) relayd(8) creates

Re: diff: trigger acpiac_refresh when acpibat notification

2023-08-18 Thread YASUOKA Masahiko
On Thu, 17 Aug 2023 10:07:27 -0500 joshua stein wrote: > On Thu, 17 Aug 2023 at 16:12:07 +0900, YASUOKA Masahiko wrote: >> Hi, >> >> Update the AC status when the battery notification is happened. >> Because the AC status notification doesn't happen on some machin

Re: diff: trigger acpiac_refresh when acpibat notification

2023-08-17 Thread YASUOKA Masahiko
Let me clarify some. On Thu, 17 Aug 2023 16:12:07 +0900 (JST) YASUOKA Masahiko wrote: > Update the AC status when the battery notification is happened. > Because the AC status notification doesn't happen on some machines. At that time (plugging or unpluggin the AC), a battery n

Re: diff: trigger acpiac_refresh when acpibat notification

2023-08-17 Thread YASUOKA Masahiko
pm」を使うことができます。 > > Battery level (percent) checking/バッテリーのレベル(パーセント)を確認するため:apm -l > Estimated battery duration (minutes)/バッテリーが持つ予定の時間まで(分)を確認するため:apm -m > > On 2023年08月17日 16:12, YASUOKA Masahiko wrote: >> Hi, >> >> Update the AC status when the battery notifi

diff: trigger acpiac_refresh when acpibat notification

2023-08-17 Thread YASUOKA Masahiko
Hi, Update the AC status when the battery notification is happened. Because the AC status notification doesn't happen on some machines. My vaio actually has this problem. Also Linux is doing the same thing https://github.com/torvalds/linux/blob/v6.4/drivers/acpi/ac.c#L165-L183 ok? comments? In

attach azalia(4) for "Intel 700 Series HD Audio"

2023-07-30 Thread YASUOKA Masahiko
Hello, New vaio has an audio device which is not configured. "Intel 700 Series HD Audio" rev 0x01 at pci0 dev 31 function 3 not configured 0:31:3: Intel unknown 0x: Vendor ID: 8086, Product ID: 51ca 0x0004: Command: 0006, Status: 0010 0x0008: Class: 04 Multimedia,

assign wsdisplay0 to the glass console

2023-07-19 Thread YASUOKA Masahiko
Hi, I noticed that the keyboard doesn't work for RAMDISK kernel on HP DL20 Gen10. The kernel assigns wsdisplay0 for VGA and wsdisplay1 for efifb. But actually the glass console is efieb but it doesn't have any keyboard assigned because the keyboard is assigned to wsdisplay0. GENERIC kernel does

make mbstat smaller (was Re: make mstat smaller)

2023-07-09 Thread YASUOKA Masahiko
On Sat, 08 Jul 2023 21:58:30 +0300 (EEST) YASUOKA Masahiko wrote: > The diff makes the mbstat be the same size which is actually used. > Also revert the previous that the mbstat is located on the stack. The userland program also needed to be changed. ok? Index: sys/kern/kern_sy

make mstat smaller

2023-07-08 Thread YASUOKA Masahiko
Hi, The diff makes the mbstat be the same size which is actually used. Also revert the previous that the mbstat is located on the stack. ok? Index: sys/kern/kern_sysctl.c === RCS file: /cvs/src/sys/kern/kern_sysctl.c,v retrieving re

Re: acpi: move acpiioctl to x86

2023-07-08 Thread YASUOKA Masahiko
On Fri, 7 Jul 2023 11:56:42 +0200 Tobias Heider wrote: > On Wed, Jul 05, 2023 at 04:53:33PM +0200, Tobias Heider wrote: >> I am planning to restructure the APM/sleep APIs to make it easier to suspend >> from more places like as a suspend keyboard shortcut. >> >> The acpiioctl handler is x86 speci

Use u_long for struct mstat

2023-07-07 Thread YASUOKA Masahiko
Hi, I'd like to expand the counters in struct mbstat from u_short to u_long. When I was debugging a mbuf leak, I saw the result of "netstat -m" --- 28647 mbufs in use: 28551 mbufs allocated to data 4 mbufs allocated to packet headers 92 mbufs allocated to socket names and

Re: tcp timer wrap around, use 64 bit

2023-07-07 Thread YASUOKA Masahiko
Hi, This netstat diff is already needed to avoid compiler warnings since it uses struct tcpcb directly. ok? Index: usr.bin/netstat/inet.c === RCS file: /cvs/src/usr.bin/netstat/inet.c,v retrieving revision 1.177 diff -u -p -r1.177 i

Re: tcp timer wrap around, use 64 bit

2023-07-07 Thread YASUOKA Masahiko
On Fri, 7 Jul 2023 10:43:21 +0200 Claudio Jeker wrote: >> @@ -411,7 +412,7 @@ tcp_stats_display(unsigned long long tot >> P(tcpi, rcv_up, "%u") >> P(tcpi, rcv_wscale, "%hhu") >> P(tcpi, rfbuf_cnt, "%u") >> -P(tcpi,

Re: tcp timer wrap around, use 64 bit

2023-07-07 Thread YASUOKA Masahiko
Hi, Does using 64 bit for timer in tcpcb require this? ok? Index: sys/netinet/tcp.h === RCS file: /cvs/src/sys/netinet/tcp.h,v retrieving revision 1.24 diff -u -p -r1.24 tcp.h --- sys/netinet/tcp.h 19 May 2023 01:04:39 -

Re: tcp timer wrap around, use 64 bit

2023-07-06 Thread YASUOKA Masahiko
On Tue, 4 Jul 2023 12:14:47 +0300 Alexander Bluhm wrote: > After changing tcp now tick to milliseconds, it will wrap around > after 49 days of uptime. That may be a problem in some places of > our stack. Better use a 64 bit counter. I agree since we sometimes hit a problem from where we could n

diff asr_run.3

2023-05-31 Thread YASUOKA Masahiko
Hi, asr_run.3 is explaining that ar_rrsetinfo must be freed only for the blocking function, but I think it must be freed regardless of the function blocking type. ok? Index: lib/libc/asr/asr_run.3 === RCS file: /cvs/src/lib/libc/asr

Re: atactl(8): 'readattr' subcommand quits silently.

2023-04-26 Thread YASUOKA Masahiko
Hello, On Wed, 26 Apr 2023 16:32:28 +0900 Yuichiro NAITO wrote: > These 2 revisions of 'attr_val' and 'attr_thr' are different on this > disk. > The comment says that it's wrong vendor implementation but I can see > 'smartctl' shows the attributes as follows. NetBSD's atactl doesn't > see these 2

diff: www/faq/pf/carp.html

2023-04-17 Thread YASUOKA Masahiko
Hi, carpdemote is increased/decreased when the link state of the carpdev is down/up. This behavior is not related to net.inet.carp.preempt since "carpdemote" is introduced. But the faq still says the "net.inet.carp.preempt" variable enables it. I'd like to commit the diff. ok or any comment i

Re: npppd(8): remove "pipex" option

2023-02-01 Thread YASUOKA Masahiko
Hi, On Wed, 1 Feb 2023 21:32:29 +0300 Vitaliy Makkoveev wrote: > On Wed, Feb 01, 2023 at 09:00:13PM +0900, YASUOKA Masahiko wrote: >> ... >> >> But I think we should keep the part since it is needed when adding a >> tunneling protocol which is not supported by pi

Re: npppd(8): remove "pipex" option

2023-02-01 Thread YASUOKA Masahiko
I'm sorry for sending 2 mails. First one was a draft. Please read second one.

Re: npppd(8): remove "pipex" option

2023-02-01 Thread YASUOKA Masahiko
Hi On Tue, 31 Jan 2023 11:30:43 +0300 Vitaliy Makkoveev wrote: > On Tue, Jan 31, 2023 at 01:40:19PM +0900, YASUOKA Masahiko wrote: >> Hi, >> >> On Sun, 29 Jan 2023 14:35:05 +0300 >> Vitaliy Makkoveev wrote: >> > While switchind pppx(4) and pppac(4) from s

Re: npppd(8): remove "pipex" option

2023-02-01 Thread YASUOKA Masahiko
On Tue, 31 Jan 2023 11:30:43 +0300 Vitaliy Makkoveev wrote: > On Tue, Jan 31, 2023 at 01:40:19PM +0900, YASUOKA Masahiko wrote: >> Hi, >> >> On Sun, 29 Jan 2023 14:35:05 +0300 >> Vitaliy Makkoveev wrote: >> > While switchind pppx(4) and pppac(4) from selwake

Re: npppd(8): remove "pipex" option

2023-01-30 Thread YASUOKA Masahiko
Hi, On Sun, 29 Jan 2023 14:35:05 +0300 Vitaliy Makkoveev wrote: > While switchind pppx(4) and pppac(4) from selwakeup() to KNOTE(9), I > found npppd(8) doesn't create pppx interface with "pipex no" in > npppd.conf, but successfully connects the client. So packets don't flow. > However, the pppac(

Re: efi(4): Support for EFI variables and tables in the kernel

2023-01-07 Thread YASUOKA Masahiko
Hi, On Wed, 04 Jan 2023 21:52:35 +0100 Mark Kettenis wrote: > Dear Sergii and others, > > I've committed the change that passes the ESRT from the bootloader to > the kernel. So now it is time to add the interfaces to the kernel to > read it. And add the interfaces to manipulate EFI variables.

Re: hostctl: Change from fixed length to variable length

2023-01-05 Thread YASUOKA Masahiko
ok yasuoka On Fri, 06 Jan 2023 15:14:05 +0900 (JST) Masato Asou wrote: > I have updated my patch. > > From: YASUOKA Masahiko > Date: Tue, 27 Dec 2022 11:58:34 +0900 (JST) > >> After diff, it doesn't use PAGE_SIZE any more. And VMware software >> limi

Re: hostctl: Change from fixed length to variable length

2022-12-26 Thread YASUOKA Masahiko
Hi, Sorry for separating emails. On Tue, 27 Dec 2022 11:58:34 +0900 (JST) YASUOKA Masahiko wrote: >> @@ -1115,12 +1116,19 @@ xs_kvop(void *xsc, int op, char *key, char *value, >> size_t valuelen) >> } >> /* FALLTHROUGH */ >> case X

Re: hostctl: Change from fixed length to variable length

2022-12-26 Thread YASUOKA Masahiko
Hi, On Mon, 26 Dec 2022 13:37:45 +0900 (JST) Masato Asou wrote: > My new patch is not returned value length from ioctl() system call > when read the KEY's value. > > The hostctl command allocate 4k bytes memory for store the value. Then > read the value by ioctl() system call. If ioctl() returne

Re: vmt is not closed

2022-12-20 Thread YASUOKA Masahiko
Yes, my previous commit was wrong. Calling vm_rpc_close() was missing. Thank you for finding. ok yasuoka On Tue, 13 Dec 2022 19:26:05 +0900 (JST) Masato Asou wrote: > From: Masato Asou > Date: Tue, 13 Dec 2022 18:26:22 +0900 (JST) > > Delete #define VMT_DEBUG > ok? > -- > ASOU Masato > >> co

pvbus: pass M_ZERO properly

2022-12-07 Thread YASUOKA Masahiko
This is obvious. M_ZERO must be for 3rd argument. ok? Index: sys/dev/pv/pvbus.c === RCS file: /cvs/src/sys/dev/pv/pvbus.c,v retrieving revision 1.25 diff -u -p -r1.25 pvbus.c --- sys/dev/pv/pvbus.c 25 Aug 2022 17:38:16 - 1

Re: pppx(4): decrease netlock pressure in pppxioctl()

2022-11-19 Thread YASUOKA Masahiko
It doesn't seem to have a problem. Sorry for my delay. ok yasuoka On Wed, 9 Nov 2022 13:24:21 +0300 Vitaliy Makkoveev wrote: > ping... > > On Tue, Nov 01, 2022 at 03:16:02PM +0300, Vitaliy Makkoveev wrote: >> Push netlock down to pppx_add_session(). The 'pppx_if' structure has >> the `pxi_read

Re: hostctl: Change from fixed length to variable length

2022-11-18 Thread YASUOKA Masahiko
On Sat, 19 Nov 2022 14:41:18 +0900 (JST) YASUOKA Masahiko wrote: > On Wed, 12 Oct 2022 07:58:20 +0900 (JST) > YASUOKA Masahiko wrote: >> On Wed, 05 Oct 2022 13:37:35 +0900 (JST) >> Masato Asou wrote: >>> From: "Theo de Raadt" >>> Date: Tue, 04 Oct

Re: hostctl: Change from fixed length to variable length

2022-11-18 Thread YASUOKA Masahiko
On Wed, 12 Oct 2022 07:58:20 +0900 (JST) YASUOKA Masahiko wrote: > On Wed, 05 Oct 2022 13:37:35 +0900 (JST) > Masato Asou wrote: >> From: "Theo de Raadt" >> Date: Tue, 04 Oct 2022 21:58:13 -0600 >>> Userland may not ask the kernel to allocate such a huge obj

Re: hostctl: Change from fixed length to variable length

2022-10-11 Thread YASUOKA Masahiko
Hello, On Wed, 05 Oct 2022 13:37:35 +0900 (JST) Masato Asou wrote: > From: "Theo de Raadt" > Date: Tue, 04 Oct 2022 21:58:13 -0600 >> Userland may not ask the kernel to allocate such a huge object. The >> kernel address space is quite small. First off, huge allocations will >> fail. >> >> But

diff: fix panic in pf_state_export()

2022-09-20 Thread YASUOKA Masahiko
Hello, My colleague hit the following kernel panic when he is doing "psctl -ss" repeatedly by a script during a performance test. uvm_fault(0xfd811b869110, 0x10, 0, 1) -> e kernel: page fault trap, code=0 Stopped at pf_state_export+0x42: movq0x10(%rax),%rcx TIDPIDUI

Re: tcp timer mutex

2022-09-03 Thread YASUOKA Masahiko
ok yasuoka On Fri, 2 Sep 2022 14:44:29 +0200 Alexander Bluhm wrote: > + now = READ_ONCE(tcp_now); > + > /* >* Determine length of data that should be transmitted, >* and flags that will be used. > @@ -228,7 +231,7 @@ tcp_output(struct tcpcb *tp) >* to send, then

Re: divert-reply: keep pf state after pcb is dropped

2022-09-02 Thread YASUOKA Masahiko
Hi, On Fri, 2 Sep 2022 17:40:13 +0200 Alexander Bluhm wrote: > On Fri, Sep 02, 2022 at 03:04:34PM +0200, YASUOKA Masahiko wrote: >> The diff is to fix a problem in a complex setup. >> >> Normal setup of divert-reply for TCP connection: >> >>

divert-reply: keep pf state after pcb is dropped

2022-09-02 Thread YASUOKA Masahiko
Hi, The diff is to fix a problem in a complex setup. Normal setup of divert-reply for TCP connection: client --- relayd --- server - transparently forward TCP connections - divert-reply is configured the outbound connection to the server - so that the PF state is removed when the PCB is de

httpd: fix default request body size

2022-09-02 Thread YASUOKA Masahiko
Hello, For HTTP request body, if neither "Content-Encoding: chunked" nor "Content-Length" is specified, it should mean body length is 0. In RFC 9112 Section 6.3, 7.: | 7. If this is a request message and none of the above are true, then | the message body length is zero (no message body

Re: pipex syzkaller keylen

2022-08-30 Thread YASUOKA Masahiko
Hi, Tested. ok yasuoka On Tue, 30 Aug 2022 15:41:29 +0200 Alexander Bluhm wrote: > Hi, > > I looks like syzkaller has found a missing input validation in pipex. > > https://syzkaller.appspot.com/bug?id=c7ac769bd7ee15549b8a2be188bcee07d98a5357 > > As I have no pipex setup, can anyone test thi

Re: diff: b64decode(1) for long line

2022-08-30 Thread YASUOKA Masahiko
On Tue, 30 Aug 2022 14:09:40 +0200 Theo Buehler wrote: > On Tue, Aug 30, 2022 at 01:01:47PM +0200, YASUOKA Masahiko wrote: >> On Tue, 30 Aug 2022 11:56:53 +0200 >> Claudio Jeker wrote: >> > On Tue, Aug 30, 2022 at 11:18:01AM +0200, YASUOKA Masahiko wrote: >> >

Re: diff: b64decode(1) for long line

2022-08-30 Thread YASUOKA Masahiko
On Tue, 30 Aug 2022 11:56:53 +0200 Claudio Jeker wrote: > On Tue, Aug 30, 2022 at 11:18:01AM +0200, YASUOKA Masahiko wrote: >> @@ -423,11 +423,13 @@ uu_decode(void) >> } >> } >> >> +#define ROUNDDOWN(x,y) (((x)/(y)) * (y)) >> + >> static

diff: b64decode(1) for long line

2022-08-30 Thread YASUOKA Masahiko
b64decode(8) fails if a long line is given. % wc test 1 11370 test % % ./b64decode -r test > /dev/null b64decode: test: /dev/stdout: error decoding base64 input stream % uudecode.c 426 static int 427 base64_decode(void) 428 { 429 int n; 430

Re: pppac(4): don't grab netlock within pppacioctl()

2022-07-22 Thread YASUOKA Masahiko
ok yasuoka On Mon, 18 Jul 2022 13:50:37 +0300 Vitaliy Makkoveev wrote: > pipex(4) doesn't rely on netlock anymore. > > Index: sys/net/if_pppx.c > === > RCS file: /cvs/src/sys/net/if_pppx.c,v > retrieving revision 1.119 > diff -u -p

Re: pipex(4): kill "Static" keyword

2022-07-22 Thread YASUOKA Masahiko
ok yasuoka On Mon, 18 Jul 2022 12:31:47 +0300 Vitaliy Makkoveev wrote: > We don't use "static" keyword for functions declaration to allow ddb(4) > debug. Also, many "Static" functions are called by pppx(4) layer outside > pipex(4) layer. > > This is the mostly mechanic diff, except the `pipex_pp

Re: wg(4): 'Address already in use' when wgrtable is changed

2022-07-21 Thread YASUOKA Masahiko
Hello, Let me ask "ok", The diff fixes the problem as follows: Configure wg0 without wgrtable # ifconfig wg0 create wgport 7111 wgkey `openssl rand -base64 32` up # ifconfig wg0 wg0: flags=80c3 mtu 1420 index 6 priority 0 llprio 3

Re: Is rdomain correct for rtable in man ifconfig?

2022-07-13 Thread YASUOKA Masahiko
Hello, On Thu, 14 Jul 2022 14:09:52 +0900 (JST) Masato Asou wrote: > The TUNNEL in the man ifconfig(8) is described as follows: > > TUNNEL > > tunneldomain rtable > ^^here > Use routing table rtable instead of the default table. The >

Re: pipex(4): remove PIPEXCSESSION ioctl(2) command

2022-07-11 Thread YASUOKA Masahiko
ok yasuoka On Mon, 11 Jul 2022 01:11:22 +0300 Vitaliy Makkoveev wrote: > Long time ago pipex(4) session can't be deleted until both pipex(4) > input and output queues become empty. Dead sessions were linked to the > stack and the `ip_forward' flag was used to prevent packets forwarding. > npppd(8

Re: pipex(4): Add missing lock around all sessions loop within pipex_ip_output()

2022-07-09 Thread YASUOKA Masahiko
ok yasuoka On Sat, 9 Jul 2022 18:04:04 +0300 Vitaliy Makkoveev wrote: > On Sat, Jul 09, 2022 at 10:46:56PM +0900, YASUOKA Masahiko wrote: >> Hello, >> >> On Sat, 9 Jul 2022 01:43:41 +0300 >> Vitaliy Makkoveev wrote: >> > On Sat, Jul 09, 2022 at 12:08

Re: pipex(4): Add missing lock around all sessions loop within pipex_ip_output()

2022-07-09 Thread YASUOKA Masahiko
Hello, On Sat, 9 Jul 2022 01:43:41 +0300 Vitaliy Makkoveev wrote: > On Sat, Jul 09, 2022 at 12:08:49AM +0300, Vitaliy Makkoveev wrote: >> Thanks for pointing. >> >> > On 8 Jul 2022, at 23:13, Alexander Bluhm wrote: >> > >> > On Fri, Jul 08, 2022 at 05:42:23PM +0300, Vitaliy Makkoveev wrote: >>

Re: pipex(4): Add missing lock around all sessions loop within pipex_ip_output()

2022-07-08 Thread YASUOKA Masahiko
Hello, On Fri, 8 Jul 2022 00:53:16 +0300 Vitaliy Makkoveev wrote: > The `pipex_list_mtx' mutex(9) protects global pipex(4) lists so it need > to be taken while we perform this foreach loop. > > The all sessions loop was reworked to make possible to drop the lock > within. This is required becaus

Re: [v3] amd64: simplify TSC sync testing

2022-07-06 Thread YASUOKA Masahiko
On Thu, 07 Jul 2022 14:02:35 +0900 (JST) YASUOKA Masahiko wrote: > Hello Scott, > > With the patch, my machine on ESXi it doesn't show any extra message. > > *Without* the patch, the machine shows > > % grep 'TSC.*skew' dmesg.current-tsc-debug > cpu1:

Re: [v3] amd64: simplify TSC sync testing

2022-07-06 Thread YASUOKA Masahiko
Hello Scott, With the patch, my machine on ESXi it doesn't show any extra message. *Without* the patch, the machine shows % grep 'TSC.*skew' dmesg.current-tsc-debug cpu1: disabling user TSC (skew=-2603) cpu2: disabling user TSC (skew=-2959) cpu3: disabling user TSC (skew=-3784) % and mono

Re: npppd(8): remove PIPEXCSESSION ioctl(2) command

2022-06-30 Thread YASUOKA Masahiko
ok yasuoka On Thu, 30 Jun 2022 12:26:55 +0300 Vitaliy Makkoveev wrote: > yasuoka@ remonded me, long time ago pipex(4) sessions can't be deleted > until both input and output queues become empty: > > pipex_timer(void *ignored_arg) > { > /* ... */ > switch (session->state) { >

Re: selecting proper GOP when there are multiple GOPs

2022-06-16 Thread YASUOKA Masahiko
On Thu, 16 Jun 2022 19:37:57 +0200 (CEST) Mark Kettenis wrote: >> Date: Thu, 16 Jun 2022 23:49:05 +0900 (JST) >> From: YASUOKA Masahiko (snip) >> @@ -444,6 +445,30 @@ efi_video_init(void) >> int i, mode80x25, m

Re: selecting proper GOP when there are multiple GOPs

2022-06-16 Thread YASUOKA Masahiko
On Thu, 16 Jun 2022 15:52:41 +0300 Nick Henderson wrote: > Any updates on this patch? Would love to see it included in the next release. Yes. I'll commit this this weekend even if I don't get no ok. ok? Index: sys/arch/amd64/stand/efiboot/efiboot.c =

Re: wg(4): 'Address already in use' when wgrtable is changed

2022-06-11 Thread YASUOKA Masahiko
Hi, On Sun, 27 Mar 2022 18:25:18 +0900 (JST) YASUOKA Masahiko wrote: > On Wed, 9 Mar 2022 15:28:44 +0900 > Yuichiro NAITO wrote: >> I see 'Address already in use' message, >> when I change wgrtable for a running wg interface. >> It doesn't make sense to

selecting proper GOP when there are multiple GOPs

2022-05-02 Thread YASUOKA Masahiko
Hello, The below diff originally posted by Alexei K. on bugs@: Garbled screen when booting with UEFI https://marc.info/?l=openbsd-bugs&m=165087969227708&w=2 The same problem had been reported periodically and we have asked to use "machine gop" to workaround it. But the diff from Alexei se

Re: wg(4): 'Address already in use' when wgrtable is changed

2022-04-01 Thread YASUOKA Masahiko
on table 1 fails with EADDRINUSE when 7111/udp on rtable 0 is used. > On 3/28/22 15:59, YASUOKA Masahiko wrote: >> On Mon, 28 Mar 2022 15:20:02 +0900 >> Yuichiro NAITO wrote: >>> Thanks for the explanation. >>> I understand how your patch works. >>> >

Re: wg(4): 'Address already in use' when wgrtable is changed

2022-03-28 Thread YASUOKA Masahiko
is nothing to do, since the command is to bind the same port, protocol, and domain of prevous. The code seems to do such the skip already, but it lacks consideration for rtable_l2(rtable) != rtable case. > On 3/28/22 14:01, YASUOKA Masahiko wrote: >> Hi, >> On Mon, 28 Mar 2022 12:12:39

Re: wg(4): 'Address already in use' when wgrtable is changed

2022-03-27 Thread YASUOKA Masahiko
Hi, On Mon, 28 Mar 2022 12:12:39 +0900 Yuichiro NAITO wrote: > On 3/27/22 18:25, YASUOKA Masahiko wrote: >> Hi, >> On Wed, 9 Mar 2022 15:28:44 +0900 >> Yuichiro NAITO wrote: >>> I see 'Address already in use' message, >>> when I change wgrtabl

Re: wg(4): 'Address already in use' when wgrtable is changed

2022-03-27 Thread YASUOKA Masahiko
Hi, On Wed, 9 Mar 2022 15:28:44 +0900 Yuichiro NAITO wrote: > I see 'Address already in use' message, > when I change wgrtable for a running wg interface. > It doesn't make sense to me. > > It can be reproduced by the following command sequence. > > ``` > # route -T1 add default `cat /etc/mygat

Re: parallel ip forwarding

2021-12-30 Thread YASUOKA Masahiko
Hi, On Sat, 25 Dec 2021 21:50:47 +0300 Vitaliy Makkoveev wrote: > On Fri, Dec 24, 2021 at 12:50:23PM +0100, Alexander Bluhm wrote: >> On Fri, Dec 24, 2021 at 04:16:28PM +0900, YASUOKA Masahiko wrote: >> > > - npppd l2pt ipsecflowinfo is not MP safe >> > >>

Re: parallel ip forwarding

2021-12-23 Thread YASUOKA Masahiko
Hello, On Fri, 24 Dec 2021 00:55:04 +0100 Alexander Bluhm wrote: > On Fri, Dec 03, 2021 at 08:35:45PM +0100, Alexander Bluhm wrote: >> Note that IPsec still has the workaround to disable multiple queues. > > I think we can remove the ipsec_in_use workaround now. The IPsec > path is protected wi

Re: Fix ipsp_spd_lookup() for transport mode

2021-12-23 Thread YASUOKA Masahiko
Hi, On Mon, 20 Dec 2021 13:20:46 +0100 Alexander Bluhm wrote: > On Tue, Dec 14, 2021 at 06:25:20PM +0900, YASUOKA Masahiko wrote: >> Yes, if there is another better idea, it will be welcome. >> For this moment, the diff is the best idea for me. > > Sorry, no better idea.

Re: Fix ipsp_spd_lookup() for transport mode

2021-12-14 Thread YASUOKA Masahiko
Hi, On Tue, 14 Dec 2021 01:20:49 +0100 Alexander Bluhm wrote: > 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. Yes, I've tested some L2TP/IPsec cases already. > The tdb mutex and ref counting looks correct. > >>

Re: Fix ipsp_spd_lookup() for transport mode

2021-12-01 Thread YASUOKA Masahiko
On Wed, 1 Dec 2021 00:27:06 +0100 Alexander Bluhm wrote: > On Tue, Nov 30, 2021 at 05:53:34PM +0300, Vitaliy Makkoveev wrote: >> Hi, >> >> This question is mostly for bluhm@. Should the gettdbbyflow() grab the >> extra reference on returned `tdbp' like other other gettdb*() do? I'm >> pointing th

Re: Fix ipsp_spd_lookup() for transport mode

2021-11-29 Thread YASUOKA Masahiko
Hi, Let me update the diff. Previous has a problem in ipsp_spd_lookup() which uses "rn" without initialization. On Sat, 20 Nov 2021 21:44:20 +0900 (JST) YASUOKA Masahiko wrote: > On Wed, 12 May 2021 19:11:09 +0900 (JST) > YASUOKA Masahiko wrote: >> Radek reported a

Fix ipsp_spd_lookup() for transport mode (was Re: Fix IPsec NAT-T for L2TP/IPsec)

2021-11-20 Thread YASUOKA Masahiko
Hi, On Wed, 12 May 2021 19:11:09 +0900 (JST) YASUOKA Masahiko wrote: > Radek reported a problem to misc@ that multiple Windows clients behind > a NAT cannot use a L2TP/IPsec server simultaneously. > > https://marc.info/?t=16099681611&r=1&w=2 > > There is two p

Re: diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits

2021-11-02 Thread YASUOKA Masahiko
Hi, On Tue, 2 Nov 2021 07:03:43 + Jason McIntyre wrote: > On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote: >> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits. >> >> sbin/ipsecctl/ike.c: >> 201

diff: isakmpd.conf.5, clarify ANY can be used for some params

2021-11-01 Thread YASUOKA Masahiko
ok? Clarify that ANY can be used for several parameters of IPsec transform. Index: sbin/isakmpd/isakmpd.conf.5 === RCS file: /cvs/src/sbin/isakmpd/isakmpd.conf.5,v retrieving revision 1.135 diff -u -p -r1.135 isakmpd.conf.5 --- sbin/

diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits

2021-11-01 Thread YASUOKA Masahiko
I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits. sbin/ipsecctl/ike.c: 201 case ENCXF_AES: 202 enc_alg = "AES"; 203 key_length = "128,128:256"; 204 br

Re: Exit status of pkg_add

2021-10-18 Thread YASUOKA Masahiko
Hi, # drop ccing misc@ The diff seems ok for me. ok to commit it in? On Tue, 19 Oct 2021 10:42:04 +0900 Yuichiro NAITO wrote: > Following patch changes pkg_add to return a error code, > if a package name is wrong. > > diff --git a/usr.sbin/pkg_add/OpenBSD/AddDelete.pm > b/usr.sbin/pkg_add/Ope

Re: Fix IPsec NAT-T for L2TP/IPsec

2021-05-12 Thread YASUOKA Masahiko
On Wed, 12 May 2021 19:11:09 +0900 (JST) YASUOKA Masahiko wrote: > Radek reported a problem to misc@ that multiple Windows clients behind > a NAT cannot use a L2TP/IPsec server simultaneously. > > https://marc.info/?t=16099681611&r=1&w=2 > > There is two problems.

Re: Fix IPsec NAT-T for L2TP/IPsec

2021-05-12 Thread YASUOKA Masahiko
On Wed, 12 May 2021 19:15:29 +0300 Vitaliy Makkoveev wrote: >> On 12 May 2021, at 18:42, YASUOKA Masahiko wrote: >> On Wed, 12 May 2021 17:26:51 +0300 >> Vitaliy Makkoveev wrote: >>> On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote: >>>>

Re: Fix IPsec NAT-T for L2TP/IPsec

2021-05-12 Thread YASUOKA Masahiko
On Wed, 12 May 2021 17:26:51 +0300 Vitaliy Makkoveev wrote: > On Wed, May 12, 2021 at 07:11:09PM +0900, YASUOKA Masahiko wrote: >> Radek reported a problem to misc@ that multiple Windows clients behind a NAT >> cannot use a L2TP/IPsec server simultaneously. >> &g

Fix IPsec NAT-T for L2TP/IPsec

2021-05-12 Thread YASUOKA Masahiko
Hi, Radek reported a problem to misc@ that multiple Windows clients behind a NAT cannot use a L2TP/IPsec server simultaneously. https://marc.info/?t=16099681611&r=1&w=2 There is two problems. First is pipex(4) doesn't pass the proper ipsecflowinfo to ip_output(). Second is the IPsec po

Re: monotonic time going back by wrong skews

2021-04-06 Thread YASUOKA Masahiko
pr 2021 09:21:40 +0200 Giovanni Bechis wrote: > On Mon, Apr 05, 2021 at 07:14:49PM +0900, YASUOKA Masahiko wrote: >> Hi, >> >> > Another issue that I see is that people have not reported, at least > [...] >> > publicly, that this runs fine on their normal OpenBSD

Re: monotonic time going back by wrong skews

2021-04-05 Thread YASUOKA Masahiko
On Mon, 5 Apr 2021 14:24:03 +0200 (CEST) Mark Kettenis wrote: >> Date: Mon, 05 Apr 2021 19:14:49 +0900 (JST) >> From: YASUOKA Masahiko >> >> Hi, >> >> On Mon, 5 Apr 2021 10:43:00 +0300 >> Paul Irofti wrote: >> > On 05.04.2021 06:13, Scott

Re: monotonic time going back by wrong skews

2021-04-05 Thread YASUOKA Masahiko
Hi, On Mon, 5 Apr 2021 10:43:00 +0300 Paul Irofti wrote: > On 05.04.2021 06:13, Scott Cheloha wrote: >> On Mon, Mar 29, 2021 at 02:00:01PM +0900, YASUOKA Masahiko wrote: >>> On Thu, 25 Mar 2021 19:41:35 +0100 (CET) >>> Mark Kettenis wrote: >>>>> From: S

Re: monotonic time going back by wrong skews

2021-03-28 Thread YASUOKA Masahiko
On Thu, 25 Mar 2021 19:41:35 +0100 (CET) Mark Kettenis wrote: >> From: Scott Cheloha >> Date: Thu, 25 Mar 2021 13:18:04 -0500 >> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote: >> Which diff did you apply? Yasuoka provided two diffs. >>

Re: fyi: get HP EliteBook 830 G7/G8 booting

2021-03-26 Thread YASUOKA Masahiko
On Fri, 26 Mar 2021 12:12:44 +0100 (CET) Mark Kettenis wrote: >> Date: Fri, 26 Mar 2021 19:43:23 +0900 (JST) >> From: YASUOKA Masahiko >> >> Hi, >> >> On Fri, 26 Mar 2021 09:30:43 +0100 >> Jan Klemkow wrote: >> > If you want to boot O

Re: fyi: get HP EliteBook 830 G7/G8 booting

2021-03-26 Thread YASUOKA Masahiko
Hi, On Fri, 26 Mar 2021 09:30:43 +0100 Jan Klemkow wrote: > If you want to boot OpenBSD on an HP EliteBook 830 G7/G8, the bootloader > will hang while loading the kernel. Because, the UEFI loads the > bootloader on the same place in memory, where the bootloader will copy > the kernel. We are un

Re: monotonic time going back by wrong skews

2021-03-24 Thread YASUOKA Masahiko
like 900, 900, 900, 900, 0, 900, 900, 900 you pick 0 which could lead > to some problems, right? Or am I missing something?" > > So could people give the minimum skew approach a spin on real machines > to see if there are any issues popping up? > > All the best, > Paul >

monotonic time going back by wrong skews

2021-03-24 Thread YASUOKA Masahiko
Hi, I hit a problem which is caused by going back of monotonic time. It happens on hosts on VMware ESXi. I wrote the program which repeats the problem. % cc -o monotime monotime.c -lpthread % ./monotime 194964 Starting 562210 Starting 483046 Starting 148865 Starting 148865 Back 991.80804

Re: diff: efiboot: alignment for media which has IoAlign > 1

2021-03-10 Thread YASUOKA Masahiko
On Wed, 10 Mar 2021 13:15:58 +0100 (CET) Mark Kettenis wrote: >> On Wed, 10 Mar 2021 20:35:41 +0900 (JST) >> YASUOKA Masahiko wrote: >> > efiboot cannot load the kernel properly on some machines if booted >> > from CD-ROM. In that case boot fa

Re: diff: efiboot: alignment for media which has IoAlign > 1

2021-03-10 Thread YASUOKA Masahiko
versed.. On Wed, 10 Mar 2021 20:35:41 +0900 (JST) YASUOKA Masahiko wrote: > efiboot cannot load the kernel properly on some machines if booted > from CD-ROM. In that case boot fails with a message like follow: > >booting cd0a:. [359648read symbols: Unknown error: code 255 >

diff: efiboot: alignment for media which has IoAlign > 1

2021-03-10 Thread YASUOKA Masahiko
Hi, efiboot cannot load the kernel properly on some machines if booted from CD-ROM. In that case boot fails with a message like follow: booting cd0a:. [359648read symbols: Unknown error: code 255 As far as Asou and my test, this happens on hosts on VMware ESXi 6.7, 7.0 and asou's physica

Re: 2 diffs for dev/acpi/dsdt.c

2021-02-27 Thread YASUOKA Masahiko
Hi, Let me update "diff #2". On Fri, 26 Feb 2021 13:42:32 +0900 (JST) YASUOKA Masahiko wrote: > My vaio repeatedly crashed by "Data modified on freelist"(*1) or other > memory corruptions. After my long time debug, I found the route cause > is a handling of r

2 diffs for dev/acpi/dsdt.c

2021-02-25 Thread YASUOKA Masahiko
Hi, My vaio repeatedly crashed by "Data modified on freelist"(*1) or other memory corruptions. After my long time debug, I found the route cause is a handling of references of LocalX, like the following: If ((SMRW (0x0B, 0x16, 0x21, RefOf (Local0)) == Zero)) In the called co

Re: pppac(4): remove `sc_dead' logic

2021-02-10 Thread YASUOKA Masahiko
ok yasuoka Thanks, On Tue, 9 Feb 2021 12:06:08 +0300 Vitaliy Makkoveev wrote: > `sc_dead' is used to prevent pppac_ioctl() be called on dying pppac(4) > interface. But now if_detach() makes dying `ifp' inaccessible and waits > for references which are in-use. This logic is not required anymore.

Re: npppd(8)/pppac(4): remove dummy TUNSIFMODE ioctl(2) call

2021-01-31 Thread YASUOKA Masahiko
Yes, ok yasuoka On Fri, 29 Jan 2021 14:32:39 +0300 Vitaliy Makkoveev wrote: > Since OpenBSD 6.7 npppd(8) can't work over tun(4) anymore. I propose to > remove dummy TUNSIFMODE ioctl(2) call. > > Index: sys/net/if_pppx.c > === > RCS

Re: Wireguard: can't remove multiple peers at once.

2021-01-13 Thread YASUOKA Masahiko
Hi, On Thu, 14 Jan 2021 08:54:36 +0900 Yuichiro NAITO wrote: > Does anybody please review my code? > > Yasuoka-san is my coleague of my work. > So, he is interested in this topic. That’s why I CCed this mail. > I don’t mean he is an reviewer. > >> 2021/01/12 11:27、Yuichiro NAITO のメール: >> I have

Re: pipex(4)/npppd(8): remove dummy PIPEX{G,S}MODE ioctl(2) calls

2021-01-02 Thread YASUOKA Masahiko
Yes, ok yasuoka On Wed, 30 Dec 2020 03:02:55 +0300 Vitaliy Makkoveev wrote: > This time pipex(4) related ioctl(2) calls PIPEX{S,G}MODE are pretty > dummy and were kept for backward compatibility reasons. The diff below > removes them. > > ok? > > Index: share/man/man4/pipex.4 > ==

Re: diff: pfctl: error message for nonexisting rtable

2020-09-17 Thread YASUOKA Masahiko
the condition was reversed. ok? Index: parse.y === RCS file: /cvs/src/sbin/pfctl/parse.y,v retrieving revision 1.702 diff -u -p -r1.702 parse.y --- parse.y 17 Sep 2020 10:09:43 - 1.702 +++ parse.y 17 Sep 2020 14:23:42

Re: diff: pfctl: error message for nonexisting rtable

2020-09-17 Thread YASUOKA Masahiko
Hi, I just committed yours. Thanks, On Wed, 16 Sep 2020 16:07:40 +0200 Klemens Nanni wrote: > On Wed, Sep 16, 2020 at 07:49:19PM +0900, YASUOKA Masahiko wrote: >> New diff is using -1 for ENOENT. >> >> Also domainid == 0 is a valid domain id, but previous diff cannot

Re: diff: pfctl: error message for nonexisting rtable

2020-09-16 Thread YASUOKA Masahiko
Hi, On Wed, 16 Sep 2020 12:04:55 +0200 Klemens Nanni wrote: > Using the function verb would reads a bit clearer/more intuitive, > i.e. Yes, "if (!rtable_exists($2))" seems better. >> @@ -5887,17 +5897,37 @@ rdomain_exists(u_int rdomain) >> >> len = sizeof(info); >> if (sysctl(mib, 6

Re: diff: pfctl: error message for nonexisting rtable

2020-09-16 Thread YASUOKA Masahiko
Hi, So, it seems we need to more code and test for pf(4) part. Let me continue this separetely. On Mon, 14 Sep 2020 11:07:53 +0200 Klemens Nanni wrote: > On Mon, Sep 14, 2020 at 02:09:27PM +0900, YASUOKA Masahiko wrote: >> Make pfctl check if the rtable really exists when parsing t

  1   2   3   4   >