[Info] FRITZ!Box 7490 Labor-Firmware Version 113.06.36-31629 vom 20.10.2015

@Neo the Hacker:
Hast Du an den DHCP-Server-Einstellungen etwas geändert? Auch wenn der Zusammenhang nicht ins Auge springen mag, könnte das der Grund für die automatische Deaktivierung sein. Wenn das regelmäßig bei allen erfolgte, wäre das sicherlich schon länger aufgefallen, vor allem wenn das Problem schon seit mehreren Versionen bei Dir auftritt.
 
Also mit VPN habe ich keine Probleme gehabt, läuft gut.
 
Nein, meine Box hat seit eh und je die 192.168.0.1 und DHCP startet bei 192.168.0.100 und endet bei 192.168.0.150. Habe ich seit Kauf vor rund 1 Jahr nicht mehr geändert. Aber das Problem das einfach das Häkchen bei meinem Benutzer bei VPN entfernt wird hatte ich bereits bei den letzten 2 Betas. Es geht tagelang gut und plötzlich komme ich mit meinem Smartphone nicht mehr drauf bei aktivierung von VPN und sehe dann das der Haken wiedermal verschwunden ist... Ob es evtl. direkt beim Update passiert habe ich noch nicht getestet - werde ich mal beobachten wenn das nächste kommt da ich gerade VPN wieder neu aktiviert hab
 
Erweitere die DHCP Range mal bis 192.168.0.221. Das war ein (so von mir interpretierter) Hinweis von PeterPawn.

Ich hatte nach einer kürzlichen Firmware Aktualisierung ebenfalls das Problem, dasss VPN nicht mehr lief. Meine DHCP Range war auch niedrig begrenzt (bis 192.xxx.xxx.49). Jetzt bekommt mein Android Phone bei VPN die IP 192.xxx.xxx.221 zugeteilt und es läuft alles reibungslos. Anscheinend sind die niedrigeren IP-Adressen für LAN/WLAN reserviert. *Achtung: Gefährliches Halbwissen *
 
Habe ich seit Kauf vor rund 1 Jahr nicht mehr geändert.
Ok, meine Schuld, da war ich wohl zu vage (oder doch eher Waage? egal) ... die Frage zielte natürlich darauf, ob Du die DHCP-Einstellungen ggü. dem AVM-Standard (das wäre 20-200) geändert hast und das hast Du ja offensichtlich. Als "Änderung in letzter Zeit" reicht dann auch das Update auf diese Firmware-Version aus, damit das "bisher ging's ja auch" keine wirkliche Rolle mehr spielt.

Vielleicht überprüfst Du ja doch noch einmal Deine VPN-Konfigurationen unter dem Aspekt der vergebenen IP-Adressen.

Der ctlmgr prüft offenbar inzwischen da irgendetwas zusätzlich auf Konsistenz, was auch nicht so ganz abwegig ist, denn für jeden VPN-Client, der da kommen könnte, muß ein Eintrag in der Routing-Table gemacht werden, damit die Daten für ihn über "dev dsl" gehen und nicht - wie es ansonsten der Fall wäre anhand von Adresse und Maske - über "dev lan" und gleichzeitig wird Proxy-ARP seitens der Box für die Client-Adresse eingerichtet.

Ich habe diese von Dir berichteten Probleme bisher nur gesehen, wenn da IP-Adressen <= 200 für einen Client vergeben waren. Aber das ist - zumindest nach meiner Interpretation - noch Baustelle und AVM schraubt da immer mal wieder auf's Neue. Meines Erachtens haben die Leute, die ihre DHCP-Range ggü. der Standardeinstellung nicht geändert haben, nach einem einmaligen neuen Einrichten der VPN-Verbindungen für Benutzer (die anderen brauchen keine Reservierungen von IP-Adressen) keine weiteren Probleme beim nächsten Update.

