[Info] "Wartungs-" Laborversionen für 7272, 7390 und 7412

@deoroller
Ja, man könnte einen Speedport probieren, den ich aber nicht habe. Oder ein Bridge-Modem vorschalten, das habe ich auch nicht....
Wird aber langsam offtopic, denn hier geht es eigentlich um das "Wartungsupdate" der genannten FritzBoxen.

@Daniel Lücking
Profil habe ich 109.344/42.000 und ankommen tut die Leitungskapazität ca. 102.000/37.000.
 
Wie wäre es mit einer 7412? Gibt es Kostengünstig.
 
In Kombination mit VDSL100 (Vectoring) immer noch häufig sporadische Sync-Abbrüche.
Manchmal läuft die Verbindung 2 Tage fehlerfrei, dann wieder Sync-Verluste im 5-Minuten Takt.

Exakt das Problem habe ich auch. Ich denke AVM hat keine Lust, die ganzen Geräte, die noch in der Garantie sind, gegen eine 7490 zu tauschen. Da halten die den Ball schön flach.

Bei mir hat es nach vielem rumprobieren geholfen, unter Störsicherheit INP und RFI auf maximale Stabilität zu setzen. Störabstandsmarge ist noch beim max. Performance.
Dadurch habe ich keinerlei Einbußen in der Geschwindigkeit, aber nur noch ca. 2 - 3 Syncverluste pro Woche. Das ist gerade so akzeptabel.
Alle 2 Wochen starte ich die Box (automatisiert via Cron) neu, denn nach ca. 2 - 3 Wochen nehmen die Probleme mit den Syncverlusten zu.

Die Download/Uploadrate, die die 7390 schafft sind 85/35. Eine 7412 schafft 102/35.

Die Begründung, die man bzgl. der Sync-Verluste liest sind: Die Box muss Berechnungen, die normalerweise der DSL Chip übernimmt (Kompensation des Übersprechen bei VDSL Vecotring) via CPU berechnen, dadurch fliegt die Box raus, wenn sie viel Last hat und/oder viel Übersprechen stattfindet.
Bei maximaler INP und RFI interpretiert sie dann ihre ureigenen Rechenprobleme als externe Störungen und hält die Leitung trotz packet-drop am Laufen.
Daher ist auch zu beobachten, dass die Meisten Sync-Verluste zwischen 18 und 22 Uhr sind, weil dann die meisten Kunden surfen und die Berechnungen der CPU größer werden, weil mehr Übersprechen zwischen den Teilnehmern stattfindet.

Sobald die finale Version des Wartungsupdate verfügbar ist, werde ich das Freetzen und auf meine Ersatz 7390 packen. Dann kopiere ich die Config auf die neue Box und wenn es Probleme gibt, wechsel ich zurück auf die Alte.
 

Anhänge

  • Bildschirmfoto_2018-07-05_17-48-10.png
    Bildschirmfoto_2018-07-05_17-48-10.png
    19.6 KB · Aufrufe: 40
Zuletzt bearbeitet:
Daher ist auch zu beobachten, dass die Meisten Sync-Verluste zwischen 18 und 22 Uhr sind, weil dann die meisten Kunden surfen und die Berechnungen der CPU größer werden, weil mehr Übersprechen zwischen den Teilnehmern stattfindet.
Ich bezweifle mal, dass das als Begründung herhalten kann denn bei DSL werden aufgrund der Kodierung immer Daten übertragen, egal ob der Kunde nun tatsächlich über die DSL-Verbindung Daten überträgt oder nicht, das macht keinen Unterschied, auch nicht für das Übersprechen (was bei Vectoring rausgerechnet werden soll).
Hinzu kommt, dass die Berechnung allein vom Vectoring-Prozessor im DSLAM übernommen wird da im US meiner Kenntnis nach Vectoring nicht verwendet wird bei VDSL2. Wenn dann muss das CPE allerdings wohl die Qualität der "Herausrechnung" ermitteln und dies dem DSLAM mitteilen was natürlich ein Mehraufwand beim CPE ist gegenüber Anschlüssen ohne Vectoring.

