Raspbian über PPPOECONF IPv6 Probleme

[SirNibo]

Hallo,

ich teste zurzeit einen Raspberry PI 3 (soll durch einen RPI4 ersetz werden) mit Raspbian als Dulastack Router mit PPPOECONF hinter einem Vigor 130 Draytek Modem im Modem Modus.

Das ganze ist folgendermaßen aufgebaut.
Modem <- RPI-eth0 -- RPI_wlan0 -> Clients. Ist wie gesgat nur ein Testaufbau. Das Wlan dafür nicht das wahre ist, ist mir klar.

Der Pi verbindet sich auch über PPPOE. Bekommt eine öffenltiche IPv4 Adresse und öffentlichen IPv6 Prefix.
Das internet und Routing funktioniert problemlos über IPv4. Alle Clients kommen über ihn auch ins Internet.
Über IPv6 kann der PI nichts erreichen.
Solange der PI selber nichts über IPv6 erreichen kann, brauche ich mich ums Routing erstmal keine gedanken zu machen machen.
Hat damit jemand hier Erfahrung?

Code: Alles auswählen

PING google.de(fra24s11-in-x03.1e100.net (2a00:1450:4001:830::2003)) 56 data bytes
From dynamic-2a01-0c22-c200-4b16-80bd-c289-b240-494a.c22.pool.telefonica.de (2a01:xxx:xxxx:xxxx:xxxx:xxxxx:xxxxx:494a) icmp_seq=1 Destination unreachable: No route

ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp
    inet xx.xx.xx.xxx peer xx.xx.xxx.xxx/32 scope global ppp0
       valid_lft forever preferred_lft forever
    inet6 2a01:xxx:xxxx:xxxx:xxxx:xxxxx:xxxxx:494a/64 scope global dynamic mngtmpaddr
       valid_lft 259148sec preferred_lft 172748sec
    inet6 fe80::80bd:c289:b240:494a peer fe80::da49:bff:feb7:37c4/128 scope link
       valid_lft forever preferred_lft forever

::1 dev lo proto kernel metric 256 pref medium
2a01:xxx:xxxx:xxxx::/64 dev ppp0 proto kernel metric 256 expires 259125sec pref medium
fe80::80bd:c289:b240:494a dev ppp0 proto kernel metric 256 pref medium
fe80::da49:bff:feb7:37c4 dev ppp0 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default dev lo proto ra metric 1024 pref medium
default via fe80::da49:bff:feb7:37c4 dev ppp0 proto ra metric 1024 expires 1725sec pref medium

[bluestar]

Hallo,
Hat damit jemand hier Erfahrung?

Ja.

Was ich gerade als erstes sehe ist eine fehlerhafte Route:

Code: Alles auswählen

default dev lo proto ra metric 1024 pref medium

Wo die Route herkommt, dazu hab ich keine Ahnung.

Wenn du später ein Subnetz für deine Clients nutzen willst, dann brauchst du - bei Telekom-Anschlüssen - noch einen wide-dhcpd um das Prefix für's LAN anzufordern.

[cosinus]

Was ich gerade als erstes sehe ist eine fehlerhafte Route:

Ist für IPv6 nicht das hier der relevante Eintrag?

Code: Alles auswählen

default via fe80::da49:bff:feb7:37c4 dev ppp0 proto ra metric 1024 expires 1725sec pref medium

Da hier ja kein Router im Spiel ist, müsste da nicht als als IP auch irgendwas mit 2a01: auftauchen statt fe80?

[bluestar]

Ist für IPv6 nicht das hier der relevante Eintrag?

Code: Alles auswählen

default via fe80::da49:bff:feb7:37c4 dev ppp0 proto ra metric 1024 expires 1725sec pref medium

Ja das ist der richtige Eintrag und nein, es ist für gewöhnlich üblich das man den Router auf fe80:: findet, z.B. in meinem LAN hab ich auch meinem Router fe80::1 als Gateway eingerichtet.

Die fe80:: sind Link-Local Adressen und genau dafür prädestiniert.

[cosinus]

Die fe80:: sind Link-Local Adressen und genau dafür prädestiniert.

