A working cable and a working Internet session are different milestones. PPP makes a point-to-point link usable through negotiation; PPPoE adds a way to establish that relationship over Ethernet. Find the last successful stage before changing settings.
Separate Ethernet discovery from PPP negotiation
PPP carries network-layer protocols between two peers. Its architecture separates encapsulation, Link Control Protocol (LCP), and Network Control Protocols (NCPs). RFC 1661's link phases place link establishment before optional negotiated authentication and network-layer configuration.
- 1. Underlying access is availableThe required physical and link service is ready. For PPPoE, verify the correct Ethernet access path and any provider-required VLAN.
- 2. PPPoE discovery finds a peerPADI seeks a service, PADO offers one, PADR requests the selected service, and PADS confirms the session. Successful discovery supplies the peer and session identifier.
- 3. LCP agrees on the PPP linkThe peers exchange configuration requests and responses. Repeated negotiation or termination points to a different problem from a completed link.
- 4. Authentication runs if negotiatedThe configured method checks the peer's identity. Failure here can involve credentials, account state, method compatibility, or the provider's authentication system.
- 5. Each network protocol is configuredIPCP handles IPv4 options; IPv6CP handles IPv6 link options. Each protocol has its own state.
- 6. Routing, name resolution, and applications are checkedA session can be established while a route, resolver, firewall policy, or remote service still prevents the intended task.
The discovery exchange is specific to PPPoE, described in RFC 2516. A serial PPP connection starts from its own underlying link and skips PPPoE discovery. Likewise, a provider using a different access arrangement may have no PPP session at all.
For IPv6, an IPv6CP success does not by itself establish that a home router received a delegated LAN prefix. RFC 5072 specifies IPv6 over PPP and interface-identifier negotiation; routed-prefix provisioning must be checked separately in the provider's supported arrangement.
Read a failed connection as a sequence
| Observation | Investigate next | What remains uncertain |
|---|---|---|
| No discovery offer | Access link, required VLAN, bridge mode, service selection, and provider availability | The observation alone cannot identify which part dropped the exchange. |
| LCP repeatedly negotiates or closes | Both peers' requested options and termination reasons | A physical link indication says little about agreement on PPP options. |
| Authentication rejected | Method, account format, provisioning, and server response | A rejection can have causes beyond a mistyped password. |
| IPv4 works; IPv6 fails | IPv6CP, addressing, prefix delegation where used, routes, and filtering | Success for one network protocol leaves the other untested. |
| Session stays up; some transfers stall | Packet sizes, loss, path-MTU feedback, application behavior, and intervening tunnels | This symptom suggests several possibilities; it does not prove an MTU fault. |
Understand the 1492-byte example
MTU is the maximum IP packet size an interface can send in this context; MRU describes the peer's receive limit for PPP's information field. They are related directional limits. Record negotiated values as well as configured ones.
RFC 4638 defines support for negotiating larger PPPoE payloads when the endpoints and Ethernet path can carry them. Check that support across the relevant path before selecting a larger value. Additional tunnels may impose further limits.
For troubleshooting, compare small and larger transfers to the same approved destination and inspect the path's packet-too-big or fragmentation-needed feedback with appropriate tools. Record IP version and all tunnel layers. TCP MSS adjustment affects TCP; it is not a general solution for every UDP-based application. Use the provider's supported configuration and a rollback plan for changes.
Keep identity checks and encryption separate
Authentication is a negotiated PPP function. PAP conveys a password in the exchange; CHAP uses a challenge-response mechanism. The PAP specification and CHAP specification explain their scope and limitations. Match the provider's supported method and protect stored credentials and management access.
A completed identity check does not encrypt the application traffic carried by PPP. Use the application's appropriate protection, such as HTTPS, and the organization's required network security. Treat logs and packet captures as potentially sensitive records.
Keep a record that another person can use
- Device model, software release, access type, and the time and frequency of failures.
- Whether the physical link, discovery, LCP, authentication, IPCP, and IPv6CP completed.
- Expected service/VLAN, assigned addresses, routes, and prefix-delegation status where applicable.
- Configured and negotiated MTU/MRU, tunnel details, and a reproducible application symptom.
- One change at a time, its observed result, and the known-good configuration to restore.
PPP grew from the need to operate dial-up and serial links predictably and later supplied a subscriber-session model for broadband. Its lasting lesson is the value of separately observable stages. SLIP's smaller framing mechanism makes the contrast particularly clear.