netdev - Re: [PATCH 0/4] ISDN patches for net-next

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

Message-ID: <537A7965.9070407@imap.cc>
Date:	Mon, 19 May 2014 23:36:37 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, pebolle@...cali.nl,
	isdn4linux@...tserv.isdn4linux.de, isdn@...ux-pingi.de
Subject: Re: [PATCH 0/4] ISDN patches for net-next

David,

thanks for your reply. I understand your concerns but I don't agree
with them and hope I'll be able to convince you otherwise.

On 19.05.2014 03:36, you wrote:
> Since this has been broken for several years, you might be doing more
> harm than good by trying to change things back again.

You appear to assume that there is a currently working configuration
which might be broken by the patch series. That is not the case.
The (very few) remaining users of PPP over ISDN cope with the
current situation in one of these ways:

a) staying with a pre-3.0 kernel that still provides capifs

b) staying with (or reverting to) the deprecated ISDN4Linux subsystem

c) patching the kernel locally to fix the breakage

d) staying with an old udev version that can still rename device nodes

e) explicitly running commands like
    mv /dev/capi /dev/capi20
    mkdir /dev/capi
    ln -s /dev/capi0 /dev/capi/0
    ln -s /dev/capi1 /dev/capi/1
   on every boot, typically via /etc/boot.local or similar mechanisms.

f) giving up on Linux ISDN support and buying a separate router.

None of these will be broken by fixing the problem in the kernel:

- a), b) and f) won't notice anything unless they read the changelog
  and find they can at last use ISDN over CAPI with a current kernel
  again if they want to.

- c) will notice that the local kernel patch doesn't apply anymore
  and happily drop it.

- d) and e) may or may not notice that renaming the CAPI nodes fails
  because the nodes are already named correctly, but apart from a
  couple of log messages everything will work as before.

> Why not just have capiplugin able to search for and use the names
> generated now?

For one, capiplugin is a pretty old piece of software. The risk of
breaking it in the attempt to adapt it to the Kernel CAPI interface
change is far bigger than the risk associated with reverting that
change in the kernel. What's more, capiplugin is not the only
software affected. /dev/capi20 is the documented standard device
for CAPI 2.0 on Linux. Userspace relies on that. We would have to
adapt at least libcapi20 too, and possibly an unknown number of
other applications.

In sum, I'm convinced the proposed patch series is the minimally
invasive way of sorting out the current mess surrounding the
CAPI device files.

Regards,
Tilman
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html