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:   Wed, 24 Apr 2019 15:06:25 +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,

> Ok, interesting. My understanding was that mISDN CAPI support
> was done purely in user space, on top of the mISDN interface.
> I don't see any interfaction between the two in the kernel code,
> but if the capi module is required for mISDN, we clearly have to
> keep it. We could still move the avm/gigaset/hysdn/cmtp drivers
> to staging though, if there are no users for those.

AVM Fritz!PCI cards are supported by the mISDN subsystem anyway,
the new driver is "avmfritz" and used by us in production.

> 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:

> That leaves the question of whether there is anyone rolling their
> own routers and/or fax machines based on future kernels with the
> avm/gigaset/hysdn/cmtp CAPI drivers, and which drivers in particular
> that would be.

I would guess that isdn4linux is mostly dead and the drivers
can be moved to staging. I didn't encounter cmtp (ISDN over Bluetooth)
in real life yet.

Intra2net uses mISDN v2 only and software fax support in mISDNcapid was 
developed because of us, so I guess we are the main user, too.

[funny side note: I use a 4 port Eicon diva card at home for my SIP
-> ISDN gateway. The eicon driver just got removed, too, but it still works
fine on Centos 7.x 3.10 kernels. Though this is an exotic use case and I would not
NAK the removal of the driver since the kernel maintenance costs
don't justify it. If it stops getting supported, I'll either set up
something based on mISDNv2 + LCR or get a used Fritz!Box for this task.]

> > Intra2net is currently in the process of upgrading to kernel 4.19.x
> > and Karsten recently did all the necessary adaptions for mISDN.
> > So the ISDN code is used with modern (LTS) kernels ^^
> Ok. If you are on 4.19 (or moving to that now), I would assume that
> you probably upgrade to a future kernel later. Even if you don't
> plan to, it's the safe bet.

Correct. Intra2net usually moves to LTS kernels and skips a few versions since 
the migration work takes a few months to verify everything still works. We have 
an "avocado"[1] automated test framework for the whole distribution but there's 
always some userspace API compatibility issue, a small patch needed here or a 
crash there. For example my colleague tries to figure out right now why the 
Microsoft Hyper-V network driver hangs on module load with kernel 4.19.35
while downgrading to the previous kernel works instantly.
Sounds like git bisect "fun" for her...


Best regards,
Thomas Jarosch

Powered by blists - more mailing lists