FRITZ!Box 7490 DHCP-Server spinnt

netspy

Neuer User
Mitglied seit
24 Dez 2015
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Hallo und frohe Weihnachten allerseits!

Seit dem Update auf die Release-Version 06.50 (hatte vorher Labor-Versionen) spinnt bei meiner FRITZ!Box 7490 vermutlich der DHCP-Server. Verschiedene Geräte (iPad, iPhone, Android-Phone, etc.) können sich auf einmal nicht mehr im Netzwerk anmelden. Die WLAN-Verbindung wird zwar hergestellt (sehe ich unter fritz.box) aber das Gerät erhält keine IP-Adresse und taucht im Heimnetzwerk nicht auf. Nach mehreren Minuten funktioniert es zwar dann manchmal, aber auch nicht immer und das ist natürlich auch kein Zustand.

Verschiedene Sachen habe ich schon probiert. Bei den Geräten den Lease erneuern bringt nichts. Unter fritz.box die Einstellungen zum DHCP-Server ändern (bspw. den Bereich, momentan .20-160 und 31 Tage) hilft manchmal aber nicht dauerhaft. IP-Adressen sind im Bereich noch genügend übrig.


Wie schon gesagt, ist WLAN nicht das Problem. Die Geräte sind im WLAN angemeldet (sehe ich an der MAC-Adresse) und ich habe auch keine Einschränkungen im WLAN hinsichtlich MAC gemacht. Es liegt sehr wahrscheinlich am DHCP-Server, der nur noch sehr unregelmäßig IP-Adresse vergibt, obwohl noch genügend frei sind. Stelle ich bei den Geräten eine feste IP-Adresse, Router und DNS ein, klappt die Verbindung auf Anhieb.


In allen Labor-Versionen der 06.50 gab es solche Probleme nicht. Die sind erst in der Release aufgetreten und ich bin hier langsam am verzweifeln.

Hat irgendwer eine Idee, woran das liegen könnte oder ob ich hier auf ein Update von AVM warten muss? Der Support hat sich auf meine Anfrage noch nicht geäußert.

Gruß
 
Hast Du denn das gleiche Problem bei kabelgebundenen Geräten?

Schon mal dir Geräte in der Netzwerkübersicht gelöscht?
 
Ich habe mit meinen Mac-Geräten keine Probleme. Lease erneuern hilft nicht, sondern nur neues komplettes Login "einspeichern"
Meine Einstellung in der Fritzbox
DHCP_einstellung.jpg
Der DNS-Server sollte gleich die IP der Fritzbox sein, sowie die Suchdomain = fritz.box
 
Hast Du denn das gleiche Problem bei kabelgebundenen Geräten?
Ich habe hier fast alles über WLAN angeschlossen und bei den wenigen LAN-Geräten ist mir das Problem noch nicht aufgefallen. Es tritt auch offenbar nur dann auf, wenn ich ein neues Gerät anschließe oder der Lease einen angeschlossenen Geräts abgelaufen ist.

Schon mal dir Geräte in der Netzwerkübersicht gelöscht?
Du meinst die Heimnetzübersicht? Dort tauchen die Geräte mit den Problemen ja nicht auf, weil sie noch keine IP-Adresse haben. Ich sehe sie nur im WLAN-Funknetz und dort löschen hilft nichts.
 
Ich sehe sie nur im WLAN-Funknetz und dort löschen hilft nichts.

Werden die Anmeldeversuche der WLAN-Geräte, in der FritzBox unter " System - Ereignisse - WLAN " (... dort mit der Einstellung "Auch An- und Abmeldungen protokollieren") angezeigt/protokolliert?
 
Wenn das Problem bei den LAN Geräten nicht auftritt (ein Test ist ja schnell gemacht) müsstest Du Deine Annahmen evtl nochmal überdenken.

Backup machen, Werksreset und dann testen wäre auch noch ein Szenario.
 
... Hat irgendwer eine Idee, woran das liegen könnte oder ob ich hier auf ein Update von AVM warten muss? ...
Liegt an der 6.50 ;)

Warten auf AVM ? 6.51 dauert bis nächstes Jahr.
Recovery 6.30 geht schneller.
 