Die derzeitigen Änderungen durch AVM sollen offenbar frühere Fehler ausräumen, bis einschließlich 06.30 führt z.B. das Einrichten einer VPN-Verbindung für einen Benutzer zu inkonsistenten Einstellungen in der FRITZ!Box, wenn keine IP-Adresse nach der DHCP-Range mehr frei ist im gewählten Netzwerk-Segment. Dann wird zwar beim Benutzer in der ar7.cfg die Einstellung "vpn_access = yes;" gesetzt (daraus resultiert der Inhalt der VPN-Checkbox im GUI beim Benutzer), aber es gibt keine passende VPN-Konfiguration in der vpn.cfg und damit kann sich der Benutzer natürlich auch nicht einwählen. Offenbar ist dieser neue Code bei seinen Plausibilitätstests noch nicht ganz sattelfest ... es ist aber sicherlich auch nicht ganz einfach, dafür einen passenden Bereich automatisch zu ermitteln (und den mit schon vorhandenen Konfigurationen abzugleichen - da vermute ich die Ursache für die Deaktivierungen bei Dir) und ich wünschte mir, AVM hätte da einfach eine zusätzliche Einstellmöglichkeit für die IP-Adressen für VPN-Clients im GUI geschaffen (meinetwegen im Expertenmodus versteckt), wo man diesen Bereich wenigstens ablesen, am besten aber nach eigenen Wünschen (im Rahmen des Segments, was für das LAN konfiguriert ist) einstellen könnte.

EDIT: Wenn ich recht haben sollte mit meiner Annahme der Deaktivierung aufgrund von Problemen mit der IP-Adresse, dann sollte das eigentlich nach jedem Neustart der Box (event. sogar des ctlmgr, den macht der "vernünftige Benutzer" aber ja ohnehin nicht einzeln, gibt ja kein Telnet mehr) auftreten und damit implizit natürlich auch nach Updates ... einen Versuch wäre es sicherlich wert, das mal zu prüfen und dann muß man ggf. nicht auf das nächste Auftauchen des Fehlers warten.
 
Zuletzt bearbeitet:
Naja ich habe den DHCP IP Range aber bewusst so gewählt denn genau bei 200 beginnen bei mir diverse Geräte die Feste IPs haben. Ich wollte damit vermeiden das der DHCP eine Adresse rausgibt die ein Gerät als feste zugewiesen hat - oder kann das nicht passieren. Aber das wäre ja wohl wirklich lächerlich wenn AVM da so einen Fehler drin hat und das am DCHP Range liegt...
 
Deine eigene Bewertung der Situation (und auch Deine Einschätzung eines Problems als "lächerlich") sei Dir unbenommen ... ich wollte nur helfen. Wenn Dir das nicht paßt, ignoriere es einfach.

Wenn jemand hier dann Deine "bewußte Entscheidung" - die schon seit Urzeiten, genauer seit der Einführung des GUI-Assistenten für VPN-Konfigurationen und der Möglichkeit, eine VPN-Konfiguration für einen Benutzer einfach per Checkbox zu aktivieren, mit der Vorgehensweise von AVM "im Clinch" liegen dürfte - seinerseits als etwas "unreif" ansieht, wirst Du ihm das ja auch nicht verübeln. Wenn das nur unglücklich gewählte Formulierungen waren, ist ja alles gut ... auf mich wirkt das im Moment allerdings etwas trotzig, aber mein Eindruck kann ja auch täuschen und ist alles andere als maßgeblich.

Noch als "Tipp" meinerseits an andere Leser:
Wenn man neben der Vergabe von IP-Adressen über den DHCP-Server der FRITZ!Box noch statische IP-Adressen in seinem LAN vergeben möchte und gleichzeitig aber auf die "Dienste" der VPN-Konfiguration über das GUI nicht verzichten will (auch das kann man logischerweise "von Hand" erledigen - nur die Harten komm'n in'n Garten), dann sollte man die Range am unteren Ende begrenzen und für die statischen Adressen eher den Bereich vor der eingestellten DHCP-Range verwenden. Wie das AVM (derzeit und künftig) regelt, wenn der DHCP-Server der FRITZ!Box gar nicht aktiv ist, weiß ich auch nicht ... wenn ich raten sollte, würde ich sagen, daß die eingestellten Werte der Range trotzdem als Anhaltspunkt herangezogen werden. Wer sich bemüßigt fühlt, seine eigene Netzwerkstruktur aufzubauen und einzustellen, der muß ggf. eben auch damit rechnen, daß dann nicht mehr alles andere auch automatisch ablaufen kann oder es dabei zu Problemen kommen kann - das sollte mit ein wenig eigener Überlegung aber auch jedem klar sein, der sich so eine "customized configuration" zutraut (meine Meinung).

