NG_DEFLATE(4)

📦 version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

💅 ng_deflate — bestie's guide to Deflate PPP compression

okay so real talk: this page is from the Kernel Interfaces Manual, and the thing it's describing is ng_deflate(4) — the netgraph node type that does Deflate PPP compression (RFC 1979). yes it's a whole mouthful. no i will not be shortening it. 🎀

✨ NAME ✨

ng_deflate — the Deflate PPP compression (RFC 1979) netgraph node type. that's the whole name. slay. 👑

🦋 SYNOPSIS 🦋

#include <sys/types.h>
#include <netgraph/ng_deflate.h>

that's it, that's the vibe check. two includes and you're in. ✨

💖 DESCRIPTION 💖

okay so the deflate node type implements the Deflate sub-protocols of the Compression Control Protocol (CCP). that's the main character energy right there.

the node has two hooks: comp for compression and decomp for decompression. only one of them can be connected at the same time — and whichever one is connected is literally what specifies the node's operation mode. 🔥

typically those hooks get connected to the ng_ppp(4) node type hook of the same name — like, comp to comp, decomp to decomp, iykyk. and heads up: the corresponding ng_ppp(4) node hook must be switched to NG_PPP_DECOMPRESS_FULL mode to permit sending uncompressed frames. don't skip that step bestie, it's giving important. ⭐

🌸 HOOKS 🌸

this node type supports the following hooks, and honestly? there are only two and they're both iconic:

  • comp — connection to the ng_ppp(4) comp hook. incoming frames are compressed (if possible) and sent right back out the same hook. cute, right? 💜
  • decomp — connection to the ng_ppp(4) decomp hook. incoming frames are decompressed (if they are compressed), and sent back out the same hook.

and again, for the people in the back: only one hook can be connected at the same time, and that's what specifies the node's operation mode. periodt. 💅

🎀 CONTROL MESSAGES 🎀

this node type supports the generic control messages, plus these iconic ones:

  • NGM_DEFLATE_CONFIG (config) — this command resets and configures the node for a session (i.e., for compression or decompression). it takes a struct ng_deflate_config as an argument:
struct ng_deflate_config {
        u_char  enable;                 /* node enabled */
        u_char  windowBits;             /* log2(Window size) */
};

the enabled field enables traffic flow through the node ✨ and the windowBits specify compression windows size as negotiated by the Compression Control Protocol (CCP) in PPP. no cap.

  • NGM_DEFLATE_RESETREQ (resetreq) — this message contains no arguments, and it's bi-directional. if an error is detected during decompression, this message is sent by the node to the originator of the NGM_DEFLATE_CONFIG message that initiated the session. the receiver should respond by sending a PPP CCP Reset-Request to the peer. 🫶

this message may also be received by this node type when a CCP Reset-Request or Reset-Ack is received by the local PPP entity. the node will respond by flushing its compression state so the sides can resynchronize. it's giving teamwork honestly. 🌈

  • NGM_DEFLATE_GET_STATS (getstats) — this control message obtains statistics for a given hook. the stats come back in struct ng_deflate_stats:
struct ng_deflate_stats {
        uint64_t        FramesPlain;
        uint64_t        FramesComp;
        uint64_t        FramesUncomp;
        uint64_t        InOctets;
        uint64_t        OutOctets;
        uint64_t        Errors;
};
  • NGM_DEFLATE_CLR_STATS (clrstats) — this control message clears statistics for a given hook. bye bye numbers 🧹
  • NGM_DEFLATE_GETCLR_STATS (getclrstats) — this control message obtains and clears statistics for a given hook. multitasking queen behavior. 👑

⭐ SHUTDOWN ⭐

this node shuts down upon receipt of a NGM_SHUTDOWN control message, or when hook have been disconnected. that's it. that's the exit. 💀

🔥 SEE ALSO 🔥

go read them. i'll wait. 🙈

🌈 AUTHORS 🌈

Alexander Motin <mav@alkar.net> — the legend who wrote this. show some respect. 👑

💀 BUGS 💀

ngl there's a real one, so listen up: due to nature of netgraph PPP implementation there are possible race conditions between data packet and ResetAck CCP packet in case of packet loss. as result, packet loss can produce bigger performance degradation than supposed by protocol. 😭

so yeah — lose a packet and the perf hit might be bigger than the protocol was ever supposed to give you. that's not a vibe, that's just the truth.

and that's the whole page bestie!! this one's from the Debian build, dated December 23, 2006 — old enough to be a vintage, still out here compressing packets with main character energy. go forth and deflate responsibly 🫶💖✨

📦 where this page comes from