Ja, das weiß ichm, aber seine Testverbindung geht doch nicht über seinen Router?

[bluestar]

Ja, das weiß ichm, aber seine Testverbindung geht doch nicht über seinen Router?

Stimmt und ich habe dir gesagt, dass du eine fehlerhafte Route am Start hast. Die müsstest du mal loswerden:

Was ich gerade als erstes sehe ist eine fehlerhafte Route:

Code: Alles auswählen

default dev lo proto ra metric 1024 pref medium

Wo die Route herkommt, dazu hab ich keine Ahnung.

[cosinus]

Ich hab die fehlerhafte Route aber nicht

[bluestar]

Ich hab die fehlerhafte Route aber nicht

Die steht in deinem Post ....

[cosinus]

Die steht in deinem Post ....

Ja, aber es klang so, als ob du mich für den TO hälst
Ich hab die fe80-Route ja auch nur erwähnt, weil du eine andere zitiert hast

[bluestar]

Ja, aber es klang so, als ob du mich für den TO hälst

Ups war mein Fehler.

[bluestar]

Ist für IPv6 nicht das hier der relevante Eintrag?

Code: Alles auswählen

default via fe80::da49:bff:feb7:37c4 dev ppp0 proto ra metric 1024 expires 1725sec pref medium

Das Problem was vorliegt: Es existieren zwei Default-Routen mit gleicher Metrik und somit wird die erste genommen

Code: Alles auswählen

default dev lo proto ra metric 1024 pref medium

und die verweist halt auf sich selbst als Default-Gateway, was ein bißchen wiedersinnig ist.

[uname]

Etwas am Thema vorbei:
Ich habe weder Ahnung vom Pi noch von IPv6. Ich habe aber einen TP-Link TL-WR802N Nano-Router (etwas über 20 Euro), der wahrscheinlich PPPoE mit IPv6 kann siehe hier (etwas scrollen) und hier. Habe PPPoE und IPv6 damit noch nicht ausprobiert. Ich nutze nur den WISP-Client-Modus mit IPv4, um ein vorhandes WLAN in einem neues, geroutetes (nicht gebridgtes) WLAN umzuwandeln. Man kann wohl auch ein OpenWrt draufflashen. Braucht ohne Last dann wohl 1,3 Watt falls es jemanden interessiert.

[SirNibo]

Was ich gerade als erstes sehe ist eine fehlerhafte Route:

Code: Alles auswählen

default dev lo proto ra metric 1024 pref medium

Hi,
hast recht. Wenn ich diese Route lösche, funktioniert es. Der PI kann jetzt auf den Inernet Wellen reiten.
Natürlich gib es trotzdem folge Probleme.

Der Pi verbindet sich nicht automatisch beim booten und erstellt dadurch kein ppp0 Interface.
die PPPOECONF setzt diese Einträge in der /etc/network/interfaces

Code: Alles auswählen

auto dsl-provider
iface dsl-provider inet ppp
pre-up /bin/ip link set eth0 up # line maintained by pppoeconf
provider dsl-provider

auto eth0

Wide-dhcp meckert wegen dem fehlendem ppp0 tracking Interface. Ich bin gezwungen den wide-dhcp Service neustarten zu lassen.
Danach bekommen die anderen Interfaces ein Prefix.

Radvd verteilt das Prefix auch an die Clients, leider kommen sie nicht ins Internet.
IPv6 forwarding fehlt.

Wenn ich das IPv6 Forwarding einschalte, funktioniert das Router Advertisment nicht bei der Einwahl.
Der Befehl

Code: Alles auswählen

sysctl -w net.ipv6.conf.ppp0.accept_ra=2

funktioniert nicht, solange das ppp0 Interface nicht da ist.

Die Link Local default Route

Code: Alles auswählen

default via fe80::6a8f:84ff:fef4:ad99 dev ppp0 metric 1024 pref medium

wird auch beim einschalten vom IPv6 Forwarding entfernt.

Ich habe folgenden Workaround erstellt.
Ich lasse 2 Scripte beim beim DSL Start (pon dsl-provider) ausführen

