Verliere ipv6 Adresse regelmäßig

[Hendrik Friedel]

Hallo,

ich habe mein Netzwerk so konfiguriert:

/run/systemd/network/10-netplan-eth0.network

[Match]
MACAddress=00:22:4d:cc:27:xx

[Network]
DHCP=ipv6
LinkLocalAddressing=ipv6
Address=192.168.177.3/24
IPv6AcceptRA=yes
Gateway=192.168.177.1
DNS=192.168.177.1
Domains=fritz.box

[DHCP]
RouteMetric=100
UseMTU=true

Das führt normalerweise zu dieser Konfiguration:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.177.3  netmask 255.255.255.0  broadcast 192.168.177.255
        inet6 2003:cb:7777:ca00:222:4dff:ffff:27bb  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::222:4dff:ffff:27bb  prefixlen 64  scopeid 0x20<link>
        ether 00:22:4d:aa:27:bb  txqueuelen 1000  (Ethernet)
        RX packets 137651  bytes 18242706 (17.3 MiB)
        RX errors 0  dropped 522  overruns 0  frame 0
        TX packets 457464  bytes 661920809 (631.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7d00000-f7d20000


Nach einiger Zeit, verliere ich aber die eine ipv6 Adresse:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.177.3  netmask 255.255.255.0  broadcast 192.168.177.255
        inet6 fe80::222:4dff:ffff:27bb  prefixlen 64  scopeid 0x20<link>
        ether 00:22:4d:aa:27:bb  txqueuelen 1000  (Ethernet)
        RX packets 960934152  bytes 1005260996402 (936.2 GiB)
        RX errors 0  dropped 1040942  overruns 0  frame 0
        TX packets 496755961  bytes 560779155942 (522.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7d00000-f7d20000

ein ping6 z.B. zu Google schlägt dann fehl.

Woran kann das liegen?

Gruß,

Hendrik

[Sven Hartge]

Hendrik Friedel <hen...@friedels.name> wrote:

> Das führt normalerweise zu dieser Konfiguration:
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.177.3 netmask 255.255.255.0 broadcast
> 192.168.177.255
> inet6 2003:cb:7777:ca00:222:4dff:ffff:27bb prefixlen 64
> scopeid 0x0<global>
> inet6 fe80::222:4dff:ffff:27bb prefixlen 64 scopeid 0x20<link>
> ether 00:22:4d:aa:27:bb txqueuelen 1000 (Ethernet)
> RX packets 137651 bytes 18242706 (17.3 MiB)
> RX errors 0 dropped 522 overruns 0 frame 0
> TX packets 457464 bytes 661920809 (631.2 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> device interrupt 20 memory 0xf7d00000-f7d20000

Nutze bitte "ip addr show" zur Anzeige, das bringt nämlich die Werte
"valid_lft" und "preferred_lft" mit, an denen man sehen kann, wie lange
die Adresse noch gültig bzw. bevorzugt ist.

Wenn die RAs sauber gesendet werden und sauber ankommen, dann muss die
Zeit regelmäßig vor dem Ablaufen erneuert werden.

> Nach einiger Zeit, verliere ich aber die eine ipv6 Adresse:

> Woran kann das liegen?

Paketfilter filter ICMPv6 für RAs?

S!

--
Sigmentation fault. Core dumped.

[Hendrik Friedel]

Hallo Sven,

vielen Dank für deine Antwort.

ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 00:22:4d:aa:29:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.177.3/24 brd 192.168.177.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::222:4dff:ffff:27bb/64 scope link
valid_lft forever preferred_lft forever

>Nutze bitte "ip addr show" zur Anzeige, das bringt nämlich die Werte
>"valid_lft" und "preferred_lft" mit, an denen man sehen kann, wie lange
>die Adresse noch gültig bzw. bevorzugt ist.

forever steht da - aber das ist nur die lokale Adresse. Die andere habe
ich momentan ja nicht.

>
>Wenn die RAs sauber gesendet werden und sauber ankommen, dann muss die
>Zeit regelmäßig vor dem Ablaufen erneuert werden.
>
>> Nach einiger Zeit, verliere ich aber die eine ipv6 Adresse:
>
>> Woran kann das liegen?
>
>Paketfilter filter ICMPv6 für RAs?
>

Habe ich nicht manuell/bewusst definiert. Wie finde ich das raus?

Gruß&Danke,
Hendrik


>

[Sven Hartge]

Hendrik Friedel <hen...@friedels.name> wrote:

> vielen Dank für deine Antwort.

Bitte kein Cc: von Mails, danke.

> ip addr show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
> link/ether 00:22:4d:aa:29:bb brd ff:ff:ff:ff:ff:ff
> inet 192.168.177.3/24 brd 192.168.177.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 fe80::222:4dff:ffff:27bb/64 scope link
> valid_lft forever preferred_lft forever


>> Nutze bitte "ip addr show" zur Anzeige, das bringt nämlich die Werte
>> "valid_lft" und "preferred_lft" mit, an denen man sehen kann, wie lange
>> die Adresse noch gültig bzw. bevorzugt ist.

> forever steht da - aber das ist nur die lokale Adresse. Die andere habe
> ich momentan ja nicht.

Das ist natürlich Voraussetzung für das Experiment.

>> Wenn die RAs sauber gesendet werden und sauber ankommen, dann muss die
>> Zeit regelmäßig vor dem Ablaufen erneuert werden.
>>
>>> Nach einiger Zeit, verliere ich aber die eine ipv6 Adresse:
>>
>>> Woran kann das liegen?
>>
>> Paketfilter filter ICMPv6 für RAs?

> Habe ich nicht manuell/bewusst definiert. Wie finde ich das raus?

Zuerst einmal "ip6tables-save", das zeigt, ob es irgendwelche Regeln
gibt. Alternativ "nft list ruleset ip6". Am besten beides testen.

Dann kann es natürlich sein, dass deine FritzBox die RAs nicht sauber
sendet.

Oder das irgendetwas Multicasts schluckt, das ist auch ein "beliebtes"
Problem bei IPv6, da alles, was nicht Unicast ist, ist Multicast.

[Hendrik Friedel]

Hallo,

vielen Dank für deine Antwort.

>> forever steht da - aber das ist nur die lokale Adresse. Die andere habe
>> ich momentan ja nicht.
>
>Das ist natürlich Voraussetzung für das Experiment.

Ja, aber ich weiß nicht, wie ich jetzt eine Adresse bekomme.
Ich habe es so versucht:
dhclient -6 -d eth0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on Socket/eth0
Sending on Socket/eth0
PRC: Previous lease is devoid of active addresses.
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT: X-- IA_NA 4d:aa:27:bb
XMT: | X-- Request renew in +3600
XMT: | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 1040ms.
RCV: Advertise message on eth0 from
2001:cb:9743:ae00:9ec7:a6ff:fefd:3a69.
RCV: X-- Preference 0.
RCV: X-- IA_NA 4d:aa:27:bb
RCV: | X-- starts 1610047394
RCV: | X-- t1 - renew +1800
RCV: | X-- t2 - rebind +2880
RCV: | X-- [Options]
RCV: | | X-- IAADDR 2001:cb:9743:ae00:222:4dff:feaa:16ae
RCV: | | | X-- Preferred lifetime 3600.
RCV: | | | X-- Max lifetime 7200.
RCV: X-- Server ID: 00:03:00:01:9c:c7:a6:fd:3a:69
RCV: Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC: X-- Initial candidate 00:03:00:01:9c:c7:a6:fd:3a:69 (s: 10104, p:
0).
XMT: Forming Request, 0 ms elapsed.
XMT: X-- IA_NA 4d:aa:27:bb
XMT: | X-- Requested renew +3600
XMT: | X-- Requested rebind +5400
XMT: | | X-- IAADDR 2001:cb:9743:ae00:222:4dff:feaa:16ae
XMT: | | | X-- Preferred lifetime +7200
XMT: | | | X-- Max lifetime +7500
XMT: V IA_NA appended.
XMT: Request on eth0, interval 1030ms.
RCV: Reply message on eth0 from 2001:cb:9743:ae00:9ec7:a6ff:fefd:3a69.
RCV: X-- Preference 0.
RCV: X-- IA_NA 4d:aa:27:bb
RCV: | X-- starts 1610047395
RCV: | X-- t1 - renew +1800
RCV: | X-- t2 - rebind +2880
RCV: | X-- [Options]
RCV: | | X-- IAADDR 2001:cb:9743:ae00:222:4dff:feaa:16ae
RCV: | | | X-- Preferred lifetime 3600.
RCV: | | | X-- Max lifetime 7200.
RCV: X-- Server ID: 00:03:00:01:9c:c7:a6:fd:3a:69
PRC: Bound to lease 00:03:00:01:9c:c7:a6:fd:3a:69.
PRC: Renewal event scheduled in 1800 seconds, to run for 1080 seconds.
PRC: Depreference scheduled in 3600 seconds.
PRC: Expiration scheduled in 7200 seconds.

Ich hoffe, das macht Sinn.
Interessanterweise beendet sich das Programm nicht.

Das ergibt nun:

ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000

link/ether 00:22:4d:aa:27:bb brd ff:ff:ff:ff:ff:ff

inet 192.168.177.3/24 brd 192.168.177.255 scope global eth0
valid_lft forever preferred_lft forever

inet6 2001:cb:9743:ae00:222:4dff:feaa:16ae/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::222:4dff:feaa:16ae/64 scope link
valid_lft forever preferred_lft forever

>>> Wenn die RAs sauber gesendet werden und sauber ankommen, dann muss die
>>> Zeit regelmäßig vor dem Ablaufen erneuert werden.
>>>
>>>> Nach einiger Zeit, verliere ich aber die eine ipv6 Adresse:
>>>
>>>> Woran kann das liegen?
>>>
>>> Paketfilter filter ICMPv6 für RAs?
>
>> Habe ich nicht manuell/bewusst definiert. Wie finde ich das raus?
>
>Zuerst einmal "ip6tables-save", das zeigt, ob es irgendwelche Regeln
>gibt. Alternativ "nft list ruleset ip6". Am besten beides testen.
>

ip6tables-save gibt keinerlei output.
nft ist nicht installiert. Sollte ich es installieren, oder bedeutet
das, dass nft auch nicht filtern kann?

>Dann kann es natürlich sein, dass deine FritzBox die RAs nicht sauber
>sendet.

Ist das denn ein bekanntes Problem? Wie kann ich das herausfinden?

>
>Oder das irgendetwas Multicasts schluckt, das ist auch ein "beliebtes"
>Problem bei IPv6, da alles, was nicht Unicast ist, ist Multicast.

Aber zwischen der Fritzbox ist ja nur ein (non-Managed) Switch. Der kann
ja eigentlich nix schlucken?

Gruß,
Hendrik

[Sven Hartge]

Hendrik Friedel <hen...@friedels.name> wrote:

> dhclient -6 -d eth0

> Interessanterweise beendet sich das Programm nicht.

Natürlich, das ist, was "-d" macht.

Allerdings ist der Mechanismus über den DHCP die IPv6 vergibt ein
anderer wie der via RA.

Insoweit ist mit den Informationen, die du angibst das Problem aus der
Ferne nicht diagnostizierbar.

> Aber zwischen der Fritzbox ist ja nur ein (non-Managed) Switch. Der kann
> ja eigentlich nix schlucken?

Leider doch. Weil bei IPv4 Multicast nur sehr selten zum Einsatz kam,
gab es durchaus ungemanagete halb-intelligente Switche, die versuchten
Multicast via IGMP-Snooping zu optimieren, aber dies dann unpassend oder
falsch implementiert hatten. Ob du so einen hast, kann ich dir nicht
sagen.

[Marc Haber]

On Thu, 07 Jan 2021 19:31:15 +0000, "Hendrik Friedel"
<hen...@friedels.name> wrote:
>Aber zwischen der Fritzbox ist ja nur ein (non-Managed) Switch. Der kann
>ja eigentlich nix schlucken?

Ich hatte schonmal einen Switch der Multicast-Pakete nicht korrekt
weitergeleitet hat. Der Hersteller hat das Problem nicht verstanden
und nur geantwortet, dass man IPv6 nicht unterstütze. Dass Multicast
eine zwingend umzusetzende Eigenschaft von Ethernet ist, hat ihn nicht
interessiert. Also: Hardware weg, Hersteller blackgelistet.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Hendrik Friedel]

Hallo,

ich denke, es gibt zwei Möglichkeiten für mich um das Problem zu lösen
oder einzugrenzen:
a) Den Rechner direkt mit der FritzBox zu verbinden
b) Eine Lösung finden, die ohne Multicast auskommt

