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 >

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=1=2 > > There is two problems. First i

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: >>&g

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=1=2 There is two problems. First is pipex(4) doesn't pass the proper ipsecflowinfo to ip_output(). Second is the IPsec

Re: monotonic time going back by wrong skews

2021-04-06 Thread YASUOKA Masahiko
: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 machines.

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

Re: monotonic time going back by wrong skews

2021-03-24 Thread YASUOKA Masahiko
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

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

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

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

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 > === >

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

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

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 c

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,

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

Re: diff: pfctl: error message for nonexisting rtable

2020-09-14 Thread YASUOKA Masahiko
Hi, On Tue, 15 Sep 2020 02:31:24 +0200 Klemens Nanni wrote: > On Tue, Sep 15, 2020 at 12:30:35AM +0200, Klemens Nanni wrote: >> Actually, that should just work regardless of whether the rounting >> domain exists at ruleset creation time; just like it is the case with >> interface names/groups

diff: pfctl: error message for nonexisting rtable

2020-09-13 Thread YASUOKA Masahiko
Hi, When pf rule with a "on rdomain n" with nonexisting rdomain n causes /etc/pf.conf:XXX: rdomain n does not exist error. But with a "rtable n" with nonexisting rtable n will cause pfctl: DIOCADDRULE: Device busy error. It is hard to find the cause by this error message.

Re: httpd: use the original uri for REQUEST_URI

2020-09-11 Thread YASUOKA Masahiko
Anyone? This is a tiny change but makes httpd(8) more correct. The diff is not so complicated. On Thu, 03 Sep 2020 13:09:49 +0900 (JST) YASUOKA Masahiko wrote: > Let me update the diff. Previous doesn't have an error handling when > strdup() failed. > > On Thu, 03 Sep 2020 13:02:5

Re: httpd: use the original uri for REQUEST_URI

2020-09-02 Thread YASUOKA Masahiko
Let me update the diff. Previous doesn't have an error handling when strdup() failed. On Thu, 03 Sep 2020 13:02:51 +0900 (JST) YASUOKA Masahiko wrote: > The diff makes REQUEST_URI in FastCGI become the original request > URI. Currently it is an url which is url decoded and canonicalize

httpd: use the original uri for REQUEST_URI

2020-09-02 Thread YASUOKA Masahiko
The diff makes REQUEST_URI in FastCGI become the original request URI. Currently it is an url which is url decoded and canonicalized. I could not find a specification of REQUEST_URI, but I suppose it is the URI in HTTP request. Apache httpd and nginx is using the original URI for it. ok? Use

Re: Make pipex more common for pppac and pppx