... spinnt bei meiner FRITZ!Box 7490 vermutlich der DHCP-Server.

BTW: Mit z. B. nmap (... und bei bereits bestehender WLAN-Verbindung) kannst Du zum testen, ein DHCPDISCOVER an den DHCP-Server deiner FritzBox senden und schauen ob der DHCP-Server mit einem DHCPOFFER antwortet:

Code:
:~$ sudo nmap -sU -p 67 --script=dhcp-discover 192.168.178.1

Starting Nmap 5.21 ( http://nmap.org ) at 2015-12-24 12:53 CET
NSE: Script Scanning completed.
Nmap scan report for fritz.box (192.168.178.1)
Host is up (0.0030s latency).
PORT   STATE SERVICE
67/udp open  dhcps
| [color=red]dhcp-discover[/color]:  
|   [color=red]IP Offered: 192.168.178.41[/color]
|   DHCP Message Type: [color=red]DHCPOFFER[/color]
|   Server Identifier: 192.168.178.1
|   IP Address Lease Time: 5 days, 0:00:00
|   Renewal Time Value: 2 days, 12:00:00
|   Rebinding Time Value: 4 days, 9:00:00
|   Subnet Mask: 255.255.255.0
|   Router: 192.168.178.1
|   Domain Name Server: 192.168.178.1
|   Domain Name: fritz.box
|   Broadcast Address: 192.168.178.255
|_  NTP Servers: 192.168.178.1
MAC Address: ##:##:##:##:##:## (Unknown)

Das testen mit nmap sollte auch dann funktionieren, wenn dein WLAN-Client bereits eine statische/feste (d. h. nicht per dhcp) IPv4-Adresse (... von außerhalb des DHCP-Pools der FB) hat.
 
Es tritt auch offenbar nur dann auf, wenn ich ein neues Gerät anschließe oder der Lease einen angeschlossenen Geräts abgelaufen ist.
netspy schrieb:
die Einstellungen zum DHCP-Server ändern (bspw. den Bereich, momentan .20-160 und 31 Tage)
netspy schrieb:
In allen Labor-Versionen der 06.50 gab es solche Probleme nicht. Die sind erst in der Release aufgetreten [...]
http://www.ip-phone-forum.de/showthread.php?t=282924&page=23 => FRITZ!Box 7490 Firmware Version 113.06.50 vom 10.12.2015
Code:
# date
[COLOR="#FF0000"]Thu Dec 24[/COLOR] 13:05:18 CET [COLOR="#FF0000"]2015[/COLOR]
:gruebel:
Ich bin etwas verwirrt ob der (vermeintlichen?) Widersprüche ... aber vielleicht habe ich ja auch etwas fundamental falsch verstanden?

Ich würde das WLAN der Box abschalten, die LAN-Verbindungen - so vorhanden - kappen und in der Box (die Frage wäre dann, womit ... komme ich gleich drauf zurück) alle bekannten Clients löschen, notfalls nach Neustart, falls die Box den Verlust des Kontaktes zu einigen Clients nicht sofort mitbekommt und sich weigert, diese zu löschen. Dann den DHCP-Server auf sinnvolle Werte konfigurieren (das ist in der Regel sogar eine kürzere Lease-Time als die 10 Tage, die AVM vorgibt) und die Geräte der Reihe nach wieder anmelden, Clients mit fester IP-Adresse zuerst.

"Anmelden" meint hier nicht nur die Herstellung einer WLAN-Verbindung für die so verbundenen Geräte, sondern einen Internet-Zugriff von einem solchen, damit die FRITZ!Box auch bei fester IP-Adresse von dem Gerät "Notiz nehmen" kann.

Wenn das Gerät dann noch von sich aus z.B. mDNS benutzt, sollte auch der passende Client-Name irgendwann in der FRITZ!Box auftauchen - ob LLMNR noch in 06.50 unterstützt ist, weiß ich nicht ... das findet man beim Vorhandensein passender Clients aber in den Support-Daten der Box zu den "neighbors" sehr schnell heraus.

Ohne solche Dienste verwendet FRITZ!OS m.W. eine DHCP-Client-ID, sofern vorhanden, zur Anzeige des Namens und natürlich auch zur DNS-Auflösung für die lokale Domain (Standard "fritz.box") - die sollte man bei Geräten mit fester IP-Adresse auch als Kandidatin für eine Suchdomain hinterlegen, weil diese Geräte natürlich nicht per DHCP entsprechend konfiguriert werden.

Je nachdem, wie ein Client DNS-Abfragen macht, fügt die FRITZ!Box einer Namenssuche ja nicht selbst die passenden Domains hinzu und so klappen Abfragen für "NAS" o.ä. auf DNS-Ebene meist nur dann, wenn der Client selbst entsprechende Suchdomains "abklappert" - in diesem Falle dann eben auch nach "NAS.fritz.box" fragt. WINS/NetBIOS-Namensauflösung ist wieder etwas anderes, da werden auch Broadcasts mit genutzt.

Die schon angesprochenen Support-Daten sollten vor dieser ersten Neuanmeldung jedenfalls keine bekannten LAN-/WLAN-Clients aufweisen (auch der Abschnitt "landevices" der ar7.cfg nicht). Wenn AVM nicht in letzter Minute noch geändert hat, wirkt sich die eingestellte Lease-Time nicht direkt auf das automatische Löschen einen Eintrags für einen bekannten Client in der FRITZ!Box aus, aber sie hat eben (m.E. negative) Auswirkungen auf die Annahmen eines Clients, nach welcher Zeit er seinerseits seine Reservierung erneuern muß.

Da sind 31 Tage - noch dazu bei einem Client, der mehr oder weniger regelmäßig die Verbindung zur Box kappt, wenn er Strom sparen will - in meinen Augen geradezu prädestiniert für künftige Probleme. Ein Client, der sich regelmäßig bei der Box meldet und seine Lease erneuert, kriegt in der Regel auch ohne "immer dieselbe Adresse"-Checkbox eine "relative feste" IP-Adresse vom FRITZ!Box-DHCP-Server. Will man das in eine "richtige feste" IP-Adresse verwandeln, setzt man die richtige Checkmark.

Mal grundsätzlich (wer nicht will, springt über den Absatz) ... das DHCP-Protokoll sieht eigentlich vor, daß ein Client - nachdem er seine Adresse erhalten hat - diese auch bis zum Ablauf der bei der Akquise übermittelten Lease-Time ohne erneute Anfrage beim DHCP-Server verwenden darf, solange er sie nicht vorher in irgendeiner Form wieder freigegeben hätte (DHCPRELEASE). Selbst wenn der Client also keine Antwort von einem (genauer seinem, denn er muß sich merken, welcher Server ihm die Adresse gab) DHCP-Server erhalten sollte - immer unter der Voraussetzung, daß er überhaupt nachfragt -, könnte er also problemlos innerhalb der Lease-Time des letzten Requests dieselbe Adresse weiterhin verwenden. Schon von daher ist es keine so richtig gute Idee, eine so extrem lange Lease-Time zu verwenden. Wird zwischendrin aus irgendeinem Grund der DHCP-Server neu gestartet und führt der nicht ordentlich Buch über die vergebenen Adressen, kann auf diesem Weg die Situation eintreten, daß zwei Clients dieselbe Adresse verwenden. Nirgendwo steht geschrieben, daß ein Client bei jeder Aktivierung seiner Netzwerkverbindung eine neue Adresse akquirieren muß, wenn die alte noch nicht abgelaufen ist oder von ihm explizit freigegeben wurde. Kriegt also ein Client die .20 und die Box notiert das nicht richtig, die FRITZ!Box wird neu gestartet und jetzt erhält der nächste Client die .20 von der FRITZ!Box, ist das Chaos vorprogrammiert. Am Ende ist es jetzt Sache des Clients, wie er mit einer solchen Lease umgeht ... wenn er nach dem Aufwachen aus einem "sleep state" eine neue Adresse anfordern will, sollte er eben vor dem Einschlafen die alte auch wieder freigeben. Das machen m.E. die wenigsten Clients, beim Verlust des Kontaktes zum DHCP-Server geht das ja auch unter Umständen gar nicht. Dann sollte sich eben so ein Client seinerseits merken, wann er die letzte Adresse erhalten hat und wie lange diese für ihn reserviert ist (RFC 2131, Seite 41, Abs. 2 - T1 und T2 und deren Berechnung auf der Basis der Lease-Time). Die Empfehlung lautet also auch, daß so ein Client nach der Hälfte der angegebenen Lease-Time die Reservierung bereits verlängert. Kriegt er dann keine Antwort, darf er sie trotzdem weiterhin bis zum Ablauf der Lease-Time verwenden. Selbst wenn also der DHCP-Server der FRITZ!Box tatsächlich einem WLAN-Client nicht antworten sollte, ist eigentlich dieser Client selbst daran schuld, wenn er eine vorher geleaste Adresse (immer wieder unter der Einschränkung, daß er sie nicht freigegeben hat) nicht einfach weiter verwendet, solange die Lease-Time nicht um ist. Ob das allerdings tatsächlich so ist, kannst Du ja eigentlich ohne entsprechenden Netzwerk-Mitschnitt nicht wirklich sicher sagen ... Du machst die Schlußfolgerung, der DHCP-Server wäre schuld, ja daran fest, daß die Clients nicht ins Internet (oder ins LAN) kommen. Solange die nicht ihrerseits die vorher verwendete IP-Adresse nach dem letzten Request wieder freigegeben haben und es noch innerhalb der Lease-Time ist, muß der Server nicht unbedingt antworten (auch wenn er es natürlich sollte) - das wäre also zumindest mal ein I14Y-Problem, an dem nicht nur die FRITZ!Box schuld ist. Meines Wissens "notiert" die FRITZ!Box selbst sich die Lease-Time gar nicht ... jedenfalls nicht in der /var/flash/multid.leases und wohl auch nicht in "landevices" in der ar7.cfg. Damit wäre dann die Lease-Time im GUI ausschließlich als Angabe für die Clients relevant, wie sie ihrerseits T1 und T2 einrichten sollen. Spätestens nach einem Neustart der FRITZ!Box müßten meines Erachtens sämtliche Informationen, wann eine bestimmte IP-Adresse von der FRITZ!Box vergeben wurde, verloren sein ... ich wüßte jedenfalls nicht, wie und wo diese einen Neustart überleben sollten. Damit muß die FRITZ!Box entweder eine bereits vergebene IP-Adresse für die anfragende MAC-Adresse in ihrem Büchern finden oder sie muß zwangsläufig eine neue vergeben, weil sie bei den bisher verwendeten keine Ahnung hat, ob deren Clients nicht auf die Idee kommen dürfen, diese weiterhin (und sei es nach deren nächstem Start, die müssen ja aktuell gar nicht aktiv sein) zu verwenden. Wie AVM das handhaben will, wenn die Range "voll" ist, würde mich auch interessieren ... ich vermute mal, dann zählt das, was gerade in Benutzung ist, als reserviert und die erste inaktive Adresse als frei. Wenn also der DHCP-Server tatsächlich "spinnen" sollte, kann er das auf zwei möglichen Wegen ... entweder er antwortet gar nicht (dann hätte der Client das Recht, die alte Adresse weiter zu verwenden und er sollte damit trotzdem arbeiten können) oder der Server lehnt ein solches Ansinnen ab. Wie die Box da aber tatsächlich reagiert, kann man von außen schlecht sehen ... das braucht schon einen Packet-Dump entweder auf dem Client oder auf der FRITZ!Box.

Ich weiß nicht genau, was Du mit der oberen Beschränkung der DHCP-Range bezweckst und was Du mit den anderen Adressen zwischen 160 und dem von AVM vorgesehenen Wert von 200 machst ... aber ich kann (pauschal) jedem, der an den DHCP-Servereinstellungen dreht, nur empfehlen, dabei auch event. vorhandene VPN-Verbindungen nicht aus den Augen zu verlieren, wenn er solche Änderungen nachträglich vornimmt.

Bei der 06.50 habe ich noch nicht getestet, wo und wie sich AVM die Adressen für VPN-Clients "besorgt" ... früher ging das direkt nach der DHCP-Range los, die beim Anlegen der VPN-Einstellungen aktuell war und wenn dann nachträglich diese Range geändert wird, kann das je nach Änderung unterschiedliche Auswirkungen auf das LAN und/oder VPN-Clients haben. Ob AVM inzwischen bei einer nachträglichen DHCP-Änderung auch die VPN-Konfiguration überprüft und ggf. korrigiert bzw. anpaßt, weiß ich nicht.

Meine Empfehlung für den DHCP-Server in der FRITZ!Box lautet (nur für Leute, die eine solche Empfehlung überhaupt brauchen, man kann das auch anders lösen und mein Vorschlag ist nur eine solche mögliche Lösung), den auf den originalen Einstellungen zu belassen (wenn man ihn schon braucht) und feste Clients vor der DHCP-Range zu konfigurieren. Wenn die möglichen 18 Adressen (.2-.19) dafür nicht ausreichen (AVM hat da - in meinen Augen auch "dummerweise" - einen "menschlichen" Ansatz für die Adressen gewählt, ich würde auch von 33 (also 32 + 1) beginnend besser finden, weil man das notfalls noch weiter segmentieren könnte), dann verschiebt man den Anfang der Range nach hinten.

Ich kann auch nachvollziehen, daß sich Leute (feste) IP-Adressen wie 192.168.100.100 besser merken können als z.B. 192.168.100.129 ... aber aus Netzwerksicht wäre eine 129 (als erste Adresse in einem (denkbaren) Segment 192.168.100.128/25) die "logischere Wahl", wenn man sein internes Netz irgendwie weiter unterteilen will in dynamische oder feste Adressbereiche (und den DHCP-Server entsprechend konfigurieren will). Da ist die 160 schon kein wirklich guter Ansatz (128+32, also 192.168.178.160/27 wäre ein denkbares Segment, aber direkt die 160 wäre in diesem Segment eben die Netzadresse und als Hostadresse ungeeignet) ... eine Begrenzung auf 158 wäre da "logischer" (159 wäre die Broadcast-Adresse im Netz 192.168.178.128/27) und würde die Nutzung eines Subnetzes (direkt) dahinter vereinfachen.

Für Portweiterleitungen u.ä. bietet das FRITZ!OS auch bei Geräten mit festen IP-Adressen, die nicht in die DHCP-Range der FRITZ!Box fallen, die Zuordnung über den Client-Namen (so die FRITZ!Box ihn kennt, was nicht zwingend der Fall sein muß, dann heißt der nur "PC-mac-address") an. Braucht man für einen DHCP-Client im LAN eine feste IP-Adresse (z.B. für ein NAS, weil die DNS-Auflösung prinzipbedingt eben nur funktionieren kann, wenn das NAS sich gegenüber der FRITZ!Box mit einem Namen zu erkennen gibt), damit andere LAN-Clients ihn zuverlässig auch ohne DNS finden, hilft "diesem Gerät immer dieselbe Adresse zuordnen" in der FRITZ!Box, was dann die gerade zugewiesene IP-Adresse permanent für diesen Client reserviert, selbst wenn sie in der Range liegt und der Client länger als "lease time" Tage nicht zu sehen war.

Wie weit sich die Unterscheidung in der FRITZ!Box zwischen "name" (das ist der Name, den man einem Client im GUI der (Router-)Box geben kann) und "neighbour_name" (das ist der "erlernte" Name des Clients) nun irgendwann mal endgültig durchsetzt (da ändert sich ja alle Nase lang etwas, wie man auch in den Labor-Reihen bemerken konnte), muß man vielleicht noch abwarten ... zumindest hat sich bei AVM jetzt die Schreibweise "neighbour" offenbar weitestgehend durchsetzen können, mit ganz wenigen Ausnahmen:
Code:
 # grep -r eighbor
Binary file bin/avmike matches
bin/supportdata:echo "##### BEGIN SECTION neighbours Neighbors"
bin/supportdata:echo "##### BEGIN SECTION neigh_tracking Neighbor tracking"
bin/supportdata:echo "##### BEGIN SECTION neigh_tracking Neighbor tracking"
:mrgreen:

Bleibt also noch die Frage, wie man eine FRITZ!Box noch "dirigieren" kann, wenn man doch keine (W)LAN-Clients angemeldet haben soll ... dafür bietet sich der Fern(wartungs-)zugang an oder auch eine VPN-Verbindung. Dort angemeldete Clients sind nicht lokal und sollten in der Liste auch nicht als solche auftauchen.
 
Zuletzt bearbeitet:
@netspy
Betrifft: FRITZ!Box 7490 DHCP-Server spinnt
Das Problem kann ich bestätigen!
7490 mit IOS 6.50
Die Laborversionen hatte ich auch drauf, aber da wurden keine neuen Geräte verbunden.
WLan DHCP über Normalzugang problematisch...
Gerät: Iphone 5 hat sich nicht erstmalig verbunden.
Gerät: Pure Sensia hat sich nicht erstmalig verbunden.
Wlan DHCP über Gastzugang funktionierte aber sofort.
Manuelle Vergabe der IP Adresse im Endgerät funktionierte auch sofort.


mfg Michael
Ergänzung:
doppelt vergebene IPs im WLAN und LAN kann ich auch bestätigen
Ein Recovery auf 6.30 halte ich aber nicht für nötig!
 
Zuletzt bearbeitet:
Kann es auch bestätigen. DHCP spinnt hier total mit der 6.50 :mad: ... doppelt vergebene IPs im WLAN und LAN. Oder Geräte bekommen auf einmal grundlos ne neue IP.
Seit dem Update habe ich hier die merkwürdigsten Probleme im Netzwerk. Seit einem PoR spinnen jetzt auch noch die T-Home Media Receiver im Netzwerk. Jetzt schon zig mal alles neu gestartet.
WLAN lief vor dem Upate auch stabiler :(
Werde wohl morgen Recover auf 6.30 machen...
 
Identische Situation hier, aber mit 06.60. Werde jetzt auch auf 06.30 zurückgehen. Im Trace sieht das so aus, dass die Box nach einiger Zeit ca 90% aller DCHP-Discover ignoriert. Nur selten gibt es ein Offer, viele NAKs zu sehen.

- - - Aktualisiert - - -

Zu blöd. Recovery funktioniert nicht (obwohl steif und fest behauptet wird, das Gerät sei jetzt auf die vorherige FW Version zurückgesetzt worden
 
Versuch's noch einmal.
Die 6.3x FWs sind die letzten Guten ;)
 
Danke, Update verhält sich merkwürdig: Werde aufgefordert, Box von Stromversorgung zu trennen unmittelbar danach, sie wieder zu powern. Dann nach 1 ms: Alles gut, recovery hat geklappt. Aber das ging deutlich zu schnell. Hab's zweimal probiert, ohne Erfolg. Irgendein Trick?

- - - Aktualisiert - - -

Q: Habe mir jetzt das 06.30 image geladen. Hat jemand Erfahrungen damit, 06.30 aus einer 06.60 Version zu flashen? Das Recovery-Tool funktioniert nicht für mich.
 
Mit einer image-Datei kommst du nicht weiter. Warum kommst du mit der Recover-Möglichkeit nicht weiter...?
 
Tja, das weiss ich nicht so recht. ETH Verbindung zur Box steht. FW aus. Recoveryprogramm startet, fordert mich auf, die Box von Stromversorgung zu trennen. Tue es, klicke "Weiter". Dialog poppt auf: Muss ein ETH Interface auswählen. Tue es. Recovery app fordert mich auf, Stromversorgung wieder anzulegen. Tue es. Klicke "Weiter". Recoveryprogramm behauptet unmittelbar darauf, dass alles gut sei und die Version zurückgesetzt wurde....Innerhalb von 10 ms

- - - Aktualisiert - - -

OK, danke für die Motivation, es noch mal zu versuchen. Nachdem sich das Recoveryprogramm wirklich extrem uncool verhalten hat (z.B. Erfolgsmeldung, obwohl Box überhaupt nicht stromversorgt war oder Fehler -6, wenn das Kabel abgezogen wurde), habe ich dann doch mal das Wifi-Interface per Schalter deaktiviert. Offenbar hat Windows die Route über das Wifi Ifc dem Kabel vorgezogen, und das konnte wohl nicht gehen..

Danach hat es auf Anhieb geklappt: 06.30 geflasht, Einstellungen wiederhergestellt und gut.

Danke nochmal für die Hilfe. Bin mal gespannt, ob sich meine DHCP Probleme damit legen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.