Ich könnte mir allerdings schon eher vorstellen, das bestimmte Kunden ihr CPE nicht immer eingeschaltet haben sondern nur wenn sie Internet nutzen möchten (viele nutzen Telefonie ja auch nur noch per Mobilfunk). Und wenn dann zu bestimmten Zeiten mehr CPEs im Leitungsbündel aktiv sind als sonst könnte das vielleicht zu diesen Resync-Effekten führen bei bestimmten CPEs (die mit Broadcom-Chipsatz sind da ja eher unproblematischer).
 
Ich hatte jetzt im Bekanntenkreis einen instabilen Vectoring-Anschluss mit 100Mb/s (providerseitig auf 50Mb/s reduziert). Die von 1und1 mitgelieferte 7412 hatte zeitweise so viele Unterbrechungen, dass telefonieren nicht möglich war. - Habe leider nicht auf die Linecard an der Gegenstelle geachtet.

Mit der 7590 hat das testweise wochenlang problemlos funktioniert.

Ich habe gestern die fritzbox-7412-labor-55354 eingespielt. Das sieht bis jetzt sehr gut aus. Es scheint zumindest in meinem Fall, dass das Update den benötigten Unterschied zur Release-Version macht.
 
@creon

Die Resync basieren einfach auf einer inkompatibilität zwischen DSLAM und Fritz!Box. Irgendwo ist da ein Fehler im VDSL Treiber der Fritz!Box. Tritt aber scheinbar nur bei grenzwertigen Leitungen und bestimmten DSLAM LineCards auf. Ich habe auch ein LineCard Firmwareupdate von 177.140 auf 192.85 bekommen, hab aber nicht merh getestet ob der Sync jetzt nicht wieder stabil ist.

Ich hatte die Resyncs mit der 7412 ebenfalls als Vectoring aktiv wurde (44Mbit Sync rockstable vor und 76Mbit Instabil im Download nach Vectoring Aktivierung im April).
Daraufhin hatte ich gegen eine 7362SL getauscht (finale Firmware 06.83, gleicher VDSL Treiber 1.100.135.11 wie 7412) mit den gleichen Problemen.
Die Beta für die 7362SL (neuerer VDSL Treiber 1.100.136.15) aufgespielt, die Resync waren komplett beseitigt, sync sogar etwas besser, 3Mbit mehr Down und 2 Mbit mehr Upload.

Nachbarn (genau ein Haus weiter, gleiche Leitungsführung) haben eine 7490 mit der letzte Final (VDSL Treiber 1.100.135.15). Da kommt ein Resync nur noch ganz selten vor (2 Resyncs / 20 Tage laut Log).
Das Wartungsupdate habe ich der 7412 auch verpasst leider ohne Besserung (gleicher alter VDSL Treiber).

Ich hoffe das AVM Fritz!OS 7 auch für die 7412 bringt oder wenigstens eine aktualisiert 06.8x Firmware mit aktuellerem VDSL Treiber. Dann funktioniert die auch wieder.

@NDiIPP

Vectoring wird natürlich auch im Upstream verwendet, siehe DSL Informationen der Fritz!Box G.Vector ist full im Up und Download. Wäre auch schwachsinn das nicht so zu realisieren.
Die Berechnungen führt natürlich der DSLAM aus weil nur dieser die ganzen Leitungsinformationen hat. Die Fritz!Box muss nur Informationen weiterleiten bzw. Anweisungen Umsetzen.
Und der Verdacht mit dem Rechenaufwand auf der CPU der Box: Da läuft ein Linux. Die bekommen Priorisierung schon hin. Der Prozess wird einfach eine höhere Priorität als WebServer/Routing zugewiesen und schon macht der Linux-Kernel den Rest.
 
Irgendwo ist da ein Fehler im VDSL Treiber der Fritz!Box.
Oder der Software im DSLAM. Das ist meines Wissens nach bis jetzt noch nicht eindeutig geklärt (bzw. fraglich ob wir die eigentliche Ursache jemals erfahren werden).

Vectoring wird natürlich auch im Upstream verwendet, siehe DSL Informationen der Fritz!Box G.Vector ist full im Up und Download. Wäre auch schwachsinn das nicht so zu realisieren.
Vectoring so wie im DS wird im US nicht genutzt, auch wenn da in den DSL-Details "full" bei G.Vector steht. Geht imo auch nicht, denn dazu müsste jedes CPE wissen was die anderen CPEs zur gleichen Zeit gerade im US senden, das geht imo nicht (ohne Zeitmaschine).

