> On 23 May 2020, at 13:11, Sergey Ryazanov <ryazanov....@gmail.com> wrote:
>
> Hello,
>
> On Wed, May 20, 2020 at 10:13 PM Vitaliy Makkoveev
> <henscheltig...@yahoo.com> wrote:
>> On Wed, May 20, 2020 at 04:08:01AM +0300, Sergey Ryazanov wrote:
>>> On Tue, May 19, 2020 at 12:11 PM Vitaliy Makkoveev
>>> <henscheltig...@yahoo.com> wrote:
>>>> On Mon, May 04, 2020 at 10:03:40PM +0300, Sergey Ryazanov wrote:
>>>>> Split checks from frame accepting with header removing in the common
>>>>> PPP input function. This should fix packet capture on a PPP interfaces.
>>>>
>>>> Can you describe the problem you fix? As mpi@ pointed to me, reviewers
>>>> are stupid and have no telepathy skills :)
>>>
>>> When I tried to capture packets on a ppp (4) interface (with pipex
>>> activated), I noticed that all the PPP CCP frames were ok, but all the
>>> ingress PPP IP frames were mangled, and they did not contain the PPP
>>> header at all.
>>
>> This time only pppx(4) and pppac(4) have pipex(4) support.
>
> Yes, and as I wrote in the first mail, now I am working on ppp(4) &
> pipex(4) integration to speed up client side of L2TP.
May be you can share you work? Not for commit, but for feedback.
For example, each pipex session should have unique pair of `protocol’ and
`session_id’. These values are passed from userland. While the only
instance of npppd(8) uses pipex(4) this is not the problem. But you
introduce the case while pipex(4) will be used by multiple independent
userland programs. At least, I have interest how you handle this.
>
>> I don't see
>> packet capture problems on them. Can you catch and share how to
>> reproduce this problem with pppx(4) or pppac(4)?
>>
>> Also did you test your diff with pppx(4) and pppac(4)?
>
> I am entirely missed the fact that pppx(4) also have IFT_PPP type.
> Thank you for pointing me.
>
> I will recheck pppx(4) work and return as soon as I will have a better
> solution.
Not only. Since you modify pipex(4) you should check pppac(4) too.