Zu a):
Ich habe viele andere Rechner (alle allerdings Windows, daher starte ich
sie natürlich regelmäßig neu), die keine Probleme haben
Ich habe einen anderen Debian Rechner (RasPi Zero). Der hat scheinbar
das gleiche Problem. Allerdings ist er NICHT über den Switch
angeschlossen, sondern:
FritzBox --> Unifi AC Pro (Wlan AP) -> Wlan -> Raspi
Natürlich kann auch der Unifi AP ein Problem mit Multicast haben; aber
ich würde erstmal den Fehler woanders vermuten: die Gemeinsamkeiten der
zwei problematischen Clients sind:
- Ich
- Debian
- FritzBox

zu b)
Was kann ich machen um nicht auf Multicast angewiesen zu sein?

Gruß,
Hendrik

[Marc Haber]

On Sun, 10 Jan 2021 09:29:09 +0000, "Hendrik Friedel"
<hen...@friedels.name> wrote:
>ich denke, es gibt zwei Möglichkeiten für mich um das Problem zu lösen
>oder einzugrenzen:
>a) Den Rechner direkt mit der FritzBox zu verbinden

Das klingt vielversprehcend, notfalls über WLAN. Dient ja nur dem
Test.

>b) Eine Lösung finden, die ohne Multicast auskommt

