[Bug 7556] ppp: sl_compress_init() will fail if called anything else than -1 or >MAX_STATE

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 08 Nov 2021 23:51:03 UTC

Ed Maste <emaste@freebsd.org> changed:

           What    |Removed                     |Added
                 CC|                            |emaste@freebsd.org

--- Comment #7 from Ed Maste <emaste@freebsd.org> ---
sppp(4) removed in:

commit 6aae3517ed2500fb963ba0a4264b4756088dd0f4
Author: Gleb Smirnoff <glebius@FreeBSD.org>
Date:   Wed Oct 20 21:08:13 2021 -0700

    Retire synchronous PPP kernel driver sppp(4).

    The last two drivers that required sppp are cp(4) and ce(4).

    These devices are still produced and can be purchased
    at Cronyx <http://cronyx.ru/hardware/wan.html>.

    Since Roman Kurakin <rik@FreeBSD.org> has quit them, they no
    longer support FreeBSD officially.  Later they have dropped
    support for Linux drivers to.  As of mid-2020 they don't even
    have a developer to maintain their Windows driver.  However,
    their support verbally told me that they could provide aid to
    a FreeBSD developer with documentaion in case if there appears
    a new customer for their devices.

    These drivers have a feature to not use sppp(4) and create an
    interface, but instead expose the device as netgraph(4) node.
    Then, you can attach ng_ppp(4) with help of ports/net/mpd5 on
    top of the node and get your synchronous PPP.  Alternatively
    you can attach ng_frame_relay(4) or ng_cisco(4) for HDLC.
    Actually, last time I used cp(4) back in 2004, using netgraph(4)
    instead of sppp(4) was already the right way to do.

    Thus, remove the sppp(4) related part of the drivers and enable
    by default the negraph(4) part.  Further maintenance of these
    drivers in the tree shouldn't be a big deal.

    While doing that, remove some cruft and enable cp(4) compilation
    on amd64.  The ce(4) for some unknown reason marks its internal
    DDK functions with __attribute__ fastcall, which most likely is
    safe to remove, but without hardware I'm not going to do that, so
    ce(4) remains i386-only.

    Reviewed by:            emaste, imp, donner
    Differential Revision:  https://reviews.freebsd.org/D32590
    See also:               https://reviews.freebsd.org/D23928

You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.