lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240212222155.shiacjlqupqoliym@begin>
Date: Mon, 12 Feb 2024 23:21:55 +0100
From: Samuel Thibault <samuel.thibault@...-lyon.org>
To: Tom Parkin <tparkin@...alix.com>
Cc: James Chapman <jchapman@...alix.com>, edumazet@...gle.com,
	gnault@...hat.com, davem@...emloft.net, kuba@...nel.org,
	pabeni@...hat.com, corbet@....net, netdev@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3] PPPoL2TP: Add more code snippets

Hello,

Thanks for reviewing, I'll send a v4.

Tom Parkin, le lun. 12 févr. 2024 21:25:32 +0000, a ecrit:
> > +        ret = ioctl(session_fd1, PPPIOCGCHAN, &chindx1);
> > +        if (ret < 0)
> > +                return -errno;
> > +
> > +        ret = ioctl(session_fd2, PPPIOCGCHAN, &chind2x);
> 
> I think we need to be clear here in this example what session_fd1 and
> session_fd2 are, and how they have come to be, since they haven't been
> mentioned in the examples so far.

Right (though it's called session_fd above), I have added explicit input
descriptions.

> I'm not sure whether it helps or not, but when we were working on l2tp-ktest
> initially we had tests for the bridge ioctl.  The tests bridged a PPPoE
> channel with a PPPoL2TP one (which was the original motivation for
> PPPIOCBRIDGECHAN).  The code is here:
> 
> https://github.com/katalix/l2tp-ktest/blob/master/src/util.c#L592
> 
> So in that codebase we have a pppoe fd and a pppol2tp fd, both of
> which have had been attached using PPPIOCATTCHAN.
> 
> We then bridge those two channels using PPPIOCBRIDGECHAN.
> 
> I think the bridging is a complex use-case for what is already quite
> an involved API (lots of file descriptors and indices to keep track
> of!).  So I think the code snippet needs to be as clear as we can make
> it.

Yes, I kept the simple l2tp-to-l2tp example, but mentioned that other
types of ppp channels can also be bridged.  The important part is that
the code snippets show exactly what kind of fd is expected where :)

Samuel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