Und der Verdacht mit dem Rechenaufwand auf der CPU der Box: Da läuft ein Linux. Die bekommen Priorisierung schon hin. Der Prozess wird einfach eine höhere Priorität als WebServer/Routing zugewiesen und schon macht der Linux-Kernel den Rest.
Mittlerweile schaffen die das, ja. Aber mit den ersten Firmwareversionen, die Vectoring unterstützt hatten bei der 7390, funktionierte das mit der Priorisierung (trotz Linux-Kernel) nicht so wie gedacht. Außerdem ist es auch "nur" der Linux-Kernel der zum Einsatz kommt, viele Kernfunktionen werden aber bei der Firmware von AVM von proprietärer Software übernommen (multid, dsld usw.) wo ein Dienst oder Prozess teilweise auch mehrere Aufgaben gleichzeitig übernimmt. Und da beispielsweise der dsld eben gleich mehrere Aufgaben übernimmt hilft das alleinige priorisieren dieses Prozesses wohl nicht weiter um die Probleme zu lösen.
Aber mittlerweile funktioniert das bei der 7390 mit der Priorisierung bei Vectoring wohl. Hat aber teilweise auch zur Folge, dass man bei paralleler Nutzung von WLAN und VoIP noch froh sein kann von den 90 oder 100MBit/s bei VDSL100 noch 30 oder 40MBit/s nutzen zu können... :rolleyes:
 
Die bekommen Priorisierung schon hin. Der Prozess wird einfach eine höhere Priorität als WebServer/Routing zugewiesen und schon macht der Linux-Kernel den Rest.
Du irrst aber, wenn Du der Ansicht bist, eine FRITZ!Box macht außer Vectoring (bzw. dem Teil davon, den eine 7390 wg. ihres Alters wohl nicht ausschließlich in der FPE macht) nichts anderes als "Webserver" und "Routing" oder irgendwelche anderen, absolut nicht zeitkritischen Dinge.

Man muß sich nur mal in den Kernel-Quellen ansehen, was AVM da (auch noch bei neueren und leistungsfähigeren Chipsets, wo man per se gar keinen "Druck" in dieser Richtung vermuten würde) an Aufwand treibt, um die letzten Performance-Bottlenecks zu finden und damit u.a. - mal so als Beispiel - das TDM für die DECT-Geräte zeitgerecht auf die Reihe zu bringen (bei zu großen Abweichungen droht "kernel panic") ... da muß das System dann schon fast echtzeitfähig sein bzw. zumindest mit halbwegs garantierten Latenzen arbeiten beim Interrupt-Handling, was schon mal ein Antagonismus zum "dann kriegt das einfach eine höhere Priorität und dann läuft das schon irgendwie" ist. Wenn Interrupt-Handling angesagt ist, findet es halt statt ... und anderes bleibt liegen.

Da kann man nicht einfach ankommen und festlegen, daß ab sofort die Unterstützung für das Vectoring über allem anderen steht ... dann geht am Ende an anderen Stellen nämlich auch nichts mehr. Und es ist wohl unbestreitbar, daß die 7390 bei der Umstellung auf Vectoring auch einen gewaltigen Sprung bei der CPU-Auslastung macht und (bei entsprechender Nutzung von Funktionen und vorhandenen Clients) ziemlich am Anschlag läuft ... das wurde häufig genug beobachtet und berichtet und zwar auch unabhängig von einem Firmware-Update zum Zeitpunkt dieses "Lastwechsels".
 
Zuletzt bearbeitet:
  • Like
Reaktionen: creon und NDiIPP
@PeterPawn

Die 7390 hatte ich weit vor der Vectoring-Freischaltung bereits "entsorgt" da kenne ich das "Problem" also nicht direkt. Hier war aber von der 7412 die Rede. Eine 7390 mit Singel Core Uralt Chip und eine 7412 mit einem weit neueren Dual-Core (oder sogar mehr?) Prozessor sollte man da nicht vergleichen.

Ich konnte bei der 7412/7362SL keine merkliche Erhöhung der CPU Last feststellen nach der Aktivierung von Vectoring.
 