2020-08-26 Thread YASUOKA Masahiko
On Mon, 24 Aug 2020 20:07:48 +0300 Vitaliy Makkoveev wrote: > I pointed some comments inline. Thanks, >> +case PIPEXASESSION: >> +{ >> +struct pipex_session_req *req = >> +(struct pipex_session_req *)data; >> +if ((error = pipex_init_session(,

Re: Make pipex more common for pppac and pppx

2020-08-19 Thread YASUOKA Masahiko
Hi, Thank you for your comments. On Mon, 17 Aug 2020 00:15:08 +0300 Vitaliy Makkoveev wrote: > I like your idea to kill `pipex_iface_context'. I had trying to keep it > by myself and this was wrong way. Could you rework your diff to be > against the recent sources? I'm sorry the diff was for

Re: Make pipex more common for pppac and pppx

2020-08-15 Thread YASUOKA Masahiko
Let me update the diff. A bug found by the test. diff --git a/sys/net/if_pppx.c b/sys/net/if_pppx.c index 62b85bc34af..6d3de6973bd 100644 --- a/sys/net/if_pppx.c +++ b/sys/net/if_pppx.c @@ -163,7 +163,6 @@ struct pppx_if { struct ifnetpxi_if; struct pppx_dev

Make pipex more common for pppac and pppx

2020-08-15 Thread YASUOKA Masahiko
This diff makes pipex become more common for pppac and pppx. - Delete "pipex_iface_context". It had been created when pppx doesn't exist. This creates some confusions. For example session->pipex_iface is the device context when pppac(4) but it's not when pppx(4). 623 Static int

Re: pppac(4): destroy sessions the same way as pppx(4) does

2020-08-14 Thread YASUOKA Masahiko
On Wed, 12 Aug 2020 12:26:22 +0300 Vitaliy Makkoveev wrote: > We destroy pppx(4) related sessions while we performing PIPEXDSESSION > command. But with pppac(4) we set session's state to > PIPEX_STATE_CLOSE_WAIT2 and we wait garbage collector to do destruction. pppac's PIPEXDSESSION set the

Re: pipex "idle-timeout" work with pppx(4).

2020-08-12 Thread YASUOKA Masahiko
Hi, On Wed, 12 Aug 2020 12:38:39 +0300 Vitaliy Makkoveev wrote: > We don't need to mark pppx(4) sessions because there is no special cases > for them. We just need to kill pppx(4) related "pr_timeout_sec != 0" > checks and call pipex_get_closed() by pppx_get_closed(). How do you implement that

Re: pipex "idle-timeout" work with pppx(4).

2020-08-11 Thread YASUOKA Masahiko
On Tue, 11 Aug 2020 23:06:45 +0300 Vitaliy Makkoveev wrote: > We removed `pipex{in,out}q'. So now we can destroy pppac(4) session just > like we do in pppx(4) case. Also there is no reason to allow > pipex_timer() to destroy sessions - userland will do this by > PIPEXDSESSION. This permit us to

Re: pipex "idle-timeout" work with pppx(4).

2020-08-11 Thread YASUOKA Masahiko
my diff is to make pppx(4) have the same "idle-timeout" functionality. I strongly think pppx(4) must have the same functionalities of pppac(4) because I don't see any reason to have any difference between pppx(4) and pppac(4). Your pseudo code is suggesting another thing. You would like to

Re: pipex "idle-timeout" work with pppx(4).

2020-08-11 Thread YASUOKA Masahiko
Hi, On Mon, 10 Aug 2020 16:30:27 +0300 Vitaliy Makkoveev wrote: > On Mon, Aug 10, 2020 at 03:12:02PM +0900, YASUOKA Masahiko wrote: >> On Sun, 9 Aug 2020 20:03:50 +0300 >> Vitaliy Makkoveev wrote: >> > On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev

Re: pipex "idle-timeout" work with pppx(4).

2020-08-10 Thread YASUOKA Masahiko
Hi, Thank you for your review. On Sun, 9 Aug 2020 20:03:50 +0300 Vitaliy Makkoveev wrote: > On Sun, Aug 09, 2020 at 06:20:13PM +0300, Vitaliy Makkoveev wrote: >> You propose to unlink pppx(4) related session which reached timeout. I'm >> ok with this direction. But I see no reason to rework

pipex "idle-timeout" work with pppx(4).

2020-08-09 Thread YASUOKA Masahiko
This diff makes pipex "idle-timeout" work with pppx(4). ok? Index: sys/net/if_pppx.c === RCS file: /disk/cvs/openbsd/src/sys/net/if_pppx.c,v retrieving revision 1.98 diff -u -p -r1.98 if_pppx.c --- sys/net/if_pppx.c 28 Jul 2020

Re: describe 'idle-timeout' exception in npppd.conf man page

2020-08-08 Thread YASUOKA Masahiko
On Sat, 8 Aug 2020 16:01:59 +0300 Vitaliy Makkoveev wrote: > On Sat, Aug 08, 2020 at 08:49:24PM +0900, YASUOKA Masahiko wrote: >> On Fri, 7 Aug 2020 22:19:05 +0300 >> Vitaliy Makkoveev wrote: >> > Some times ago we disabled in-kernel timeout for pppx(4) related >&g

Re: describe 'idle-timeout' exception in npppd.conf man page

2020-08-08 Thread YASUOKA Masahiko
On Fri, 7 Aug 2020 22:19:05 +0300 Vitaliy Makkoveev wrote: > Some times ago we disabled in-kernel timeout for pppx(4) related > pipex(4) sessions. We did this for prevent use after free issue caused > by pipex_timer [1]. By default "idle-timeout" is not set in > npppd.conf(5) and I guess this is

Re: [PATCH] pipex(4): rework PPP input

2020-08-04 Thread YASUOKA Masahiko
Sorry for delayed reply. On Wed, 27 May 2020 01:29:36 +0300 Sergey Ryazanov wrote: > On Tue, May 26, 2020 at 12:07 PM Vitaliy Makkoveev > wrote: >>> On 25 May 2020, at 22:04, Sergey Ryazanov wrote: >>> On Sat, May 23, 2020 at 3:07 PM Vitaliy Makkoveev >>> wrote: For example, each pipex

Re: pipex(4): kill pipexintr()

2020-08-03 Thread YASUOKA Masahiko
On Mon, 3 Aug 2020 23:36:09 +0300 Vitaliy Makkoveev wrote: > On Tue, Aug 04, 2020 at 01:26:14AM +0900, YASUOKA Masahiko wrote: >> Comments? > > You introduce `cookie' as > > cookie = session->protocol << 16 | session->session_id; > &

Re: pipex(4): kill pipexintr()

2020-08-03 Thread YASUOKA Masahiko
On Sat, 1 Aug 2020 18:52:27 +0300 Vitaliy Makkoveev wrote: > On Sat, Aug 01, 2020 at 07:44:17PM +0900, YASUOKA Masahiko wrote: >> I'm not sure when it is broken, in old versions, it was assumed the >> pipex queues are empty when pipex_iface_stop() is called. The proble

Re: pipex(4): kill pipexintr()

2020-08-01 Thread YASUOKA Masahiko
Hi, I'm not sure when it is broken, in old versions, it was assumed the pipex queues are empty when pipex_iface_stop() is called. The problem mvs@ found is the assumption is not true any more. pipex has a mechanism that delete a session when the queues are empty. 819 Static void 820

Re: pipex(4): kill pipexintr()

2020-07-30 Thread YASUOKA Masahiko
On Thu, 30 Jul 2020 22:43:10 +0300 Vitaliy Makkoveev wrote: > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote: >> On Thu, 30 Jul 2020 15:34:09 +0300 >> Vitaliy Makkoveev wrote: >> > On Thu, Jul 30, 2020 at 09:13:46PM +0900, YASUOKA Masahiko wrote: &

Re: pipex(4): kill pipexintr()

2020-07-30 Thread YASUOKA Masahiko
On Thu, 30 Jul 2020 22:43:10 +0300 Vitaliy Makkoveev wrote: > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote: >> On Thu, 30 Jul 2020 15:34:09 +0300 >> Vitaliy Makkoveev wrote: >> > On Thu, Jul 30, 2020 at 09:13:46PM +0900, YASUOKA Masahiko wrote: >&g

Re: pipex(4): kill pipexintr()

2020-07-30 Thread YASUOKA Masahiko
On Thu, 30 Jul 2020 15:34:09 +0300 Vitaliy Makkoveev wrote: > On Thu, Jul 30, 2020 at 09:13:46PM +0900, YASUOKA Masahiko wrote: >> Hi, >> >> sys/net/if_ethersubr.c: >> 372 void >> 373 ether_input(struct ifnet *ifp, struct mbuf *m) >> (snip) >>

Re: pipex(4): kill pipexintr()

2020-07-30 Thread YASUOKA Masahiko
Hi, sys/net/if_ethersubr.c: 372 void 373 ether_input(struct ifnet *ifp, struct mbuf *m) (snip) 519 #if NPPPOE > 0 || defined(PIPEX) 520 case ETHERTYPE_PPPOEDISC: 521 case ETHERTYPE_PPPOE: 522 if (m->m_flags & (M_MCAST | M_BCAST)) 523 goto

Re: pf: route-to least-states

2020-07-28 Thread YASUOKA Masahiko
Hi, On Tue, 28 Jul 2020 18:54:48 +0200 Alexandr Nedvedicky wrote: > On Wed, Jul 29, 2020 at 01:22:48AM +0900, YASUOKA Masahiko wrote: >> Previous commit has a wrong part.. >> >> ok? >> >> Fix previous commit which referred wrong address. > > would

Re: pf: route-to least-states

2020-07-28 Thread YASUOKA Masahiko
Hi, Let me add another fix of previous. ok? Fix previous commit which referred wrong address and returned wrong value. Index: sys/net/pf_lb.c === RCS file: /cvs/src/sys/net/pf_lb.c,v retrieving revision 1.66 diff -u -p -r1.66

Re: pf: route-to least-states

2020-07-28 Thread YASUOKA Masahiko
Hi, Previous commit has a wrong part.. ok? Fix previous commit which referred wrong address. Index: sys/net/pf_lb.c === RCS file: /cvs/src/sys/net/pf_lb.c,v retrieving revision 1.65 diff -u -p -r1.65 pf_lb.c --- sys/net/pf_lb.c

relayd: set group and divert-reply

2020-07-26 Thread YASUOKA Masahiko
Hi, I'd like to run relayd as _relayd group always so that we can use "group _relayd" in a pf rule. This makes it possible to write a pf rule easily which is to match only connections from relayd(8). Also as for relayd.conf(5), I'd like to mention that "divert-reply" is required for

Re: pf_remove_divert_state

2020-07-26 Thread YASUOKA Masahiko
Thanks, On Sat, 25 Jul 2020 15:00:07 +0200 Alexander Bluhm wrote: > On Sat, Jul 25, 2020 at 09:37:37PM +0900, YASUOKA Masahiko wrote: >> Is this part a reason why we have "divert-reply"? > > Yes. > > Divert rules pass packets to the local network stack. With div

Re: pf_remove_divert_state

2020-07-25 Thread YASUOKA Masahiko
On Sat, 25 Jul 2020 13:29:57 +0200 Alexander Bluhm wrote: > On Sat, Jul 25, 2020 at 08:20:21PM +0900, YASUOKA Masahiko wrote: >> Currently SO_BINDANY is usable without any divert or divert-reply >> rule. > > This is why we have the divert-reply feature. Just mark the state

pf_remove_divert_state

2020-07-25 Thread YASUOKA Masahiko
Hi, # let me correct the previous mail, it has some typos. Currently SO_BINDANY is usable without any divert or divert-reply rule. pf reserves its associated PCB to its state when the packet is going out. This time, the pf rule is not required to have "divert" or "divert-reply" option. When

pf_remove_divert_state

2020-07-25 Thread YASUOKA Masahiko
Hi, Currently SO_BINDANY is usable without any divert or divert-reply rule. pf reserves its associated PCB to its state when the packet is going out. This time, the pf rule is not required to have "divert" or "divert-reply" option. When receiving reverse direction packets, those packets are

carp: unicast carppeer and peer down

2020-07-25 Thread YASUOKA Masahiko
Hi, When an unicast address is specified for carppeer, if the peer is down, sending out advertisemnent packets will fail, this failure is treated as an error of the sending host, then the error counter is incremented and carpdemote is incremenated. I think this is not correct because the failure

pfsync: comparing duration when "bulk-end"

2020-07-24 Thread YASUOKA Masahiko
Hi, pfsync does "bulk update" just after boot, I noticed it sometimes fails. When finishing "bulk update", the duration in the "bulk-end" packet and our duration based on uptime are compared, but that comparision should be fixed. It must consider the values are rounded in a second. ok?

Re: pf: route-to {random,srchash} in an anchor

2020-07-24 Thread YASUOKA Masahiko
Hi, On Thu, 23 Jul 2020 18:44:43 +0200 Alexandr Nedvedicky wrote: > On Thu, Jul 23, 2020 at 08:01:18PM +0900, YASUOKA Masahiko wrote: >> Hi, >> >> Last month, I fixed the problem "route-to least-state" in an anchor >> didn't work. >> >> https://

Re: pf: route-to least-states

2020-07-24 Thread YASUOKA Masahiko
Hi, Thank you for your review. On Fri, 24 Jul 2020 01:25:42 +0200 Alexandr Nedvedicky wrote: >> - interface is not selected properly if selected table entry specifies >> an interface. > > to be honest I don't quite understand what's going on here. > can you share some details of

pf: route-to least-states

2020-07-23 Thread YASUOKA Masahiko
Hi, The diff fixes 2 problems of "least-states": - states whose address is selected by sticky-address is not counted for the number of states. - interface is not selected properly if selected table entry specifies an interface. ok? Increase state counter for least-states when the address

pf: route-to {random,srchash} in an anchor

2020-07-23 Thread YASUOKA Masahiko
Hi, Last month, I fixed the problem "route-to least-state" in an anchor didn't work. https://marc.info/?t=15911745782=1=2 I noticed the same problem happens on "random" and "srchash" as well. ok? Use the table on root always if current table is not active. Index: sys/net/pf_lb.c

Re: receive interfacez for carp when real mac is used

2020-07-22 Thread YASUOKA Masahiko
The problem I was to fix had been fixed by dlg@'s commit today. https://marc.info/?l=openbsd-cvs=159538265604770=2 So the diff is not needed any more. Pointed out by dlg@. Thanks, On Wed, 22 Jul 2020 19:24:32 +0900 (JST) YASUOKA Masahiko wrote: > Hi, > > Currently when using the

receive interfacez for carp when real mac is used

2020-07-22 Thread YASUOKA Masahiko
Hi, Currently when using the real mac address for carp(4) interface, all packets are treated as their receive inteface is carp. This causes some problems. For example, IPv6 ndp doesn't work on an interface which is used for carpdev. Because it is assumed that reply packets are received with

Re: route add ::/0 ...

2020-07-06 Thread YASUOKA Masahiko
Let me updated the diff. On Mon, 06 Jul 2020 17:54:30 +0900 (JST) YASUOKA Masahiko wrote: > On Tue, 30 Jun 2020 02:42:02 +0200 > Klemens Nanni wrote: >> On Tue, Jun 30, 2020 at 09:00:30AM +0900, YASUOKA Masahiko wrote: >>> inet_makenetandmask() had required another tre

Re: route add ::/0 ...

2020-07-06 Thread YASUOKA Masahiko
On Tue, 30 Jun 2020 02:42:02 +0200 Klemens Nanni wrote: > On Tue, Jun 30, 2020 at 09:00:30AM +0900, YASUOKA Masahiko wrote: >> inet_makenetandmask() had required another treatment. >> >> Also -prefixlen 0 for -inet has a bug >> >> % doas ./obj/route -T1

Re: route add ::/0 ...

2020-06-29 Thread YASUOKA Masahiko
On Mon, 29 Jun 2020 19:18:17 +0200 Klemens Nanni wrote: > On Mon, Jun 29, 2020 at 11:55:10PM +0900, YASUOKA Masahiko wrote: >> The function mask_addr() doesn't mask address for IPv4 and IPv6. Does >> any address family other than IPv4 or IPv6 require #1142:1148? The >> f

Re: route add ::/0 ...

2020-06-29 Thread YASUOKA Masahiko
On Mon, 29 Jun 2020 18:45:07 +0900 (JST) YASUOKA Masahiko wrote: > On Mon, 29 Jun 2020 10:12:23 +0200 > Martin Pieuchot wrote: >> On 28/06/20(Sun) 20:41, YASUOKA Masahiko wrote: >>> Hi, >>> >>> When "::/0" is used as "default", >>

Re: route add ::/0 ...

2020-06-29 Thread YASUOKA Masahiko
Hi, On Mon, 29 Jun 2020 10:12:23 +0200 Martin Pieuchot wrote: > On 28/06/20(Sun) 20:41, YASUOKA Masahiko wrote: >> Hi, >> >> When "::/0" is used as "default", >> >> # route add ::/0 fe80::1%em0 >> add net ::/0: gateway fe80::1%em

route add ::/0 ...

2020-06-28 Thread YASUOKA Masahiko
Hi, When "::/0" is used as "default", # route add ::/0 fe80::1%em0 add net ::/0: gateway fe80::1%em0: Invalid argument route command trims the sockaddr to { .len = 2, .family = AF_INET6 } for "::/0", but rtable_satoplen() refuses it. I think it should be accepted. ok? Allow sockaddr for

Re: pipex(4): prevent `state_list' corruption

2020-06-22 Thread YASUOKA Masahiko
Yes, this seems right. ok yasuoka On Thu, 18 Jun 2020 23:53:25 +0300 Vitaliy Makkoveev wrote: > While pppac(4) destroy sessions by pipex_iface_fini() or by > pipex_ioctl() with PIPEXSMODE command, some sessions can be linked to > `state_list'. This case is not checked and sessions will never be

Re: install npppd.conf with mode 0600

2020-06-21 Thread YASUOKA Masahiko
The line in etc/mtree/special should be updated as well. npppd.conf type=file mode=0640 uname=root gname=wheel other than that, ok yasuoka On Sun, 21 Jun 2020 16:48:44 +0300 Vitaliy Makkoveev wrote: > We installing `npppd-users' with uid:gid root:wheel and mode 0600 > because it

Re: pf "route-to least-state" in an anchor doesn't work

2020-06-03 Thread YASUOKA Masahiko
Hello, On Wed, 3 Jun 2020 23:30:56 +0200 Alexandr Nedvedicky wrote: > I'm OK with your change. Thank you for your review and comment. > However I would like to ask you to do yet another test. I wonder if things > will eventually work on unfixed PF if rules will be constructed as follows: > >

pf "route-to least-state" in an anchor doesn't work

2020-06-03 Thread YASUOKA Masahiko
Hi, pf.conf: anchor { pass in on rdomain 102 quick proto tcp to 10.0.0.101 port 8080 \ keep state ( sloppy ) route-to \ least-states sticky-address } table { 10.0.0.11@pair102 } this doesn't work. All packets going to 10.0.0.101 are dropped with 'no-route'. The

Re: diff: init efifb even if VGA is probed.

2020-05-28 Thread YASUOKA Masahiko
On Thu, 28 May 2020 12:31:31 +0200 (CEST) Mark Kettenis wrote: >> Date: Thu, 28 May 2020 17:01:48 +0900 (JST) >> From: YASUOKA Masahiko >> >> Hi, >> >> I'd like to conclude this issue. >> >> On Fri, 21 Feb 2020 14:09:07 +0900 (JST) >> YAS

Re: diff: init efifb even if VGA is probed.

2020-05-28 Thread YASUOKA Masahiko
On Thu, 28 May 2020 17:01:48 +0900 (JST) YASUOKA Masahiko wrote: > Hi, > > I'd like to conclude this issue. > > On Fri, 21 Feb 2020 14:09:07 +0900 (JST) > YASUOKA Masahiko wrote: >> I am testing a new hardware, HPE DL20 Gen10. >> >> When efiboot starts t

Re: diff: init efifb even if VGA is probed.

2020-05-28 Thread YASUOKA Masahiko
Hi, I'd like to conclude this issue. On Fri, 21 Feb 2020 14:09:07 +0900 (JST) YASUOKA Masahiko wrote: > I am testing a new hardware, HPE DL20 Gen10. > > When efiboot starts the kernel, the video display becomes distorted > and never recovered until CPU reset. > >

fix pppac(4) without pipex

2020-04-12 Thread YASUOKA Masahiko
Hi, The diff followings fixes panics when using pppac(4) with "pipex no". Index: sys/net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.83 diff -u -p -r1.83 if_pppx.c --- sys/net/if_pppx.c 10 Apr 2020

Re: pipex(4) fix: check session existence before creation

2020-04-07 Thread YASUOKA Masahiko
ok yasuoka On Mon, 6 Apr 2020 19:54:20 +0300 Vitaliy Makkoveev wrote: > Deny to create pipex_session which is already exist. Newly created > session will be placed to list head so the caller of > pipex_*_lookup_session() will receive wrong session. > > Index: sys/net/if_pppx.c >

Re: Prevent memory corruption by pipex_timer()

2020-04-01 Thread YASUOKA Masahiko
Hi, Sorry for my silence. ok yasuoka for the daemon part. On Wed, 1 Apr 2020 09:27:10 +0200 Martin Pieuchot wrote: > On 31/03/20(Tue) 23:16, Vitaliy Makkoveev wrote: >> On Tue, Mar 31, 2020 at 06:15:46PM +0200, Martin Pieuchot wrote: >> > [...] >> > Well better fix npppd(8), no? Not crashing

Re: diff: init efifb even if VGA is probed.

2020-03-09 Thread YASUOKA Masahiko
Hi, Thank you for your test and feedback. On Fri, 6 Mar 2020 16:38:24 -0600 Andrew Daugherity wrote: > On Sun, Mar 1, 2020 at 10:41 PM YASUOKA Masahiko wrote: >> >> Hi, >> >> The problems you are pointing seem to be the same problem. >> >> > I'l

Re: efiboot, serial port order

2020-03-01 Thread YASUOKA Masahiko
Hi, On Sun, 23 Feb 2020 12:18:37 +0100 (CET) Mark Kettenis wrote: >> Date: Sat, 22 Feb 2020 10:40:13 +0900 (JST) >> From: YASUOKA Masahiko >> efiboot is using ACPI UID to determine the minor number of comX. (snip) >> I originally wrote this code, because I thou

diff: ipmi initializing watchdog

2020-03-01 Thread YASUOKA Masahiko
When I played with ipmi, I found problems in the initializing watchdog. As far as my test on HPE DL20 Gen10, the ipmi device refuses "set watchdog timer" command if "use" value (in first byte) is none. Since existing code uses the value which read from the device, if the value is not set on the

diff: "ipmi0: sendcmd fails"

2020-03-01 Thread YASUOKA Masahiko
Hi, On HPE DL20 Gen10, kernel keeps printing "ipmi0: sendcmd fails" if ipmi0 is enabled. The machine has following 4 sensor devices. 19-P/S 1 Inlet 20-P/S 2 Inlet 21-P/S 1 22-P/S 2 But reading value from these devices fails always. This causes the problem above. The diff makes such

Re: diff: init efifb even if VGA is probed.

2020-03-01 Thread YASUOKA Masahiko
Hi, On Fri, 21 Feb 2020 18:55:38 -0600 Andrew Daugherity wrote: > On Thu, Feb 20, 2020 at 11:10 PM YASUOKA Masahiko wrote: >> Hello, >> >> I am testing a new hardware, HPE DL20 Gen10. >> >> When efiboot starts the kernel, the video display becomes distorted

Re: diff: init efifb even if VGA is probed.

2020-02-27 Thread YASUOKA Masahiko
On Sun, 23 Feb 2020 21:23:41 +1100 Jonathan Gray wrote: > On Sun, Feb 23, 2020 at 07:06:50PM +0900, YASUOKA Masahiko wrote: >> On Sun, 23 Feb 2020 18:50:54 +0900 (JST) >> YASUOKA Masahiko wrote: >> > On Sat, 22 Feb 2020 13:02:48 +1100 >> > Jonathan Gray wrote:

Re: diff: init efifb even if VGA is probed.

2020-02-27 Thread YASUOKA Masahiko
On Sun, 23 Feb 2020 12:47:51 +0100 (CET) Mark Kettenis wrote: >> Date: Sun, 23 Feb 2020 18:50:54 +0900 (JST) >> From: YASUOKA Masahiko >> >> On Sat, 22 Feb 2020 13:02:48 +1100 >> Jonathan Gray wrote: >> > On Fri, Feb 21, 2020 at 02:09:07PM +0900, YAS

Re: diff: init efifb even if VGA is probed.

2020-02-23 Thread YASUOKA Masahiko
On Sun, 23 Feb 2020 18:50:54 +0900 (JST) YASUOKA Masahiko wrote: > On Sat, 22 Feb 2020 13:02:48 +1100 > Jonathan Gray wrote: >> On Fri, Feb 21, 2020 at 02:09:07PM +0900, YASUOKA Masahiko wrote: >>> When efiboot starts the kernel, the video display becomes distorted >>

Re: diff: init efifb even if VGA is probed.

2020-02-23 Thread YASUOKA Masahiko
On Sat, 22 Feb 2020 13:02:48 +1100 Jonathan Gray wrote: > On Fri, Feb 21, 2020 at 02:09:07PM +0900, YASUOKA Masahiko wrote: >> When efiboot starts the kernel, the video display becomes distorted >> and never recovered until CPU reset. >> >> Our kernel tries to initi

efiboot, serial port order

2020-02-21 Thread YASUOKA Masahiko
Hi, efiboot is using ACPI UID to determine the minor number of comX. In sys/arch/amd64/stand/efiboot/efiboot.c: 646 for (i = 0; i < sz / sizeof(EFI_HANDLE); i++) { 647 /* 648 * Identify port number of the handle. This assumes ACPI 649

Re: retries and timeouts for radiusctl(8) test

2020-02-20 Thread YASUOKA Masahiko
ok yasuoka On Fri, 21 Feb 2020 15:32:53 +1000 David Gwynne wrote: > we (work) use radiusctl as part of a check script with relayd so > we can try and keep a radius service available with some magical > routing and redirect configs. > > radiusctl is currently pretty simple and sends a radius

diff: init efifb even if VGA is probed.

2020-02-20 Thread YASUOKA Masahiko
Hello, I am testing a new hardware, HPE DL20 Gen10. When efiboot starts the kernel, the video display becomes distorted and never recovered until CPU reset. Our kernel tries to initialized console twice, first trial is done before getting boot info and second trial is done after getting boot

Re: remove needless #ifdef

2020-02-14 Thread YASUOKA Masahiko
committed. Thanks On Fri, 14 Feb 2020 08:48:06 +0100 Claudio Jeker wrote: > On Thu, Feb 13, 2020 at 11:50:46PM +0100, Jan Stary wrote: >> On Feb 10 09:28:38, yasu...@openbsd.org wrote: >> > Hi, >> > >> > On Sun, 09 Feb 2020 19:28:50 +0100 >> > Jeremie Courreges-Anglas wrote: >> > > On Sun,

diff: httpd, handling no content-lenght and not chunked trasfer

2020-02-14 Thread YASUOKA Masahiko
Hi, When httpd received the following request, POST /cgi-bin/test.cgi HTTP/1.0 Host: 127.0.0.1 Content-Type: application/json Content-Length: 0 if the request is handled by fastcgi, STDIN is closed immediately. But the problem is that STDIN is never closed if the request doesn't have

diff: nvme.c

2020-02-14 Thread YASUOKA Masahiko
Hi, I have a problem that kernel core dumping always hangs around first 8MB. The diff attached fixes the problem. In nvme_poll(): 930 while (!ISSET(state.c.flags, htole16(NVME_CQE_PHASE))) { 931 if (nvme_q_complete(sc, q) == 0) 932 delay(10);

Re: remove needless #ifdef

2020-02-09 Thread YASUOKA Masahiko
Hi, On Sun, 09 Feb 2020 19:28:50 +0100 Jeremie Courreges-Anglas wrote: > On Sun, Feb 09 2020, Jan Stary wrote: >> Currently, sys/net/pipex_local.h asks #ifdef __OpenBSD__ >> and if so, defines "Static" to be nothing, to use it later. >> That can go away, right? > > I believe that's something

  1   2   3   >