Ob AVM das nun besser dokumentieren müßte, liegt sicherlich wieder im Auge des Betrachters ... das "Verstecken" einiger Konfigurationsmöglichkeiten in der "Expertenansicht" (heißt inzwischen nur noch "erweitert", braucht auch tatsächlich "erweiterte Kenntnisse" beim Benutzer, nicht unbedingt "Expertenwissen") erfolgt sicherlich nicht ganz unabsichtlich. Wenn man alle diese Spezialfälle in Form eines Handbuchs dokumentieren wollte, erreicht das irgendwann auch "Brockhaus-Dimensionen" (für die jüngeren Leser, das ist eine (inhaltlich richtige und gute) "Wikipedia"-Version auf richtigem Papier, zu "Büchern" gebunden, diese wiederum sind als maschinell hergestellte Erzeugnisse bekannt (und eine alte Handwerkskunst) seit dem Mittelalter) und dann liest das ohnehin kein Benutzer mehr - da ist es sicherlich schwierig, die Balance zu halten.
 
Zuletzt bearbeitet:
Ich habe nach wie vor Probleme mit dem 5GHz Frequenzband, immer wieder bricht die Verbindung ab, wenn ich dann neu Starte, geht es wieder ein paar Stunden , bis das ganze von vorne beginnt. Hat noch jemand diese Probleme mit 5 GHz
 
Bei mir ist das 5 GHz Netz meistens auch total lahm oder zwar verbunden, aber ohne Internetzugriff.
 
Hmmm.....also ich verwende 5GhZ mit meinem Laptop, jeden Tag min. 8 Stunden zum Arbeiten, und es läuft super-stabil und performant.
 
@michael2009
@rabe85
da bin ich ja froh das ich nicht alleine bin, druck und weg...:(
 
...

Noch als "Tipp" meinerseits an andere Leser:
Wenn man neben der Vergabe von IP-Adressen über den DHCP-Server der FRITZ!Box noch statische IP-Adressen in seinem LAN vergeben möchte und gleichzeitig aber auf die "Dienste" der VPN-Konfiguration über das GUI nicht verzichten will (auch das kann man logischerweise "von Hand" erledigen - nur die Harten komm'n in'n Garten), dann sollte man die Range am unteren Ende begrenzen und für die statischen Adressen eher den Bereich vor der eingestellten DHCP-Range verwenden.
Genau so mach ich das, und hab seit jeher keine Probleme damit. Irgendwo muss die FB ja eine IP Adresse für die VPN Clients herholen, und da sind die Adressen hinter dem oberen Ende der DHCP-Range meiner Meinunng nach eine ziemlich vernünftige Wahl. Es gäbe zwar auch andere Möglichkeiten (Adressen von innerhalb der DHCP Range, oder eine spezielle VPN Range), aber für mich ist die aktuelle Methode vollkommen ausreichend für ein solches Gerät.
Wie das AVM (derzeit und künftig) regelt, wenn der DHCP-Server der FRITZ!Box gar nicht aktiv ist, weiß ich auch nicht ... wenn ich raten sollte, würde ich sagen, daß die eingestellten Werte der Range trotzdem als Anhaltspunkt herangezogen werden.
Kann ich bestätigen. Ich habe einige Zeit einen kleinen WLAN Access Point mit einer Tomato Firmware als DHCP Server benutzt. Damit konnte ich meinen eigenen DNS Server per DHCP kundgeben (die FB sieht ja alle Geräte in der DNS Domäne fritz.box...).
Auch mit so einer Konfiguration verteilt die FB IP Adressen and VPN Clients, und zwar auch hier die hinter dem Ende der (nicht aktiven) DHCP Range.
Seit die neuen Labors nun die Konfiguration eines eigenen DNS Server für die DHCP Clients erlaubt, brauch ich das nicht mehr - wieder ein Gerät das ich abschalten kann :)

