Stole My Own Pppoe Credentials Back From My Isps Router Using A Pi

Stole My Own Pppoe Credentials Back From My Isps Router Using A Pi

INTRODUCTION

When I first decided to replace the ISP‑provided router with a more flexible networking stack, I hit an unexpected roadblock: the PPPoE credentials that authenticating my internet connection were never exposed to me. The router was provisioned automatically via TR‑069, and the ISP’s support team refused to hand over the username and password. Without those credentials I could not re‑host the WAN interface on my own hardware, and the prospect of losing connectivity loomed large.

For homelab enthusiasts and self‑hosted infrastructure engineers, this scenario is all too familiar. Many ISPs lock down the WAN side of their equipment, handing out only a single Ethernet hand‑off to the customer premises equipment (CPE). Yet the underlying PPPoE session still requires a username and password that the provider injects at provisioning time. The challenge, therefore, is not just to obtain those secrets but to do so in a way that respects network boundaries, avoids service disruption, and stays within legal and ethical limits.

In this guide I walk through a complete, reproducible workflow for extracting PPPoE credentials from an ISP router using a Raspberry Pi. The approach combines a lightweight PPPoE server implementation, packet capture with tcpdump, and straightforward parsing of the captured frames. Readers will learn why this technique works, which tools are required, how to configure the Pi safely, and how to integrate the solution into a broader DevOps‑oriented homelab automation pipeline. By the end you will have a repeatable method that can be scripted, monitored, and version‑controlled alongside other infrastructure code.

The post is structured to cover:

• A concise technical primer on PPPoE, TR‑069 provisioning, and the relevant protocols.
• The exact prerequisites – hardware, OS, and software versions – needed to replicate the setup.
• Step‑by‑step installation and configuration commands with detailed explanations.
• Security hardening and performance optimization tips for production‑grade deployments.
• Common troubleshooting scenarios and how to resolve them.
• Links to authoritative external resources for deeper study.

All instructions assume a basic familiarity with Linux networking, container‑agnostic service management, and the principles of self‑hosted infrastructure. No marketing fluff or promotional content is included; the focus remains strictly on technical execution and practical guidance.

UNDERSTANDING THE TOPIC

What is PPPoE and why is it hidden?

Point‑to‑Point Protocol over Ethernet (PPPoE) is a network protocol that encapsulates PPP frames within Ethernet frames. ISPs commonly use PPPoE to deliver subscriber‑specific authentication (username/password) and accounting information over a shared Ethernet infrastructure. When a modem or router receives a PPPoE discovery request, it replies with a service name (often the ISP’s brand) and expects the client to respond with valid credentials before establishing the PPP session.

Many ISPs automate this process via the TR‑069 (CPE WAN Management) protocol. During provisioning, the CPE (the customer router) receives a configuration file that contains the PPPoE service name, encapsulation mode, and the authentication credentials. The ISP never reveals these values to the subscriber; they are stored internally and only exposed to the device’s management interface. Consequently, when you replace the ISP router, you lose the credentials that were never presented to you.

Historical context and ecosystem

PPPoE was standardized in RFC 2516 (1999) and quickly became the de‑facto method for broadband access. Early DSL modems often exposed the credentials via a web UI, but as ISPs moved toward fully managed CPE, the visibility diminished. Tools like pppoe-discover, tcpdump, and custom PPPoE servers have long been used by network engineers to troubleshoot or audit PPPoE sessions. More recently, open‑source projects such as pppoe-server (part of the pppoe package) and micropwn have enabled developers to spin up mock PPPoE endpoints for testing and research.

Key capabilities of the extraction workflow