Da Forwarding für lokale Netze schon beim booten da sein soll, habe ich es in der sysctl.conf eingetragen.
Es soll nur beim DSL Start kurzzeitig abgeschaltet werden, damit das Rouer Advertisment funktioniert
/etc/ppp/ip-pre-up.d/disable_ipv6_forwarding

Code: Alles auswählen

sysctl -w net.ipv6.conf.all.forwarding=0

/etc/ppp/ip-up.d/fix_ipv6_problems

Code: Alles auswählen

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route del default dev lo
ip -6 route add default via fe80::6a8f:84ff:fef4:ad99 dev ppp0
service wide-dhcpv6-client restart
nft -f /etc/nftables.conf

Das funktioniert so, sollte doch trotzdem irgendwie schöner gehen. Mehr gefrickel geht nicht.
Ausserdem währe es cool, wenn sich die Sache beim booten verbinden würde.

[bluestar]

Fangen wir mal vorne an, ich habe diesen Router früher auch im Einsatz gehabt und über ein systemd service folgendes Script zum Starten des PPPd genutzt. Den Router hatte ich auf die 192.168.1.1 konfiguriert und den PPPoE Traffic lasse ich durch VLAN7 laufen.

Code: Alles auswählen

#!/bin/bash

PROVIDER="provider-name"

if test -e "/usr/bin/snmpwalk"; then
	RUN_CHECK="yes"
else
	RUN_CHECK="no"
fi

if test "${RUN_CHECK}" = "yes"; then
	echo "$(date): Checking DSL-Line state" >>/var/log/tdsl.log
	LINE="WAITING"
	CNT=0
	MAX_CNT=100
	WAIT_TIME=30s
	while true; do
		CNT=$(( $CNT + 1 ))
		LINE=$(snmpwalk -Os -Oa -c public -v 1 192.168.1.1 1.3.6.1.2.1.10.94.1.1.3.1.6 | cut -d '"' -f2 | sed 's/\.//g')
		echo "$(date): Line-State: ${CNT}/${MAX_CNT}: ${LINE}" >>/var/log/tdsl.log
		if test "${LINE}" = "SHOWTIME"; then
			break;
		elif test "${LINE}" = ""; then
			break;
		fi
		sleep "${WAIT_TIME}"
		if test "${CNT}" = "${MAX_CNT}"; then
			echo "$(date): Aborting waiting loop, trying to start pppd without beeing in SHOWTIME state" >>/var/log/tdsl.log
			break;
		fi
	done
	echo "$(date): Starting pppd" >>/var/log/tdsl.log
else
	echo "$(date): Skipping Online Check" >>/var/log/tdsl.log
fi
echo "Starting pppd"
/usr/sbin/pppd nodetach call "${PROVIDER}"
echo "PPPd died"
echo "$(date): Stopped pppd" >>/var/log/tdsl.log
exit 1

Die "provider-name" Datei sieht folgendermaßen aus:

Code: Alles auswählen

plugin rp-pppoe.so eth0.7

noipdefault
#defaultroute
#replacedefaultroute
hide-password
lcp-echo-interval 20
lcp-echo-failure 3
noauth
nopersist
#noaccomp
#nopcomp
#novj
#nobsdcomp
#nodeflate
#noccp
+ipv6 ipv6cp-use-ipaddr
#ipv6cp-use-ipaddr

ipparam provider-name
linkname provider-name
unit 0

user "USERNAME"
password "PASSWORD"

Und im letzten Schritt gibt es in /etc/ppp/ip-up.d/ ein Script zum Aktivieren der ppp0 spezifischen Settings:

Code: Alles auswählen

#!/bin/bash

if test "${PPP_IPPARAM}" != "provider-name"; then
	exit 0
fi

if test "${PPP_IFACE}" = ""; then
	exit 0
fi

echo "Setting up routing table"
/sbin/ip -4 route add default dev "${PPP_IFACE}" metric 15 table default
echo "Enabling Accept_RA"
/sbin/sysctl -w net.ipv6.conf.${PPP_IFACE}.accept_ra=2
echo "Starting wide-dhcpv6-client"
systemctl restart wide-dhcpv6-client