netdev - need to identify sl# interface used by a particular instance of slattach (not subscribed to LKML)

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>] [day] [month] [year] [list]

Message-ID: <CAK4PFCVewY-n0Z=q8NeQCaV+p1PWL9-eQg+j5+7RD3mtks+rNA@mail.gmail.com>
Date:   Tue, 18 Feb 2020 14:22:19 -0500
From:   Kent Dorfman <kent.dorfman766@...il.com>
To:     netdev@...r.kernel.org
Subject: need to identify sl# interface used by a particular instance of
 slattach (not subscribed to LKML)

Hey gents.

As is usually the case, engineering decisions were made before I came
on-board, and now I'm stuck dealing with plans that I had no input
into.

Anyway, company advertised to external customers that they could
connect their widgets to our system using plain ole uncompressed SLIP
over RS422 serial (four wire, no flow control, 115200bps)

Problem, as you may have guessed, is that since the lines are
statically allocated I need to be able to assign static IPs based on
the tty port they are using.  I haven't used a SLIP dialup since
mid-90s and from what I remember, the sl# link is dynamically
allocated based on the "next available" when the slattach command
handshakes with the other end.  This leaves me without knowing what
sl# interface to assign the IP number to.  The common use case was
always a single sl link over a dialup line, not 16+ different
statically allocated slip connections on a single server (with no end
user authentication to define the IP on a per-port basis)

What is my work-around?  How can I know which sl interface to
configure based on a particular tty serial link?

I'm not a LKML subscriber, so please CC me directly.