noone100

Die Labor-Firmware 18.12.2020 behebt das Problem.

Antwort von AVM:

die FRITZ!Box sendet die Anfrage auch nach Mitschnitt als Broadcast-Anfrage. 
 Der Mitschnitt selbst zeigt aber auch, dass hier an 255.255.255.255 angefragt wird, 
also eine Broadcast-Anfrage stattfindet, von daher ist immer noch der Provider in der Verantwortung. 

Auf Seiten der FRITZ!Box lässt sich nun kein Fehler oder Fehlverhalten feststellen.
Wie empfehlen Ihnen daher eine Kontaktaufnahme mit Ihrem Provider.

Und genau deshalb wird es wohl keine Möglichkeit geben, die FRITZ!Box mit dem UPC-DHCP-Setup ohne Unterbrüche zum Laufen zu bringen. Die Firewall akzeptiert die ACKs in der oben genannten Form nicht (DHCP-Request-Dst == DHCP-Relay -> DHCP Ack src== DHCP Server mit Dst 0.0.0.0).

Was mich auch stutzig macht, ist folgender Abschnitt in der Spez:

If the ‘giaddr’
field is zero and the ‘ciaddr’ field is nonzero, then the server
unicasts DHCPOFFER and DHCPACK messages to the address in ‘ciaddr’.

Die obige Bedingung scheint erfüllt zu sein. Müsste dann nicht der DHCP-Server das ACK an die ciaddr schicken und nicht an 0.0.0.0?

Habe nun den Vergleich der beiden ISPs

Bei UPC gibt es ein ACK als Broadcast (mit Server Identifier vom Relay) beim anderen Provider gibt es ein Unicast ACK (mit Server Identifier vom Server) und dann gibt’s auch keine ICMP mit 

icmp and udp.dstport == 68

und Destination Unreachable.

Das Problem liegt nun vermutlich beim Broadcast oder beim Relay. Beides kann ich wohl auf der FB nicht beeinflussen. Out of luck

Auf die Firewall lässt sich in der FRITZ!Box keinen Einfluss nehmen (nur Portforwading ins LAN)..

Wird die FRITZ!!Box über Glasfaser (an einen anderen Provider) angeschlossen, funktioniert es problemlos mit dem DHCP. DHCP scheint bei UPC anders umgesetzt worden zu sein als beim Glasfaser-Provider. Fragt sich nur was genau die FB zum Ablehnen des ACKs bringt. Ich werde mal einen Mitschnitt mit Glasfaser machen und den Unterschied versuchen zu erkennen.

Ich habe nun einen Mitschnitt, der kurz nach dem ersten Lease startet und bis nach dem Überschreiten der Lease-Time, dem Trennen der Verbindung und einem erneuten DHCPOFFER dauert (ca. 10 min). Im DHCP Server Identifier ist die IP des Relays eingetragen, was wohl auf [1] zurückzuführen ist.

Könntest du @GrandDixence den Mitschnitt einmal analysieren? Vielen Dank!

Das Problem tritt gleichermassen mit einer FRITZ!Box 7270 als auch mit einer 5490 auf.

[1] https://tools.ietf.org/html/rfc5107#page-3

Werde diesen Freitag den Netzwerkverkehr aufzeichnen und schauen, ob auch ein “nicht akzeptiert” geschickt wird.

Die Anleitung bei DHCP-Problemen scheint für die Connect Box zu gelten. Bei mir ist noch das Technicolor TC7200-U im Einsatz.

Bei einem kurzen Mitschnitt auf der WAN-Schnittstelle sind diverse DHCP-Discovery Broadcasts angekommen. Reichen die schon für eine Analyse oder braucht es einen Mitschnitt um den Disconnect herum? Falls nein, wird der Wireshark-Mitschnitt wohl riesig werden, da das Problem nur ca. 2 Mal am Tag auftritt. Reicht die auf DHCP-Pakete gefilterte pcap-Datei?

Wie schon vor Jahren hier und hier und hier beschrieben wird bei bei meiner FRITZ!Box die Verbindung ca. alle 12 Stunden wegen eines DHCP-Lease-Timeouts unterbrochen. Das nervt bei grossen Downloads und VoIP-Telefonaten, die dann einfach unterbrochen werden. UPC scheint die DHCP-Leases nach wie vor nicht standardgemäss umzusetzen und je nach dem, welchen DHCP-Server man erwischt, funktioniert es einmal dann wieder nicht.

@d_rotcod  und @Guldi, tritt das Problem bei euch auch immer noch auf?

Region: Bern

Modem: Technicolor TC7200-U im Bridge-Modus (da nach wie vor Routerzwang bei UPC)