Point-to-Point Protocol (PPP) is a data link layer protocol (RFC 1661) that frames and negotiates link-layer encapsulation over a serial link between exactly two endpoints. It provides encapsulation, link configuration via the Link Control Protocol (LCP), and optional authentication and upper-layer protocol negotiation via protocols such as IPCP for IP.
In practice
PPP appears in embedded systems wherever a device needs to carry IP (or another network layer protocol) over a byte-oriented serial link -- for example, a cellular modem (UART or USB CDC-ACM), a dial-up modem, or a direct RS-232 tether. On cellular-connected devices, the host MCU or MPU often sends AT commands to establish a data call and then transitions the serial port into PPP mode, after which the modem and the mobile network exchange LCP and IPCP frames to assign an IP address and bring up the data path.
Framing is handled by HDLC-like byte stuffing: a 0x7E flag byte marks frame boundaries, and any 0x7E or 0x7D byte inside the payload is escaped with 0x7D followed by the byte XORed with 0x20. This stuffing is transparent to the application but matters when sizing buffers and estimating worst-case throughput -- a payload that is entirely 0x7E bytes will nearly double in wire size after escaping.
PPP includes a CRC check on every frame. The default is a 16-bit FCS using reflected (LSB-first) CRC parameters derived from the HDLC standard, though a 32-bit FCS can be negotiated. The bit-ordering and pre/post-conditioning used by PPP can be a source of subtle bugs when implementing or porting a CRC routine; the EmbeddedRelated post "The CRC Wild Goose Chase: PPP Does What?!?!?!" documents this class of problem in detail.
On resource-constrained targets, a full PPP stack (including LCP state machine, IPCP, PAP/CHAP authentication, and retransmission timers) adds meaningful code size -- commonly 10--40 KB of flash depending on the implementation. Lightweight stacks such as lwIP's PPP module are common choices for bare-metal or RTOS environments; pppd is widely used on Linux-capable platforms. On very small MCUs (8-bit class), PPP is sometimes replaced by SLIP, which has simpler framing but no negotiation or error detection.
Frequently asked
Why does my PPP connection fail silently right after LCP negotiates successfully?
The most common cause is a failure in the next negotiation phase -- usually IPCP (for IP address/DNS assignment) or authentication (PAP or CHAP). Enable verbose logging on both ends to see which protocol is rejecting options and why. Mismatched authentication credentials, an unsupported option (e.g., header compression the peer insists on), or a timer expiry before the modem responds are frequent culprits.
What is the difference between PPP and SLIP?
SLIP (Serial Line Internet Protocol, RFC 1055) is a much simpler framing scheme -- it only delimits IP packets with a special byte and has no negotiation, authentication, error detection, or support for protocols other than IP. PPP is generally preferred over SLIP for most purposes, but SLIP remains useful on extremely memory-constrained targets where PPP overhead is not acceptable.
Why does PPP CRC calculation often produce unexpected results when ported to a new platform?
PPP uses
CRC-16-CCITT with reflected (LSB-first) bit ordering, an initial value of 0xFFFF, and a final XOR of 0xFFFF. Many generic CRC-16 library implementations use different parameters. Swapping any of these silently produces a different
checksum that passes on one end and fails on the other. The EmbeddedRelated post 'The CRC Wild Goose Chase: PPP Does What?!?!?!' covers this exact failure mode in detail.
Can PPP run directly over USB instead of a UART?
Yes. Many cellular modems and embedded LTE/3G modules expose a CDC-ACM (virtual
COM port) or a CDC-ECM/NCM interface over
USB. When using CDC-ACM, the host-side software treats the interface as a serial port and runs a normal PPP
stack over it. Some modules bypass PPP entirely by presenting a CDC-ECM or RNDIS
Ethernet interface, which is simpler to integrate but requires an Ethernet/IP stack rather than a PPP stack.
What is PPPoE and does it appear in embedded systems?
PPP over
Ethernet (PPPoE, RFC 2516) encapsulates PPP frames inside Ethernet frames and is commonly used by DSL broadband modems. It does appear in embedded Linux systems (routers, industrial gateways) that manage a DSL or fiber WAN connection. Bare-metal
MCU-class devices rarely implement PPPoE directly; it is more typical on application-processor platforms running Linux with pppd.
Differentiators vs similar concepts
PPP is often compared to SLIP, which is an earlier and much simpler serial IP-framing scheme with no link negotiation, no authentication, and no built-in error detection. PPP is also confused with PPPoE (PPP over
Ethernet), which wraps PPP inside Ethernet frames for DSL-style broadband links rather than raw serial. On cellular modems, PPP mode is sometimes contrasted with direct-IP or CMUX modes, where the modem exposes an IP interface or multiplexed channels without requiring the host to run a PPP
stack.