@Nero FX:
Es ging eben nicht nur um die 7412 (auch nicht bei @creon), sondern auch um die 7390 ... bitte lies einfach #63 noch einmal. Auch bei Deiner Replik hast Du diesen Unterschied noch nicht gemacht. Bei der 7390 kommt eben nur noch erschwerend hinzu, daß ihr IKF6850 nie wirklich für G.993.5 gedacht war und vermutlich alles, was das Vectoring betrifft, tatsächlich der CPU aufgebürdet wird (wenn jemand das etwas genauer weiß und irgendwelche anderen Informationen hat, lese ich diese gerne).

Ich habe meinerseits auch nicht geschrieben, daß die Ursachen für die berichteten Sync-Verluste ausschließlich in der CPU-Belastung liegen ... wenn Du noch einmal nachschaust, wirst Du feststellen, daß ich nur gegen Deine "einfache Lösung" argumentiert habe, daß man nur die Priorität irgendeines Prozesses unter Linux ändern müsse (von Rücksichtnahme auf die Belange anderer Features stand bei Dir nichts) und der Rest würde sich dann schon von alleine regeln.

Und die Aufstände zum Profiling und zum schnelleren Kontextwechsel macht AVM eben auch nicht nur in den Linux-Versionen für die 7390, sondern genauso (eigentlich sogar noch etwas aufwändiger) in denen für VR9- und GRX-Boxen - habe ich aber oben bereits geschrieben und wenn Du das überprüfen möchtest, sieh Dir einfach die Quellen an, speziell zum Thema "yield context".

Da hat AVM (auf der Basis von Lantiq-Vorarbeiten, afaik) einen komplett eigenen Mechanismus implementiert, der Kontextwechsel (zumindest kurze zur Interrupt-Behandlung im Kernel - auch ein guter Teil des AVM-eigenen DSL-Daemons läuft direkt auf Kernel-Ebene im "kdsldmod.ko", mit einem Userland-Komplement im "dsld"-Prozess) deutlich weniger "kostenintensiv" machen soll, dafür aber auch ein paar Möglichkeiten bei der Fehlerbehandlung und -protokollierung unter den Tisch fallen läßt bzw. diese können dann nicht benutzt werden, weil kein "vollständiger" Kontextwechsel vollzogen wird.

Das Thema einer max. Latenz bei der Behandlung von Hardware generell (und nicht nur bei Interrupts, wobei das hier besonders wichtig wird, wenn es keine "Queues" gibt, wo der nächste Interrupt "zwischengespeichert" werden kann und somit ggf. verloren geht bzw. (als Beispiel) auch, wenn als Reaktion auf den Interrupt in reproduzierbarer und limitierter Zeit das nächste Datenpaket zum Senden bereitgestellt werden muß, o.ä.) ist auch einigermaßen unabhängig von der reinen "Prozessor-Power" (und teilweise sogar auch von der Anzahl der Cores, wenn andere kritische Ressourcen nicht ebenfalls mehrfach vorhanden sind).

Viel hilft viel ist hier leider nicht immer die beste Maxime ... und das gilt auch für die Priorisierung einer Task, wenn diese dadurch für andere zum "Bremsklotz" wird (und dafür braucht es auch keine "volle Prozessorlast", damit solche Situationen auftreten können). Wenn ein Prozess innerhalb einer definierten Zeitspanne ein berechnetes Ergebnis vorlegen muß und ein anderer das ebenso soll, dann ist jeder Kontextwechsel zwischen diesen beiden schon "Gift" für solche "Terminarbeiten" (weil der Wechsel selbst auch "Rechenzeit" braucht) und in der Regel gibt es auch nicht nur zwei Prozesse, die einigermaßen zeitkritisch sind und gleichzeitig um kritische Ressourcen konkurrieren. Das gilt in einem/jedem OS an sich und im FRITZ!OS im Speziellen, weil dieses sich auch noch ein wenig mit "Steuern und Regeln" und dem Aufrechterhalten von "Außenbeziehungen" befassen muß und nicht nur irgendwelche isolierten Berechnungen für sich anstellt, deren Ergebnis dann irgendwann mal kommuniziert wird und wo es auf eine oder zwei Sekunden Verzögerung gar nicht ankommt und man irgendwelche Prozesse tatsächlich "vorziehen" kann über entsprechende Priorisierungen.
 
Zuletzt bearbeitet:
@KunterBunter:
Meinst Du meinen letzten Satz?

