Archive

OpenWrt pppd

Anfang 2026 begann ich mit Anthropic zu chatten, weil sich meine FRITZ!Box 7530 vermutlich bei einem Kaltstart und vermutlich schlechterer Retry-Logik als das originale FRITZ!OS erst nach einem erneuten Neustart einwählen würde.

Fehler die immer wieder auftauchten sind:

PADO (PPPoE Active Discovery Offer) timeouts (PADI/PADO/PADR/PADS)
Kein PPPoE IPv4 gateway wegen IPv6 neighbor discovery messages (ff:ff:ff:ff:ff:ff is a broadcast MAC)

/etc/config/network

In der Datei gibt es mehrere config device Blöcke mit zugehörigen option Definitionen. Inwiefern diese Einfluss nehmen können auf den pppoe Verbindungsaufbau bin ich mir bis heute nicht im Klaren.

Der nächste Block (config device) ist definiert vom option type bridge und gibt die Internetverbindung an die LAN Ports 2 bis 4 weiter (list ports lan#).

Ein config interface 'lan' wird als management Zugang eingestellt über option proto 'static' und option ipaddr '192.168.1.1' (option netmask '255.255.255.0').

Das config interface 'wan' ist auf jeden Fall wichtig für die Authentifizierung da diese von netifd gelesen werden:

option device 'lan1'
option proto 'pppoe'
option username 'N#11@kunden.sachsen-gigabit.de'
option password 'secret'
option ipv6 '0'
option keepalive '9 3'
option padi_attempts '5'
option padi_timeout '5'
option pppd_options 'noipv6 debug dump lcp-echo-interval 5 lcp-echo-failure 3'

Für mein Home Lab brauche ich zwingend IPV6 (wichtig wegen CGNAT und/oder Dual Stack Lite)

config interface 'wan6'
option device '@wan'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '56'
option norelease '1'
option release '0'

(letztere zwei sind wahrscheinlich exakt dasselbe)

/etc/ppp/options - IPV6 zunächst deaktivieren mit noipv6 (sollte das gleiche sein wie pppd_options noipv6 im interface wan.

Andere Grundeinstellungen wie

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd33:82d4:af6f::/48'
option packet_steering '1'

Andere Optionen bei denen ich unsicherer bin sind:

option ipv6 'auto'
option dhcpv6_pd '1'
option dhcpv6_strict '0'
option ip6assign '60'
option defaultroute '0'
option peerdns '0'
list dns <DNS Server des Internetanbieters>

um den Verbindungsaufbau / Authentifizierung besser manuell zu steuern.

Befehle in der SSH

Für die manuelle Steuerung (nach einem Neustart)

ifup wan (ifdown, ifstatus) um netifd anzustoßen und WAN-Ergebnis zu sehen.
pppoe-discovery -I "$IFACE" -D /tmp/pppoe-discovery.log, pppd call wan debug dump, pppdump -i ppp0 > /tmp/ppp-traffic.dump für das debugging in /var/log/messages
Verzeichnisse wie /etc/ppp/ip-up.d/ und /etc/ppp/ip-down.d/

Unbestätigt: Zum Beispiel kann es wichtig sein, dass der LAN1 Port (der als WAN fungieren soll) die richtige macaddr besitzt, wenn der Internetanbieter einen anderen Router bereitgestellt hat.

Claude (Anfang 2026):

IPv6 prefix delegation happens after the PPP link is up, during DHCPv6 negotiation
- wan6 uses DHCPv6, not PPPoE
- your ISP's PPPoE server doesn't properly handle IPv6CP negotiation even though it supports DHCPv6 prefix delegation.

The solution: Keep noipv6 in pppd options, but enable IPv6 differently. Connection/Retry related:

persist - Keep retrying after connection drops
holdoff N - Wait N seconds before retrying (default 30)
maxfail N - Stop after N failed attempts (you have maxfail 0 = infinite)
connect-delay N - Max time (ms) to wait after connect script finishes
idle N - Disconnect after N seconds of inactivity
demand - Dial on demand (you already have this disabled)

Debugging:

debug - Increase debugging ✓ (you have this)
kdebug N - Kernel driver debug level
logfile FILE - Log to file ✓ (you have this)
dump - Print option values after parsing
dryrun - Stop after parsing options (useful for testing)

LCP/Link control (relevant for timeouts):

lcp-echo-interval N - Seconds between keepalive pings (you use keepalive 9 3)
lcp-echo-failure N - Fail after N consecutive echo failures
lcp-restart N - Timeout between LCP retransmissions
lcp-max-configure N - Max LCP configure attempts
passive - Wait for LCP packets from peer instead of initiating

For PADO timeout specifically, try adding to /etc/ppp/options:

persist
holdoff 5
lcp-restart 3
lcp-max-configure 10

The FRITZ!Box has different PPPoE timing/behavior that works better

FRITZ!Box likely uses different defaults than pppd. The issue might be:

PADI packet timing - FRITZ!Box might space out discovery packets differently
MTU/frame size - Different settings on first PADI packet
Host-Uniq tag - FRITZ!Box might use specific values
Asyncmap/negotiation - Different initial LCP proposals

Try these in /etc/ppp/options to mimic FRITZ!Box behavior:

# More aggressive discovery
padi_attempts 10
padi_timeout 5

# Simpler LCP negotiation
default-asyncmap
default-mru
nomagic

# Less aggressive about features
noaccomp
nopcomp
nocrtscts

# Better retry behavior
holdoff 3
persist
lcp-restart 2

Also, try reducing MTU - add to /etc/ppp/options:

mtu 1492

(PPPoE overhead is 8 bytes, so 1492 instead of standard 1500)

Most importantly: when does the PADO timeout happen?

Your ISP has TWO servers (01 and 02), and pppd is receiving PADO responses from both. It's trying to connect to Server-01 which succeeds, but you're getting responses from both.

The real problem: Look at the end:

Script /lib/netifd/ppp-up finished (pid 3214), status = 0x1

Status 0x1 means the script exited with error code 1. That's why the connection fails after negotiation completes!

Check what /lib/netifd/ppp-up does: This script is responsible for setting up the interface after PPP negotiation succeeds. If it's failing, the connection gets torn down even though pppd negotiated everything correctly.

Can you show me the contents of /lib/netifd/ppp-up? That's likely where your real issue is.

Mehr komplexere Netzwerk Architektur, die ich noch nicht verstanden habe (könnten mehr Probleme verursachen als lösen):

Claude (Anfang 2026), ich begreife es selber nicht mehr:

In /etc/ppp/options

ipv6cp-use-ipaddr

Uses the IPv4 addresses negotiated in IPCP to derive IPv6 interface identifiers
Instead of negotiating separate IPv6 addresses, it converts your IPv4 address to IPv6 format
Example: IPv4 100.64.1.221 → IPv6 identifier based on that
Use when: ISP doesn't support full IPv6CP negotiation but will accept IPv6 traffic over the same link

holdoff 5

After pppd fails to connect, wait 5 seconds before retrying
Default is 30 seconds
Why you use it: Faster reconnection attempts without hammering the ISP

passive

pppd waits for the peer (ISP) to initiate LCP negotiation instead of sending first
Normally pppd sends LCP ConfReq immediately; passive waits to receive one first
Use when: ISP equipment is slow or requires peer-initiated negotiation
Can cause issues if ISP doesn't initiate, so use cautiously

In /etc/config/network (wan6 interface)

norelease '1'

Don't release the DHCPv6 lease when the interface goes down
Keeps the prefix even if wan6 temporarily disconnects
Benefit: Avoids losing your IPv6 prefix during brief reconnections

release '0'

Redundant with norelease '1' - they do the same thing
You only need one of these, not both

iapd_length '56'

Requests a /56 prefix delegation from DHCPv6
/56 means you get 256 /64 subnets for your LAN devices
Your ISP supports this (FRITZ!Box got it)
Standard for residential ISP DHCPv6-PD

dhcpv6_pd '1'

Explicitly enable DHCPv6 prefix delegation
Sometimes needed if OpenWrt defaults to address-only (not prefix)
Use when: You specifically want prefix delegation, not just a single address

dhcpv6_strict '0'

Less strict DHCPv6 validation
Allows DHCPv6 to work even if server doesn't follow RFC perfectly
Many ISPs have non-compliant DHCPv6 servers
Use when: ISP's DHCPv6 doesn't follow standards exactly

Recommended clean config for your wan6:

config interface 'wan6'
option device '@wan'
option proto 'dhcpv6'
option reqprefix '56'
option norelease '1'
option dhcpv6_pd '1'
option dhcpv6_strict '0'

Remove: option release '0' and option reqaddress 'try' (redundant/not needed for PD)

The real question: Does enabling any IPv6 negotiation in pppd (like ipv6cp-use-ipaddr) cause your timeouts, or only full IPv6CP?

Try testing with just that one option and see if it connects without timing out.

ISP is providing an IPv6 gateway for Router Advertisement (RA)**

Comes from the ISP's PPPoE server
Allows IPv6 communication immediately
Different from prefix delegation

Prefix delegation (what wan6 requests) = DHCPv6-PD

Gets you a delegated /56 prefix for your local network
Allows you to assign IPv6 to your LAN clients

Your ISP provides both, but pppd with noipv6 doesn't negotiate the RA part.

To get the IPv6 gateway without enabling IPv6CP:

Try adding this to /etc/ppp/options to be more selective about IPv6CP (instead of noipv6) - this enables IPv6CP but uses a simpler negotiation method.:

ipv6 fd00::1,fd00::2
ipv6cp-use-ipaddr

wan verbindet und deligiert wan6.

Erfolgreich aber irgendwie instabiel

Claude (Anfang 2026) vermutet: IPv6CP disabled at PPP level, but DHCPv6-PD working above it.

root@OpenWrt:~# ip link show pppoe-wan
12: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3
link/ppp

ifstatus wan6

{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 46,
"l3_device": "pppoe-wan",
"proto": "dhcpv6",
"device": "pppoe-wan",
"updated": [
"addresses",
"routes",
"prefixes",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [

],
"ipv6-address": [
{
"address": "2a00:fda0:287:5987:e1df:d019:253d:c364",
"mask": 64,
"preferred": 604751,
"valid": 2591951
}
],
"ipv6-prefix": [
{
"address": "2a00:fda0:2a2:4800::",
"mask": 56,
"preferred": 86354,
"valid": 86354,
"class": "wan6",
"assigned": {
"lan": {
"address": "2a00:fda0:2a2:4800::",
"mask": 60
}
}
}
],
"ipv6-prefix-assignment": [

],
"route": [
{
"target": "::",
"mask": 0,
"nexthop": "fe80::2cc:34ff:fee1:1ffd",
"metric": 512,
"valid": 1751,
"source": "2a00:fda0:2a2:4800::/56"
},
{
"target": "::",
"mask": 0,
"nexthop": "fe80::2cc:34ff:fee1:1ffd",
"metric": 512,
"valid": 1751,
"source": "2a00:fda0:287:5987:e1df:d019:253d:c364/64"
}
],
"dns-server": [
"2a00:fda0::1:53",
"2a02:2878:0:9::1337:53"
],
"dns-search": [

],
"neighbors": [

],
"inactive": {
"ipv4-address": [

],
"ipv6-address": [

],
"route": [

],
"dns-server": [

],
"dns-search": [

],
"neighbors": [

]
},
"data": {
"passthru": "001700202a00fda00000000000000000000100532a022878000000090000000013370053"
}
}

root@OpenWrt:~# ip -6 addr show br-lan
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet6 2a00:fda0:2a2:4800::1/60 scope global dynamic noprefixroute
valid_lft 86210sec preferred_lft 86210sec
inet6 fd33:82d4:af6f::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::1eed:6fff:fed6:a4cf/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
root@OpenWrt:~# ip -6 route show
default from 2a00:fda0:287:5987::/64 via fe80::2cc:34ff:fee1:1ffd dev pppoe-wan proto static metric 512 pref medium
default from 2a00:fda0:2a2:4800::/56 via fe80::2cc:34ff:fee1:1ffd dev pppoe-wan proto static metric 512 pref medium
unreachable 2a00:fda0:287:5987::/64 dev lo proto static metric 2147483647 pref medium
2a00:fda0:2a2:4800::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2a00:fda0:2a2:4800::/56 dev lo proto static metric 2147483647 pref medium
fd33:82d4:af6f::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd33:82d4:af6f::/48 dev lo proto static metric 2147483647 pref medium
fe80::2cc:34ff:fee1:1ffd dev pppoe-wan proto kernel metric 256 pref medium
fe80::e1df:d019:253d:c364 dev pppoe-wan proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev lan1 proto kernel metric 256 pref medium

Wireguard und DDNS

Claude (Anfang 2026):

Before (with CGNAT only):

Your devices were stuck behind ISP CGNAT
No way to reach them from internet without port forwarding (unreliable)
WireGuard was necessary to establish an outbound tunnel you could reverse-connect through
Value: Essential for connectivity

Now (with IPv6):

Your devices have public global IPv6 addresses
They're directly reachable from the internet
You can host services on them without WireGuard

But WireGuard still provides security value:

Network segmentation - Isolate your hosted service from your home network

WireGuard interface → Service only
Regular IPv6 → Rest of home network untouched

Encryption end-to-end - Even with public IPv6, traffic is encrypted

IPv6 alone doesn't encrypt; ISP can see all traffic
WireGuard encrypts everything passing through it

Access control - Only specific peers can connect

WireGuard firewall: only allow traffic from your VPN clients
Much more restrictive than just "open to IPv6 internet"

DDoS mitigation - Hide your real IP from attackers

Service sits behind WireGuard, not directly exposed
Attackers see VPN endpoint, not your home IP

Privacy from ISP - Traffic encrypted so ISP can't inspect it

They see you have WireGuard traffic, but not what service runs on it

Practical recommendation for home hosting:

Keep it simple:

Small hobby service? Use IPv6 directly, add local firewall rules
Semi-public service? WireGuard for encryption + access control
Privacy-critical? WireGuard for ISP visibility hiding

What would you be hosting? That determines if WireGuard is worth the complexity.

WireGuard vs dynamic DNS:

You're right that WireGuard eliminates the dynamic DNS problem, but for different reasons:

Method	Advantage
IPv6 Direct + Dynamic DNS	Simple, native IPv6, but need DDNS service if prefix changes
WireGuard	Static endpoint (your WireGuard server IP), clients always know where to connect

With WireGuard: Your WireGuard server gets a stable IPv6 (or IPv4), and that address is hardcoded in client configs. Even if the underlying network changes, WireGuard endpoint stays the same.

Recommendation:

Try hosting directly on IPv6 first (it's simpler)
Use the stable SLAAC address derived from MAC
If your ISP changes the /56 prefix (rare), then add dynamic DNS
Use WireGuard only if you want encryption/privacy and guaranteed connectivity through IP changes

Does your ISP documentation mention how often they re-delegate prefixes? That determines if you need DDNS at all.

ipv6-address (WAN6): valid: 2591745 seconds ≈ 30 days
ipv6-prefix (delegated): valid: 84712 seconds ≈ 23.5 hours
route (default): valid: 1545 seconds ≈ 25 minutes

What this means:

Your WAN6 address (public address on pppoe-wan) is valid for ~30 days

This is stable-ish but will eventually renew/change

Your delegated /56 prefix is valid for ~24 hours

Your ISP is re-negotiating this daily
The prefix itself might change at each renewal

The default route expires in ~25 minutes

Router advertisement, needs frequent refresh

This is the problem: Even though prefixes can be stable, your ISP renews them every 24 hours and could assign a different /56.

So yes, you might need dynamic DNS if:

The /56 prefix changes at renewal time
You're hosting long-lived services that clients need to find

Options:

Dynamic DNS + IPv6 - Monitor if prefix changes, update DNS
WireGuard - Endpoint stays constant regardless of prefix changes
Check ISP stability - Monitor for 1-2 weeks: does the /56 actually change at each renewal?

# Run daily to see if prefix changes
ip -6 addr show wan6

If the prefix stays the same across renewals, you don't need DDNS. If it changes, you need either DDNS or WireGuard.