Auch der Bemerkung das man für eine Expertenkonfiguration auch das nötige Expertenwissen im Gepäck haben sollte, kann ich nur voll und ganz zustimmen. Ich habe von Beruf's wegen mit solchen Dingen zu tun, und ich kann mir in der Regel sehr gut selbst helfen wenn mal etwas nicht so reagiert wir ich mir das vorstelle - notfalls durch die Analyse eines Netzwerkmitschnitts.
 
Bug: USB-Tethering und Problem No-Inbound-RTP-Streams

das Problem "USB-Tethering und Problem No-Inbound-RTP-Streams" besteht bei dieser FW-Lab-Version ebenfalls
Fehlerbild: sämtliche VOIP-Telefonate funktionieren bei Internet-Zugang via USB-Tethering (Android Smartphone, Huawei HiLink Mobilfunk-Stick) nur mit Outbound-Audio-Kanal.
bei Einschalten des Paketmitschnitts auf usb0-Schnittstelle funktionieren beide Audio-Kanäle
Details siehe:
http://www.ip-phone-forum.de/showthread.php?t=281785&p=2123206&viewfull=1#post2123206
http://www.ip-phone-forum.de/showthread.php?t=281785&p=2123404&viewfull=1#post2123404

Feedback/Bugreport bei AVM eingekippt.

next Step: Test mit neuer Lab-FW http://www.ip-phone-forum.de/showthread.php?t=282027

Gruß
Splenditnet
 
@ PeterPawn :
Ich habe mit meiner Aussage "lächerlich" in keinster Weise deinen Beitrag bzw. deine Erklärung/Hilfestellung gemeint. Ich finde es lächerlich das AVM eine deartige Vorraussetzung für die Nutzung vom VPN hat denn es macht meiner Meinung nach keinen Sinn. Und wenn Sie das schon machen sollten Sie das auch dokumentieren und den Kunden nicht rätseln lassen was hier los ist. Komisch ist aber ja auch das es ne ganze Weile geht, irgendwann aber nicht mehr. Ich aktvier es nun mal wieder und schaue ob es nur durch Updates deaktiviert wird.
 
Meine Fritzbox 7490 läuft immer noch unter FRITZ!OS 06.30
Ich habe Probleme bei der Telefonie, während Verkehr über eine VPN-Verbindung läuft. Da scheint die Priosierung nicht richtig zu funktionieren. Ist dieses Problem bekannt und evtl. mit der aktuellen Labor-Firmware behoben? Dann könnte ich ja den Versuch wagen, diese auch zu installieren.
 
@Neo:
Das hatte ich gar nicht auf mich bezogen (schon auf das Problem, was AVM da zu lösen hat), wäre aber auch kein Grund für persönliche Befindlichkeiten gewesen ... und ganz ehrlich - für mich haust Du mit dem nachgeschobenen: "... es macht meiner Meinung nach keinen Sinn." noch einmal in dieselbe Kerbe, ich lese daraus eine Erwartungshaltung in Bezug auf diese Labor-Version, die ich schlicht für überzogen halte.

Du hast eben eine spezielle Konfiguration, die hier Probleme bereitet ... wenn AVM das bis zum Release in den Griff bekommt, ist es gut, wenn nicht eben auch. Wenn 1 Promille der Kunden dasselbe Problem haben sollte, bleibt das für mich immer noch eine Randnotiz ... ärgerlich für den Einzelnen, aber der sollte sich dann eben auch zu helfen wissen, wenn er so etwas in Angriff nimmt im eigenen LAN.

Wenn Du einen Einwand gegen dieses Vorgehen (mit der Reservierung der IP-Adressen) seitens AVM hast und einen Vorschlag, wie man das besser lösen könnte, den wir noch nicht hatten, dann lass' lesen.

Aber so vollkommen ohne Begründung und in Anbetracht der Tatsache, daß es bei der derzeitigen VPN-Implementierung nun einmal eine reservierte Adresse aus dem LAN-Segment braucht, wenn so eine Client-LAN-VPN-Verbindung konfiguriert werden soll, ist das immer noch nichts - auch das ist nicht persönlich gemeint, es soll Dich eher dazu auffordern, Deine These dann auch zu begründen.

