On Tue, 31 Jan 2023 11:30:43 +0300 Vitaliy Makkoveev <m...@openbsd.org> 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 <m...@openbsd.org> 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(4) has no this problem, because corresponding pppac >> > interface always created when npppd(8) opened device node. >> > >> > In fact, npppd(8) will not work with pppx(4) interfaces without pipex(4) >> > support. Otherwise npppd(8) should create pppx(4) sessions with not >> > pipex(4) specific PIPEXASESSION ioctl(2) command. >> > >> > I propose to remove "pipex" option from npppd(8). We already have >> > "net.pipex.enable" sysctl MIB to control pipex behaviour. In the case >> > then "net.pipex.enable" is set to 0, pipex(4) sessions will be always >> > created, but the traffic will go outside pipex(4) layer. >> > >> > The "ifdef USE_NPPPD_PIPEX" left as is. If we decide to remove them, I >> > will do this with the next diffs. >> >> Will the next diff remove the networking part (MPPE, IP) as well? >> >> > Please note, we never have complains about the problem described above, >> > so I doubt someone uses npppd(8) with "pipex no" in the npppd.conf(5). >> >> I don't know why you configured "pipex no", I suppose it was for >> debug. I also actually use "pipex no" when debug or development. > > I used this option to test my/visa@ diff which replaced selwakeup() by > KNOTE(9) and found that pppx(4) case is broken if this option is set to > "no".
So you used "pipex no" for test. That exactly is the purpose of "pipex yes/no". > Since we have the ability of enable/disable pipex(4) globally, I > propose to remove this option. No, they have different purposes. Without "pipex yes/no" option, we can't test the networking part (IP, MPPE) of npppd for without pipex. > in fact, for the pppx(4) case npppd(8) is absolutely useless without > pipex(4) support, so I don't see any reasons to build it without > pipex(4). I don't propose to remove the whole "ifdef USE_NPPPD_PIPEX" > blocks, only preprocessor directives. Sorry, if my suggestion was not > clear. Note that the networking part (IP, MPPE) of npppd works with/without pipex. So just removing #ifdef lines, npppd still has "the networking part without pipex". As the result of removing "pipex yes/no" option, we can't test that part. If you are to remove the networking part (IP, MPPE) of npppd completely, removing "pipex yes/no" option makes sense since we don't need to test it anymore. But I'd like to keep the networking part since it is needed when adding a tunneling protocol which is not supported by pipex, or running npppd on another OS. >> If having "pipex yes/no" configuration is misleading, we can improve >> the man page or the configuration itself. > > pipex yes | no > Specify whether npppd(8) uses pipex(4). The default is > “yes”. The sysctl(8) variable net.pipex.enable should > also be enabled to use pipex(4). > > There is no misleading. But with "pipex no" npppd(8) is usable with > pppac(4), but with pppx(4) it is not. Also, I don't like that it > successfully creates connection. Guess, it better to deny "pipex no" > for pppx(4). >
