netdev - Re: [PATCH 5/5] isdn: move capi drivers to staging

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]

Date:   Mon, 29 Apr 2019 13:57:13 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Thomas Jarosch <thomas.jarosch@...ra2net.com>
Cc:     Karsten Keil <isdn@...ux-pingi.de>,
        Networking <netdev@...r.kernel.org>,
        Tilman Schmidt <tilman@...p.cc>,
        Paul Bolle <pebolle@...cali.nl>,
        gigaset307x-common@...ts.sourceforge.net,
        isdn4linux@...tserv.isdn4linux.de,
        Al Viro <viro@...iv.linux.org.uk>,
        Holger Schurig <holgerschurig@...glemail.com>
Subject: Re: [PATCH 5/5] isdn: move capi drivers to staging

On Mon, Apr 29, 2019 at 11:59 AM Thomas Jarosch
<thomas.jarosch@...ra2net.com> wrote:
> You wrote on Thu, Apr 25, 2019 at 01:24:09PM +0200:
> > I'm still confused by this: You say here that you use the CAPI
> > subsystem from the mainline kernel (i.e. /dev/capi20 rather
> > than mISDNcapid), but this does not appear to interact at all with
> > mISDN, neither the in-kernel variant nor the one you link to.
>
> my working theory was that a userspace capi application
> talks to mISDNcapid via the kernel's CAPI layer as a proxy.
>
> Karsten's original announcement mentioned
> mISDN v2 CAPI support is userspace only:
> https://isdn4linux.listserv.isdn4linux.narkive.com/bRkOUkZG/announcement-misdn-fax-capi-2-0-support
>
>
> I did some preliminary research by removing the /dev/capi20 device node
> and checked if "capiinfo" still works via strace -> it does.
>
> # strace -e open,connect capiinfo
> open("/usr/lib/libcapi20.so.3", O_RDONLY|O_CLOEXEC) = 3
> open("/dev/shm/sem.CAPI20_shared_sem.v01000010", O_RDWR|O_NOFOLLOW) = 3
> open("/dev/shm/CAPI20_shared_memory.v01000010", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0666) = 3
> open("/usr/lib/capi/lib_capi_mod_misdn.so.2", O_RDONLY|O_CLOEXEC) = 5
> open("/usr/lib/capi/lib_capi_mod_std.so.2", O_RDONLY|O_CLOEXEC) = 5
> open("/root/.capi20rc", O_RDONLY)       = -1 ENOENT (No such file or directory)
> open("/etc/capi20.conf", O_RDONLY)      = 4
> open("/dev/capi20", O_RDWR)             = -1 ENOENT (No such file or directory)
> open("/dev/isdn/capi20", O_RDWR)        = -1 ENOENT (No such file or directory)
> connect(4, {sa_family=AF_UNIX, sun_path="/var/run/mISDNcapid/sock"}, 110) = 0
> Number of Controllers : 1
> connect(5, {sa_family=AF_UNIX, sun_path="/var/run/mISDNcapid/sock"}, 110) = 0
> Controller 1:
> Manufacturer: mISDN
> CAPI Version: 2.0
> Manufacturer Version: 0.1
> Serial Number: 0000001
> ..
>
> The trick is the lib_capi_mod_misdn.so library.
> It's a plugin for the CAPI tools to directly talk to mISDNcapid.

Ok, that's also what I guessed from taking a brief look at the
library: it just tries all possible backends to find hardware, which
will open /dev/capi20 if it exists, but it still continues without it.

> Intra2net officially supports AVM b1 and c4 cards for fax but we didn't
> encounter these cards for years in customer support and I'm also
> willing to officially cancel support for those.
>
> -> it's good to move the drivers to staging.

Ok, thanks a lot for researching this! Since you are currently moving
to 4.19 which still has CAPI, you also don't have to cancel support
for those quite yet, and we may also have yet another stable release
(5.3 or 5.4?) that you can upgrade to before it gets thrown out of
staging.

       Arnd