An so einem "Automatismus" bei der VPN-Konfiguration hängen dann eben jede Menge zusätzliche Probleme, die man alle berücksichtigen muß, wenn man so etwas umsetzt. Das geht z.B. schon dort los, wo der Admin der Box auf einmal auf die Idee kommt, das lokale Netz-Segment einfach mal in einen anderen Adressbereich zu verschieben ... jetzt muß man dann auch alle diese VPN-Einträge für die Benutzer theoretisch mit ändern oder eben deaktivieren oder ggf. sogar löschen. So ein VPN-Eintrag hat auch nicht nur eine einzelne Stelle (remote_virtualip), die zu ändern ist, das zieht sich bis in die "accesslist" durch, wenn nur die Netzwerkmaske alleine schon geändert werden sollte.

Auch die Entscheidung, was beim partiellen Übernehmen der Daten aus einer anderen Sicherung passieren soll mit solchen VPN-Verbindungen (die nicht zur LAN-Konfiguration passen) oder das Synchronisieren eines geänderten Benutzerkennworts (das steht in der VPN-Konfiguration noch einmal im "xauth"-Abschnitt) sind alles "Baustellen", die man berücksichtigen muß (prompt fällt mir noch die Prüfung beim "cfgtakeover" ein, ob ein entsprechender Benutzer überhaupt existiert, die Frage, ob das derselbe wie in der originalen Box ist (boxuser_id steht in der VPN-Konfiguration, nicht der Benutzername, diese ID ist von der Reihenfolge beim Anlegen abhängig und kann eben dann differieren) und was man machen soll, wenn das nicht paßt, ist da noch gar nicht im Fokus) und wenn AVM sich jetzt ans Werk macht, da die gröbsten Schnitzer zu korrigieren, finde ich das alles andere als lächerlich. Die Alternative, einfach nur noch "handgeschöpftes VPN" zuzulassen, wenn irgendetwas "Unerwartetes" geändert wurde, ist sicherlich auch nicht unbedingt im Sinne aller AVM-Kunden.

Auch die Forderung nach einer Dokumentation kann ich durchaus nachvollziehen (im passenden Rahmen, meinetwegen in der KB), aber dazu muß das vielleicht erst einmal "stable" und eine Release-Version sein, damit sich so etwas auch lohnt bzw. damit diese Forderung eine gewisse Berechtigung hat. Das ist hier eben eine Labor-Version, da muß man mit solchen Problemen tatsächlich rechnen und im Idealfall kann man durch eigene Tests und Fehlermeldungen an AVM dazu beitragen, daß es solche Probleme wie bei Dir nicht undokumentiert (oder am Ende auch gar nicht) in eine Release-Version schaffen.

Wie gesagt, just my 2 cents und ich bin immer wieder auf's Neue erstaunt, wie wenig sich einige darüber im Klaren sind, daß eine Labor-Version eben nicht "stable" ist und vom Hersteller an dieser Stelle wahre Wunder erwarten, was die initiale Funktion einer neuen (Beta-)Firmware-Version betrifft. Wenn die nicht bereits beim Starten Späne macht, dann ist das schon mal gut ... und inzwischen hat diese hier in meinen Augen auch eine Stabilität und Reife erreicht, daß es mehr um das Ausmerzen kleinerer Mängel als um grundlegend fehlende Funktionen geht.
 
@PeterPawn
Hat sich eigentlich bzgl. #2691 was Neues ergeben?
Ich würde so gerne die aktuelle Labor mit freetz nutzen :):):)
 
@BenGurion:
Kann ich überhaupt nichts zu sagen, ich bin da raus ... ich rate mal ganz wild und sage (aus der Beobachtung der Changesets), daß es schlicht an Manpower fehlen dürfte/wird, wenn es von AVM die finale Version der 06.36 (wie auch immer die nummeriert sein wird) geben sollte und die Frage aufkommt, wie schnell Freetz an die neue Version angepaßt werden kann.

er13 ist da m.W. weitgehend Einzelkämpfer und mit der Aktualisierung von vorhandenen Paketen und kleineren Änderungen für das Vereinheitlichen von Interfaces/Einstellungen/Makefiles beschäftigt, wobei auch das in letzter Zeit ziemlich nachgelassen hat, aber heute gab es erst wieder einen Schub (eigentlich gestern).

Nun ist ja die auffälligste Änderung der neuen Version das - für Freetz ziemlich irrelevante - GUI, aber auch unter der Haube hat sich schon einiges getan (vom anderen Vorgehen bei Updates mal ganz abgesehen), das wird sicherlich seine Zeit brauchen.