IPv6 funktioniert ohne Multicast nicht. Punkt.

>Ich habe einen anderen Debian Rechner (RasPi Zero). Der hat scheinbar
>das gleiche Problem. Allerdings ist er NICHT über den Switch
>angeschlossen, sondern:
>FritzBox --> Unifi AC Pro (Wlan AP) -> Wlan -> Raspi
>Natürlich kann auch der Unifi AP ein Problem mit Multicast haben;

Hat er nicht, ich habe hier auch Unifi WLAN.

Wenn sich der Fehler reproduzieren lässt, würde ich einfach mal einen
tcpdump -np -s 0 -w /path/to/file mitlaufen lassen; Port 80, 443 und
sonstige Ports die viel Traffic machen gerne ausschließen. Zusätzlich
einen Prozess mitlaufen lassen der Alarm schlägt sobald die
IPv6-Adresse verschwindet und dann das pcap-File mit wireshark
angucken oder angucken lassen. Ich würde mich für letzteres "opfern",
meine Mailadresse funktioniert.

[Hendrik Friedel]

Hallo Marc,

>>ich denke, es gibt zwei Möglichkeiten für mich um das Problem zu lösen
>>oder einzugrenzen:
>>a) Den Rechner direkt mit der FritzBox zu verbinden
>
>Das klingt vielversprehcend, notfalls über WLAN.