Die meisten (normalen) OS (in irgendeinem PC) haben ja auch heute noch keine Notwendigkeit, irgendwelche zeitabhängige Peripherie zu steuern oder mit jemandem "von außerhalb" zu kommunizieren, der auch innerhalb einer definierten Zeitspanne eine Reaktion erwartet und wo solche Kommunikation dann nicht "message-driven" ist (womit wir wieder bei einer Queue und dem "Speichern" von Events sind).

Eine Netzwerk-Antwort in einer TCP-Verbindung ist zwar auch (in Grenzen) zeitkritisch, weil sie vor dem Receive-Timeout beim Sender gesendet werden und dort auch noch eintreffen sollte - aber eine von einem GPIO-Pin und der dort "anliegenden Frequenz" abgeleitete Zeitkonstante für irgendwelche Peripherie (wo dann der Prozessor im richtigen Takt den Pin von 0 auf 1 und wieder zurück schalten muß) ist noch einmal eine andere Qualität bei den Anforderungen an die Latenzen in einem OS.

Welchen (kumulierten) Effekt schon geringe prozentuale Abweichungen über einen längeren Zeitraum haben können, konnte man irgendwann in diesem Frühjahr z.B. bei der Absenkung der (noch einigermaßen niedrigen) Frequenz im Stromnetz beobachten, wo darauf synchronisierende Uhren dann plötzlich alle nachgingen: https://www.heise.de/newsticker/mel...knappheit-laesst-Uhren-nachgehen-3984126.html

Wenn es also zeitkritische Aufgaben in einem OS gibt, dann brauchen diese eine einigermaßen garantierte max. Latenz bei ihrer Bearbeitung - das ist in einem "normalen" PC eher selten der Fall (weil die Peripherie meist über Controller angebunden ist, die sich selbst um die Einhaltung von Protokollen kümmern), aber in dieser Hinsicht ist die FRITZ!Box eben doch ein "embedded device" und einiges der Steuerung der Hardware wird wohl (aus Kostengründen oder warum auch immer, AVM wird zwingende Gründe haben angesichts des Aufstands, der da in Software gemacht wird) auch in Software umgesetzt.

Ich habe jedenfalls schon Boxen gesehen, die "kernel panic" im DECT-Treiber geschoben haben, weil die Timing-Abweichungen im DECT zu hoch wurden (wenn meine Interpretation der Fehlernachrichten in den Crash-Logs korrekt ist) - ich würde das u.a. darauf zurückführen, daß der Data-Link-Layer für die DECT-Funktionen wirklich in Software umgesetzt ist (ob das auch in Hardware verfügbar wäre, ggf. mit anderem Chipset, weiß ich nicht). Auch das sind sicherlich alles noch keine "kritischen Bitraten", die da zu realisieren sind (ist iirc irgendwas knapp über 1 MBit/s), aber da hier das Timing eine große Rolle spielt (das ist m.W. TDMA auf dem Physical-Layer), müssen zu sendende Daten rechtzeitig bereitstehen und empfangene rechtzeitig verarbeitet werden. Hier kommt es vermutlich eher auf die Pünktlichkeit an als auf die Power - zwischen zwei Interrupts könnte sich die CPU sogar langweilen, wenn nichts anderes zu tun ist. Aber wenn sie zwischenzeitlich etwas anderes macht, dann muß das auch umgehend unterbrechbar sein, damit der nächste Interrupt wieder "in-time" behandelt werden kann.

