netdev - Re: [PATCH net-next v2 5/6] net/lapb: support netdev events

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Nov 2020 10:28:10 -0800
From:   Xie He <xie.he.0141@...il.com>
To:     Martin Schiller <ms@....tdt.de>
Cc:     Andrew Hendry <andrew.hendry@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux X25 <linux-x25@...r.kernel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 5/6] net/lapb: support netdev events

On Tue, Nov 17, 2020 at 5:26 AM Martin Schiller <ms@....tdt.de> wrote:
>
> On 2020-11-17 12:32, Xie He wrote:
> >
> > I think for a DCE, it doesn't need to initiate the L2
> > connection on device-up. It just needs to wait for a connection to
> > come. But L3 seems to be still instructing it to initiate the L2
> > connection. This seems to be a problem.
>
> The "ITU-T Recommendation X.25 (10/96) aka "Blue Book" [1] says under
> point 2.4.4.1:
> "Either the DTE or the DCE may initiate data link set-up."
>
> Experience shows that there are also DTEs that do not establish a
> connection themselves.
>
> That is also the reason why I've added this patch:
> https://patchwork.kernel.org/project/netdevbpf/patch/20201116135522.21791-7-ms@dev.tdt.de/

Yes, I understand that either the DTE or the DCE *may* initiate the L2
connection. This is also the way the current code (before this patch
set) works. But I see both the DTE and the DCE will try to initiate
the L2 connection after device-up, because according to your 1st
patch, L3 will always instruct L2 to do this on device-up. However,
looking at your 6th patch (in the link you gave), you seem to want the
DCE to wait for a while before initiating the connection by itself. So
I'm unclear which way you want to go. Making DCE initiate the L2
connection on device-up, or making DCE wait for a while before
initiating the L2 connection? I think the second way is more
reasonable.

> > It feels unclean to me that the L2 connection will sometimes be
> > initiated by L3 and sometimes by L2 itself. Can we make L2 connections
> > always be initiated by L2 itself? If L3 needs to do something after L2
> > links up, L2 will notify it anyway.
>
> My original goal was to change as little as possible of the original
> code. And in the original code the NETDEV_UP/NETDEV_DOWN events were/are
> handled in L3. But it is of course conceivable to shift this to L2.

I suggested moving L2 connection handling to L2 because I think having
both L2 and L3 to handle this makes the logic of the code too complex.
For example, after a device-up event, L3 will instruct L2 to initiate
the L2 connection. But L2 code has its own way of initiating
connections. For a DCE, L2 wants to wait a while before initiating the
connection. So currently L2 and L3 want to do things differently and
they are doing things at the same time.

> But you have to keep in mind that the X.25 L3 stack can also be used
> with tap interfaces (e.g. for XOT), where you do not have a L2 at all.

Can we treat XOT the same as LAPB? I think XOT should be considered a
L2 in this case. So maybe XOT can establish the TCP connection by
itself without being instructed by L3. I'm not sure if this is
feasible in practice but it'd be good if it is.

This also simplifies the L3 code.