• Passive capture – By placing a Raspberry Pi in the WAN path and listening for PPPoE discovery and session establishment packets, you can record the exact authentication exchange without interfering with the traffic.
• Active spoofing – A lightweight PPPoE server can be started on the Pi to accept the client’s PPPoE Active Discovery (PADI) request, forcing the ISP equipment to reveal its service name and credentials during the negotiation.
• Non‑intrusive – The approach does not require flashing the ISP router, modifying firmware, or sending any packets that could be detected by the provider’s monitoring systems.
• Scriptable – The entire process can be encapsulated in Bash or Python scripts, making it suitable for automation, CI/CD pipelines, or inclusion in infrastructure‑as‑code repositories.

Comparison with alternative methods

Method	Pros	Cons
Direct firmware dump	May expose credentials in clear text	Requires privileged access to router firmware; often not feasible on locked‑down devices
TR‑069 API interrogation	Can retrieve a full configuration set	Needs valid TR‑069 credentials or a management account; many ISP routers block external calls
Packet capture on existing router	No extra hardware needed	Limited to the router’s own capture capabilities; may miss early PADI/PADO exchanges
Dedicated PPPoE sniffer on a separate NIC	Simple, passive, works with any ISP router	Requires physical placement in the WAN path; may need additional cabling

The Raspberry Pi solution occupies a middle ground: it is passive enough to avoid detection, yet active enough to compel the ISP equipment to disclose its credentials during the PPPoE handshake. This makes it ideal for homelab environments where you control the entire network topology.

Real‑world applications

• Self‑hosted broadband replacement – Replace a locked‑down ISP router with a custom edge device while retaining the original authentication.
• Network research – Study how different ISPs implement PPPoE service names and authentication methods.
• Automation pipelines – Integrate credential extraction into a configuration management repo to provision new edge devices automatically.

Understanding these fundamentals equips you to move from curiosity to a concrete, repeatable implementation. The next sections detail the exact prerequisites, installation steps, and operational practices required to pull the credentials back from your ISP’s router using a Raspberry Pi.

PREREQUISITES

Hardware and network topology

1. Raspberry Pi – A Pi 4 Model B with at least 2 GB of RAM is recommended. The device must have an Ethernet port that can be connected directly to the ISP router’s WAN (or “Internet”) port.
2. Ethernet cable – Use a Category 5e or higher cable to ensure reliable link‑layer communication.
3. Power supply – A 5 V 3 A USB‑C adapter to keep the Pi stable under load.
4. Optional – A managed switch or a small Ethernet hub if you need to isolate the Pi’s traffic from other devices.

Software stack

Component	Minimum version	Reason
Raspberry Pi OS (64‑bit)	2023‑10‑10	Provides recent kernel with improved networking stack.
ppp	3.15.0	Implements the PPPoE client/server utilities.
pppoe	3.0.4	Supplies the pppoe command for discovery and server mode.
tcpdump	4.9.3	Captures raw Ethernet frames for later analysis.
tshark (optional)	4.2.0	Alternative to tcpdump for easier parsing of pcap files.
systemd	v247 (default on Raspberry Pi OS)	Manages the PPPoE server service.

Network and security considerations

• Isolation – Connect the Pi’s Ethernet interface to the ISP router’s WAN port and configure the Pi’s LAN side as a separate subnet (e.g., 10.0.0.1/24). This prevents accidental routing of traffic through the Pi and keeps the capture environment deterministic.
• Firewall rules – Disable any default firewall rules that might block inbound PPPoE traffic (protocol number 0x8863/0x8864). Use iptables to allow only the necessary PPPoE packets from the ISP side.
• Permission model – Capturing raw Ethernet frames requires root privileges. Run tcpdump and the PPPoE server under a dedicated service account with CAP_NET_RAW capabilities, or execute them via sudo.

Pre‑installation checklist

1. Verify that the Pi’s Ethernet interface is recognized (ip link).
2. Ensure the system clock is synchronized (timedatectl).
3. Confirm that the ISP router’s WAN port is set to “Bridge” or “Routing” mode; if it is in “NAT” mode, you may need to adjust the topology.
4. Reserve a static IP address for the Pi’s LAN interface (e.g., 10.0.0.1/24).
5. Document the physical port mapping (WAN ↔ Pi eth0