Da ist eine "critical section" in irgendeinem Kernel-Driver zum falschen Zeitpunkt dann auch nicht gerade hilfreich ... ich vermute mal, daß die Timing-Anforderungen bei der Kommunikation CPE <-> DSLAM auch nicht so ganz ohne sein werden (reine Vermutung, kann man sicherlich in irgendeiner Spec nachlesen, wenn's einen wirklich interessiert) und so unterscheiden sich dann AIOs eben sogar noch mit ihren "Zusatzaufgaben" recht deutlich von einfachen Modems, die ggf. sogar auf denselben Chipsets basieren (deshalb die Betonung auf die "FRITZ!Box" im Speziellen, weil sie schon eines der am höchsten integrierenden Consumer-Geräte ist) und trotzdem deutlich mehr Reserven haben, weil sie andere Aufgaben nicht kennen.

Bei der Ausführung von "normalen Tasks" auf einem beliebigen OS ohne "externe Abhängigkeiten" mag eine höhere Priorisierung einer Task eine einfache Lösung sein ... wobei auch dort (und im Angesicht von Multi-Core-Prozessoren an allen Ecken und Enden) inzwischen sehr deutlich zwischen Prozessen für MMI und "worker threads" unterschieden wird, denn wenn - als Beispiel - das Generieren eines RSA-Keys mit 4 KBit die "responsiveness" eines GUI in den Keller treibt, ist das ja - egal wie wichtig dieser Key aus sein mag und wie hoch der Prozess priorisiert wird - eher nicht im Sinne des Erfinders/Programmierers ... es ist also (und darauf wollte ich hinaus) immer noch eine Abwägung von Vor- und Nachteilen erforderlich und ein "Priorität hochsetzen, der Linux-Kernel macht dann schon den Rest" als Behebung eines echten Bottlenecks ist etwas, was max. bis zur Abnahme durch den Auftraggeber hält und beim Auftreten von Extremsituationen im Wirkbetrieb sehr schnell seine Schwächen offenbart.
 
Ich mal einen Versuch der Übersetzung des grammatikalisch etwas holprigen letzten Satzes. Meines Erachtens handelt es sich um eine Wiederholung des folgenden, bereits im vorhergehenden Posts geschriebenen Absatzes:
Du irrst aber, wenn Du der Ansicht bist, eine FRITZ!Box macht außer Vectoring (bzw. dem Teil davon, den eine 7390 wg. ihres Alters wohl nicht ausschließlich in der FPE macht) nichts anderes als "Webserver" und "Routing" oder irgendwelche anderen, absolut nicht zeitkritischen Dinge.

Edit: da war ich wohl zu langsam :)
 
Ich habe den letzten Satz mal anders (hoffentlich besser) formuliert ... das tut der ausführlicheren Erklärung ja keinen Abbruch.
 
Hi, ich hatte ja beschrieben dass ich mit der 7412 Verbindungsabbrüche bei Vectoring habe (die auch nicht durch die neue Firmware behoben wurden). Es stellt sich heraus, dass diese durch den Powerline-Adapter meines Nachbarn verursacht wurden. In der "richtigen" Labor für andere Boxen ist "Option zur Prüfung und ggf. Behebung erkannter Störeinflüsse von Powerline auf VDSL" enthalten. Dies wird lt. AVM definitiv nicht für die 7412 kommen - schade. Auf neue Funktionen (Mesh, ...) hätte ich problemlos verzichten können.
 
Dann würde ich den Nachbarn darauf ansprechen. Powerlineadapter werden von den Marktaufsichtsbehörden, hier die Bundesnetzagentur, sehr argwöhnisch beobachtet. Speziell die MIMO-Adapter sauen bis hoch zu 80 MHz rum. Man hat für Powerline eine spezielle Norm zusammengenagelt, die auch nur in Europa benutzt wird. Die Nutzpegel der PLC liegen weit über den zugelassenen Störspannungsgrenzwerten von Klasse B- und sogar Klasse A-Geräten.

VG

Thomas
 
Ich glaub, ich war zu schnell mit meiner Aussage. Gab wieder eine Unterbrechung..
 
Gerade habe ich festgestellt, dass das Ende des Supports EOS für die 7390 um einem Monat auf den 1. September verschoben wurde.
https://avm.de/service/eos-liste/fritzbox/
Bisher war die Rede vom 1. August, also in einer Woche (vergleiche mit Screenshot)
Womöglich braucht man noch mehr Zeit für die finale Firmware, die es dann über den regulären Updatekanal gibt.
Die heißt dann FRITZ!OS 7 :rolleyes:
smiley_emoticons_ironie.gif
 
Zuletzt bearbeitet:
Da würde ich nicht drauf wetten. Aber man kann sich ja täuschen. Dann haste wenigstens eine gute Heizung, wenn du das OS7 auf die 7390 bügelst.
 
Jo, ich glaube auch nicht an die 7er Version. Hab noch ne 7390 im Freundeskreis zu betreuen und gehe eher von einer 6.94 oder so aus.
 
Eher drunter - die 6.90 hat die 7390 ja schon ausgelassen.

Generell dürfte das mit dem Wartungslabor zusammenhängen. Wenn da noch eine Wartungsrelease kommt, dann sollte der Support eben ansprechbar sein. Das angegebene Datum bedeutet ja eine Arbeitsanweisung für den Support.
 
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.