NG_PRED1(4)

👑 NG_PRED1 — the Predictor-1 PPP compression netgraph node type, bestie edition 💖

Okay so this is ng_pred1, a netgraph node type, and it lives in section 4 of the manual (kernel interfaces, the fun one). It does the Predictor-1 PPP compression thing. RFC 1978. Yeah. We're doing compression lore today. Sit down, hydrate, let's go. 🦋

---

✨ NAME ✨

ng_pred1 — Predictor-1 PPP compression (RFC 1978) netgraph node type

---

🌸 SYNOPSIS 🌸

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

---

💅 DESCRIPTION 💅

The pred1 node type implements the Predictor-1 sub-protocols of the Compression Control Protocol (CCP). That's the whole point of it. It compresses. It decompresses. It serves. 💁

The node has two hooks: comp for compression and decomp for decompression. And here's the vibe check: only one of them can be connected at the same time, and whichever one you pick is literally what specifies the node's operation mode. So you don't get both. Pick a lane, queen. 👑

Typically those hooks would be connected to the ng_ppp(4) node type hook of the same name — like, same-name-to-same-name, a lil hook handshake, iykyk. 🫶

---

🎀 HOOKS 🎀

This node type supports the following hooks:

• comp — Connection to ng_ppp(4) compress hook. Incoming frames are compressed and sent back out the same hook. Cute, right? Goes in, comes back out the same door, now smaller. ✨
• decomp — Connection to ng_ppp(4) decompress hook. Incoming frames are decompressed and sent back out the same hook. Same energy, opposite direction. 🦋

Only one hook can be connected at the same time, and it's the one specifying the node's operation mode. No cap.

---

⭐ CONTROL MESSAGES ⭐

This node type supports the generic control messages, plus the following:

• NGM_PRED1_CONFIG (config) — This command resets and configures the node for a session (i.e., for compression or decompression). It takes a struct ng_pred1_config as an argument:

struct ng_pred1_config {
        u_char          enable;                 /* node enabled */
};

The enable field enables traffic flow through the node. That's it, that's the whole field. One (1) u_char holding the entire fate of your traffic. Iconic.

• NGM_PRED1_RESETREQ (resetreq) — This message contains no arguments, and it is bi-directional. If an error is detected during decompression, this message is sent by the node to the originator of the NGM_PRED1_CONFIG message that initiated the session. The receiver should respond by sending a PPP CCP Reset-Request to the peer. Like a little "hey bestie we lost sync, resend" text. 😭

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. Fresh start, clean slate, new me. 🌈

• NGM_PRED1_GET_STATS (getstats) — This control message obtains statistics for a given hook. The stats come back in struct ng_pred1_stats:

struct ng_pred1_stats {
        uint64_t        FramesPlain;
        uint64_t        FramesComp;
        uint64_t        FramesUncomp;
        uint64_t        InOctets;
        uint64_t        OutOctets;
        uint64_t        Errors;
};

• NGM_PRED1_CLR_STATS (clrstats) — This control message clears statistics for a given hook. Bye data 👋
• NGM_PRED1_GETCLR_STATS (getclrstats) — This control message obtains and clears statistics for a given hook. Two birds, one control message. Efficiency is the moment. 💅

---

🦋 SHUTDOWN 🦋

This node shuts down upon receipt of a NGM_SHUTDOWN control message, or when hook have been disconnected. (Yes, "hook have been disconnected" — that's the original wording and we respect it, fr fr. 🫶)

---

🌈 SEE ALSO 🌈

• netgraph(4)
• ng_ppp(4)
• ngctl(8)
• D. Rand, PPP Predictor Compression Protocol, RFC 1978.
• W. Simpson, The Point-to-Point Protocol (PPP), RFC 1661.

---

💜 AUTHORS 💜

Alexander Motin <mav@alkar.net> — the main character who wrote this. 👑

---

💀 BUGS 💀

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 basically: lose a packet, and the fallout can be messier than the protocol ever promised. Not a vibe. Be aware. 🙈

---

And that's the whole page, bestie — brought to you by the Debian crew, dated December 24, 2006, from the Kernel Interfaces Manual, section 4. Go forth and compress responsibly. 💖✨🎀