Mangels Interesse fehlt mir auch vollkommen eine Vorstellung, wieviele Dateien in der neuen Firmware jetzt wirklich betroffen wären, wenn man z.B. die alten Patches auf eine neue Firmware anwenden wollte ... ich behaupte mal kühn, daß da mindestens die Hälfte nicht mehr passen wird - aber nicht weil ich es probiert hätte, sondern auf der Basis der beim Lesen der AVM-Dateien festgestellten Unterschiede.

Auch der neue Kernel bei der 7490 macht das sicherlich nicht einfacher - vor der Freigabe der OpenSource-Dateien durch AVM kann man einiges an Einstellungen in der Konfiguration der uClibc und des Linux-Kernels nur erraten und durch Probieren sich einer passenden eigenen Konfiguration nähern. Ich weiß nicht, ob er13 da dran ist oder ob er das auch für zu viel Aufwand hält (mir geht es so, ich brauche aber auch für meinen Bedarf nur eine Toolchain für ein paar wenige eigene Pakete - keinen eigenen Kernel - und diese Pakete bzw. die uClibc mit den Einstellungen beim 2er-Kernel funktionieren überwiegend auch ziemlich gut mit dem 3er-Kernel) - die Kommunikation mit er13 ist da nicht so ausgeprägt bei mir.

Ich würde ja vorschlagen, ihn einfach über das Trac-System zu fragen (aber auch das Freetz-Unterforum dürfte er regelmäßig besuchen), wenn man das vorsichtig formuliert und ordentlich macht, ist das sicherlich auch nicht "offending" und eine Perspektive/Zeitschiene für Freetz bei der 7490 interessiert wahrscheinlich noch andere, auch wenn er naturgemäß nicht beeinflussen kann, wann AVM die OpenSource-Dateien bereitstellt.

Paßt zwar nicht in diesen 7490-Thread ... aber hat mal jemand mit der 7390-Laborversion (seit gestern abend im Trunk möglich) ein Freetz-Image für eine 7390 gebaut und getestet?

Die dort event. notwendigen Änderungen (z.B. beim Freetz-Mount und anderen Modifikationen von AVM-Skripten) dürften große Ähnlichkeit mit dem aufweisen, was bei der 7490 später auch notwendig sein wird ... das wäre eine Chance, schon mal vorzuarbeiten, auch wenn die OpenSource-Dateien für die "neue 7490" noch nicht verfügbar sind.

Persönlich hätte ich auch eher einen neuen Branch für den Wechsel auf Linux mit 3er-Kernel erwartet (bzw. für die neue Oberfläche), weil das ein weiteres Aufblähen vermeiden könnte in meinen Augen, aber das ist ebenfalls nicht mein Tisch. Schon das Hinzufügen von Versionen mit neuem GUI und das Anpassen der ganzen Remove- und GUI-Patches an diese zusätzlichen Möglichkeiten, dürfte eine echte Herausforderung werden, wenn man das alles so umsetzen will, daß es von 04.irgendwas bis zum nächsten Release alles aus demselben Source-Code funktioniert.

Ich komme leider nicht selbst dazu, wenigstens mal mit einer 7390 zu testen (bzw. nur den Build dafür erst mal) ... das ist auch nicht so richtig meine Baustelle oder die Richtung, wohin ich das entwickeln will. Die NOR-Boxen sind für mich Alteisen und weitere Bemühungen dort zu investieren, ist für mich (meine persönliche Einschätzung, aber ich kann es mir eben auch leisten, den gedanklichen Schnitt zu vollziehen, ohne jemanden zurückzulassen) verschwendete Energie. Die Vorteile der NAND-Boxen in puncto Modifikation sind für mich so eklatant, daß ich nicht mehr zurückblicken will.

Sorry, daß das schon wieder so lang ist, die kurze Antwort: "Keine Ahnung." hätte es ja vielleicht auch getan. Ich schwafele auch nicht nur, um mein Unwissen an dieser Stelle zu übertünschen, ich wollte nur Überlegungen aufschreiben, die ich schon mehrfach für mich selbst angestellt hatte.
 
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.