Before pppd can dial out over PPPoE, pppoe-discovery answers the one question that matters: which access concentrator is even listening. It asks without starting a PPP session. The examples match pppoe-discovery from ppp 2.4.9, installed here as package version 2.4.9-1+1.1ubuntu4.
Fifteen minutes. You need the ppp package, an Ethernet interface connected to the PPPoE network, and permission to send raw discovery packets. Discovery does not touch PPP configuration, but it does put packets on the wire, so do not run it across a link you are not authorised to test.
Start with the local binary. These are ordinary, read-only commands that need no elevated privileges:
$ command -v pppoe-discovery
/usr/sbin/pppoe-discovery
$ dpkg-query -W -f='${Package} ${Version}\n' ppp
ppp 2.4.9-1+1.1ubuntu4
$ pppoe-discovery -V
pppoe-discovery from pppd 2.4.9
The installed help lists eth0 as the default interface, and that default trips people up constantly: a modern host's real uplink is usually called something else entirely. Check the available links before sending anything:
$ ip -br link
LOOPBACK UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0 UP 00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP>
Use whichever interface is physically connected to the PPPoE service. The sample address and names above are illustrative; copy your own interface name, not enp3s0 out of habit.
The manual expects the selected interface to be up and carrying no IP address of its own. Inspect it without changing anything:
$ ip link show dev enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
$ ip address show dev enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
The two things that matter are UP in the link flags and no inet or inet6 address on that interface. Do not strip an address off a live interface just to satisfy this check: that interrupts traffic and can disconnect you outright. Arrange a maintenance window or grab an unused, connected Ethernet interface instead.
Checkpoint: write down the exact interface name. If it is down, fix that through your normal network-management procedure and verify the result with ip link show. Enabling a link can affect connectivity, so it normally wants elevated privileges and a rollback plan.
Run it with an explicit interface. Sending raw packets usually wants elevated privileges, so reach for sudo only if the plain attempt gets denied:
$ sudo pppoe-discovery -I enp3s0
<access concentrator names printed here, if any>
Each responding access concentrator gets printed from a PADO response. Names and exact output are network-specific, so treat the placeholder above as exactly that: a placeholder. This program never starts a PPP session; by default it fires three PADI attempts, each with a five-second discovery timeout.
A successful discovery only tells you a concentrator answered. It does not authenticate you, assign an address, or promise that a later PPP login will actually succeed. If you only needed to identify a service, stop right here.
If the command exits with no concentrator listed, check the basics before you start reaching for filters:
$ sudo pppoe-discovery -I enp3s0
$ printf 'exit status: %s\n' "$?"
exit status: <status returned by the installed command>
An empty display is not automatically success. -Q deliberately suppresses discovered names, so leave it off while you are investigating; it is meant for scripts that read the exit status instead of eyeballing output.
Check the cable, link state, VLAN path, and interface choice. Confirm nothing is managing the interface in a way that adds an address or changes its state behind your back. On a slow path, give it more time and keep the attempt count explicit:
$ sudo pppoe-discovery -I enp3s0 -t 10 -a 5
That only changes wait and retry behaviour for this one invocation. It will not repair a disconnected circuit or bully a service into answering discovery.
Start without -S or -C for most installations. Add a service-name filter only when the provider actually gave you an exact name, or several services are present at once:
$ sudo pppoe-discovery -I enp3s0 -S broadband
Access-Concentrator: isp-concentrator
Service-Name: broadband
Use -C for an exact access concentrator name. Give both filters and both must match:
$ sudo pppoe-discovery -I enp3s0 -S broadband -C isp-concentrator
A filter can turn a perfectly visible response into no output at all. Drop the filters and try once more before deciding the provider is unreachable, and never guess a service or concentrator name from a vague label in an old configuration file.
Discovery packets interfere when several pppoe-discovery or pppd instances share the same path. Running instances at the same time on purpose? Give each one a Host-Uniq value. The -U form derives it from the process ID:
$ sudo pppoe-discovery -I enp3s0 -U
Alternatively, provide an explicit hexadecimal value with -W:
$ sudo pppoe-discovery -I enp3s0 -W 70616e656c2d31
Pick one form, not both: -U and -W are mutually exclusive, and every instance meant to coexist needs the same choice. For a one-off test, skip both options and just avoid running a competing PPPoE discovery at the same time.
-D writes every packet to the file you name, for debugging. Packet captures expose network metadata, so pick a protected temporary location and remove the file once you have reviewed it:
$ umask 077
$ sudo pppoe-discovery -I enp3s0 -D /tmp/pppoe-discovery-debug.log
$ sudo ls -l /tmp/pppoe-discovery-debug.log
$ sudo rm -- /tmp/pppoe-discovery-debug.log
Warning: that final command is destructive. Do not run it until you have finished examining the capture, and never store the file in a shared directory. Retaining it means moving it into your approved diagnostic store with access controls, not leaving it in /tmp.