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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 29 Apr 2019 11:58:56 +0200
From:   Thomas Jarosch <>
To:     Arnd Bergmann <>
Cc:     Karsten Keil <>,
        Networking <>,
        Tilman Schmidt <>,
        Paul Bolle <>,,,
        Al Viro <>,
        Holger Schurig <>
Subject: Re: [PATCH 5/5] isdn: move capi drivers to staging

Hi Arnd,

You wrote on Thu, Apr 25, 2019 at 01:24:09PM +0200:
> > > Right, this is what I'm trying to find out here. I realize that there
> > > are (very few) remaining users of ISDN voice services, but this only
> > > matters if someone uses them
> > >
> > > 1. with a modern Linux kernel, and planning to upgrade beyond linux-5.3
> > > 2. with a device driver that ships with the kernel
> > > 3. using the CAPI subsystem
> > >
> > > I suspect that all three of the above are true in isolation, but onless
> > > at least one person needs all three combined, that doesn't stop us
> > > from staging them out.
> >
> > 1. + 3. applies to us. The mISDN drivers are based on the kernel ones,
> > but maintained in an extra git tree on top of the kernel. The situation
> > is not ideal but that's what it currently is. git repo:
> >
> 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:

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/", 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/", O_RDONLY|O_CLOEXEC) = 5
open("/usr/lib/capi/", 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 library.
It's a plugin for the CAPI tools to directly talk to mISDNcapid.

I will do more thorough research next week if the CAPI userspace stuff runs with 
 the kernel CAPI layer disabled. It could be that the userspace tools like 
"capiinit" check for the presence of the kernel CAPI interface but don't really 
need it. We'll find out.

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.

Best regards,

Powered by blists - more mailing lists