Na, der RasPi ist ja schon über WLAN verbunden. Und ich war recht
sicher, dass er das gleiche Problem hatte. Jetzt hat er aber (wieder?)
eine ipv6 Adresse.

>>b) Eine Lösung finden, die ohne Multicast auskommt
>
>IPv6 funktioniert ohne Multicast nicht. Punkt.

Verstanden :-)

>>Natürlich kann auch der Unifi AP ein Problem mit Multicast haben;
>
>Hat er nicht, ich habe hier auch Unifi WLAN.
>

Gut!

>
>Wenn sich der Fehler reproduzieren lässt, würde ich einfach mal einen

Ja, dauert nur eine Weile.

>
>tcpdump -np -s 0 -w /path/to/file mitlaufen lassen; Port 80, 443 und
>sonstige Ports die viel Traffic machen gerne ausschließen.

SSH, Samba würden mir da noch einfallen.
Ich bin nicht sicher, ob ich die richtige Syntax gefunden habe um Ports
auszuschließen.
Ich habe dieses Beispiel gefunden:
tcpdump -i eth1 -s 1500 port not 22 and port not 53

Wäre das in meinem Beispiel:
tcpdump -np -s 0 -w /path/to/file port not 22 and port not 53
oder
tcpdump port not 22 and port not 53 -np -s 0 -w /path/to/file

>Zusätzlich
>einen Prozess mitlaufen lassen der Alarm schlägt sobald die
>IPv6-Adresse verschwindet und dann das pcap-File mit wireshark
>angucken oder angucken lassen. Ich würde mich für letzteres "opfern",
>meine Mailadresse funktioniert.

Danke für das Angebot!

Gruß,
Hendrik

[Marc Haber]

On Sun, 10 Jan 2021 21:24:55 +0000, "Hendrik Friedel"
<hen...@friedels.name> wrote:
>Wäre das in meinem Beispiel:
>tcpdump -np -s 0 -w /path/to/file port not 22 and port not 53
>oder
>tcpdump port not 22 and port not 53 -np -s 0 -w /path/to/file

Also ich schreibe den Ausdruck immer nach hinten und ich schreibe "not
port 22". Aber Du kannst das ja mal ein paar Minuten mitlaufen lassen
und Dir dann den Trace anschauen.

[Ulf Volmer]

On 11.01.21 13:16, Marc Haber wrote:
> On Sun, 10 Jan 2021 21:24:55 +0000, "Hendrik Friedel"
> <hen...@friedels.name> wrote:
>> Wäre das in meinem Beispiel:
>> tcpdump -np -s 0 -w /path/to/file port not 22 and port not 53
>> oder
>> tcpdump port not 22 and port not 53 -np -s 0 -w /path/to/file
>
> Also ich schreibe den Ausdruck immer nach hinten und ich schreibe "not
> port 22". Aber Du kannst das ja mal ein paar Minuten mitlaufen lassen
> und Dir dann den Trace anschauen.

Wobei -s 0 eigentlich schon seit geraumer Zeit der Default ist.

Viele Grüße
Ulf

[Marc Haber]

On Mon, 11 Jan 2021 16:58:13 +0100, Ulf Volmer <u.vo...@u-v.de>
wrote:

Oh. Mein Fingermemory...