Zum Inhalt springen

Magenta Community

Erweiterte Suche für „“
📱 eSIM Aktivierung 📱

gunnar

Top Mitglied
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    32

  • Benutzer seit

  • Letzter Besuch

 Inhaltstyp 

Alle erstellten Inhalte von gunnar

  1. gunnar
    Kann berichten, meine Connect-Box CH7465LG-LC im IPv6 DS-Lite Modus läuft mit: Software Version:CH7465LG-NCIP-6.15.32p2TM-GA-NOSH WAN IP Einstellungen: IPv6 lease time 3 Tage 20h nach Neustart der Box Windows-PCs erhalten per ICMPv6 Router Advertisement: Valid Lifetime 932798 ... das sind also ca. 10,8 Tage Preferred Lifetime: 327998 ... das sind also ca. 3,8 Tage
  2. gunnar
    Ja, funktioniert.
  3. gunnar
    Vielen Dank @seppl - diese URL kannte ich nicht. Ja - funktioniert auch bei mir. Dass das im "Mein Magenta" ins Leere zeigt sollte aber dennoch behoben werden.
  4. gunnar
    Die Funktionalität das Digital Telefon im WebInterface von Mein-Magenta zu verwalten ist hier erläutert: https://www.magenta.at/faq/entry/~self-service~mein-magenta-kabel~dienste-verwalten/~DigTelefon_Verwaltung_Dienste~master Man steigt also unter https://www.magenta.at/mein-magenta-kabel-login/ ein, wählt dort das Digital Telefon aus. Soweit klappt das auch, sieht wie folgt aus: Nun klickt man auf "Digital Telefon verwalten" ... ein Link der nach https://b2bvoipselfcarefrontend.prod.cl.t-mobile.at/voipsc/api/v1/login/mymagenta zeigt. Das Problem: Eine solche Domain b2bvoipselfcarefrontend.prod.cl.t-mobile.at gibt es gar nicht, löst per DNS gar nicht auf. Das ist also auch kein Problem meines Vertrages, sondern dieses Portal scheint generell nicht erreichbar zu sein / zu funktionieren. Bitte an die Moderatoren das an die Technik weiterzugeben.
  5. gunnar
    Dein erster FTP-Abbruch ist einer Firewall die dem CLIENT vorgeschaltet sein dürfte geschuldet. Im Passiven Modus freilich musst du auch die hierfür vorgesehenen dynamischen Port-Ranges in der Firewall des Modems freigeben - da reicht dann 21/tcp noch nicht aus. Noch ein Nachtrag: Da man in der IPv6-Firewall des Modems ja vermutlich nicht "alles für jeden" freischalten möchte wäre die Nutzung einer statischen IP für Deinen "Server" dennoch ratsam. Wie gesagt, einfach am Endgerät die zuvor dynamisch bezogene (oder eine beliebige andere aus der gleichen /64er Range) statisch konfigurieren.
  6. gunnar
    Ein DynDNS mit IPv4 ist im DS-Lite-Mode nicht möglich, du hast keine öffentliche IPv4 die hierfür nutzbar ist, das was nach außen hin sichtbar ist, ist die IPv4 des CGN. Ein DynDNS mit IPv6 ist freilich möglich, wenn Deine DynDNS-Lösung das unterstützt alles fein, dann musst du auch keine "fixe IPv6" konfigurieren sondern kannst Dir diese auch dynamisch zuweisen lassen, der DynDNS-Client sorgt dann für die Updates im DNS. Was Dein "Portscanner" bezwecken soll weiß ich jetzt nicht genau, ich versuche mal ein paar Gedanken dazu zu ordnen: 1. Wenn Du hier ernsthaft vor hast Klartext-FTP über Internet verfügbar zu machen, so ist es vielleicht besser Du lässt die Finger davon - oder willst Du wirklich Klartext-FTP im Jahr 2022 verwenden? Glaube nicht. 2. Selbst wenn du aktives Klartext-FTP verwendest, warum denkst du auf Port 20 sollte etwas nicht "closed" sein? Port-20 ist der Data-Port, den öffnet bei aktivem FTP nicht Dein Server sondern der Client. Insofern wird der auf Deinem NAS niemals "listening / open" sein. Vielleicht möchtest Du Dir in Erinnerung rufen wie FTP funktioniert, siehe z.B. die Skizze hier.
  7. gunnar
    Danke nochmals @Jonathan Dorian, habe die zuletzt von Dir hier geposteten Codes erfolgreich getestet - funktionieren.
  8. gunnar
    Danke @Jonathan Dorian, ich teste das heute Abend.
  9. gunnar
    Danke @Jonathan Dorian, aber unter dem von Dir vorgeschlagenen Link finden sind die gleichen nicht funktionstüchtigen Codes die ich in meinem ersten Posting unter der Überschrift "Anschlussbezogene Standarddienste" bereits gescreenshottet habe. Hilft somit nicht weiter. ---
  10. gunnar
    Win10 Build 19043 ist 21H1, entspricht also auch der Version mit der ich getestet habe. Vielleicht doch nochmal die konfigurierte Dynamic-Port-Range prüfen (wie in meinem Blog-Post erläutert), ob diese wirklich wie folgt konfiguriert ist:
  11. gunnar
    @Gojo interessant, dass es bei Dir nicht wirkt. Welches Betriebssystem / Version, welcher Browser / Version? Im Chromium Projekt wurde der SO_RANDOMIZE_PORT Change übrigens am 31. August 2021 wieder reverted: https://chromium-review.googlesource.com/c/chromium/src/+/3129902/1..4 Allerdings dauert das noch eine Weile bis es in der Stable-Release ab Chrome v95 ankommt: https://chromiumdash.appspot.com/commits?commit=1ce4b7bcd754c7fbff5af8b6ad31e3641e0614f5&platform=Windows Wobei das nun mittlerweile nur noch ein paar Tage dauert, um den 19. Oktober ist v95 zum Rollout vorgesehen. Als Chrome Beta oder als Microsoft Edge Beta kannst Du v95 jetzt schon testen - bin gespannt ob das die Problematik (zumindest durch den Browser getriggert, der Firmware-Bug bleibt ja weiterhin bestehen) etwas entschärft.
  12. gunnar
    Das "Technikteam" an der Hotline hatte keine Idee zu meiner Frage/Problem, mich auf Warteschleife gelegt und das Gespräch schließlich ohne eine Antwort zu geben getrennt. Anfrage über das Kontaktformular mit angefügtem Screenshot: Antwort ich soll die Hotline anrufen, man kann mir per E-Mail nicht helfen. Ich vergebe hierfür die Note: Nicht genügend, 5
  13. gunnar
    Danke @Jonathan Dorian dieser FAQ-Beitrag unter https://www.magenta.at/faq#!self+service/frage/23778 ist mir bereits bekannt. Allerdings ist nichts davon was dort steht existent. Zitat 1: Um eine Rufumleitung zu setzen, wechseln Sie im VoIP Selfservice zu "Rufumleitung". Zitat 2: Um das VoIP Selfservice aufzurufen, loggen Sie sich zuerst in Mein Magenta Kabel/Festnetz ein. Wählen Sie anschließend bei "Meine Einstellungen" den Punkt "Digital Telefon". Existiert in meinem "Mein Magenta Kabel/Festnetz" Kundenmenü nicht - alles durchgeschaut:
  14. gunnar
    Analoges Telefon, angeschlossen an der UPC/Magenta Connect-Box (also Koax-Kabel-Internet). Dienst "Digital Telefon" ist aktiv. Ich möchte eine Anruf-Umleitung einrichten. Aber alle Anleitungen die ich gefunden habe scheinen nicht zu funktionieren. Dass das möglich sein muss erkenne ich an zwei Dingen: 1. in der Leistungsbeschreibung des "Digital Telefon" ist der Dienst Rufumleitung bei Nichterreichbarkeit, bei Besetzt und Permanent angeführt 2. die Codes zum Ausschalten einer Rufumleitung werden korrekt angenommen, das System antwortet mit einer Stimme/Ansage wie folgt: #21# ... "Ihre sofortige Rufumleitung wurde erfolgreich deaktiviert" #61# ... "Ihre Rufumleitung bei Nichtmelden wurde erfolgreich deaktiviert" Die Codes zum Einschalten der Umleitung (siehe Anleitung als Bild im Anhang) hingegen werden mit einer Ansage "Ungültiger Funktionscode" beantwortet. Wie lautet nun der richtige Funktionscode zum Setzen einer Anrufumleitung (sofortig oder bei Nichtmelden)? Eine andere Anleitung habe ich noch gefunden, dies stammt aus der ehemaligen UPC Business Internet F.I.T Broschüre, diese Vorgangsweise funktioniert jedoch im Gegensatz zur Anleitung zuvor gar nicht - das angeführte Freizeichen nach *61 ertönt nicht, nach einem Timeout von ca. 10 Sekunden kommt das übliche rasche "tut-tut-tut"
  15. gunnar
    Weitere 4 Wochen sind seit meiner letzten Rückfrage vergangen, Magenta kann sich seit Mai immer noch nicht zu einer möglichen Lösung äußern und das Problem ist 3 Monate später weiterhin vorhanden. Letzte Woche hat mich sogar jemand extra angerufen um sich zu bedanken, weil Google ihn zu meinem Blog-Post geführt hat und er endlich einen Workaround für das Problem auf meiner Website gefunden hat. Mir wurde geschildert der Magenta Support hat ihm zuvor mehrfach Techniker geschickt und Modem getauscht und mit keinem Wort diese Problematik erwähnt. Liebe Moderatoren @Karo, @Doris676, @Jonathan Dorian, ist euch das eigentlich gar nicht peinlich für ein Unternehmen zu arbeiten, das so agiert?
  16. gunnar
    @Jonathan Dorian und @Doris676 wie ist denn nun der aktuelle Status betreffend dieser Problem-Behebung? Inzwischen sind zwei Monate vergangen, da könnte man ja annehmen das wäre genug Zeit um das Problem zu beheben und eine neue Firmware bereitzustellen?!
  17. gunnar
    @Jonathan Dorian Du wolltest uns ja am Laufenden halten ... was hat sich denn in den letzten 3 Wochen diesbezüglich getan?
  18. gunnar
    @nämo Jemand der autorisiert ist das Modem von außen per Fernwartung zu rebooten nutzt hierzu SNMP (der Provider) oder gibt das WebInterface hierfür von außen frei (berechtigter Nutzer des Modems). Der Provider braucht für einen Reboot von außen hierfür freilich keinen WebInterface-Zugriff und auch keinen "kreativen Workaround" wie hier offenbar vermutet. Beides hat mit diesem Issue den ich beschreibe nichts zu tun und hinterlässt im Log auch einen entsprechenden Eintrag der sich hiervon klar unterscheidet. @Christian_E Das Problem lässt sich - wie von mir beschrieben, wenn die Konfiguration der dynamic-Ports in Windows wie von mir erläutert vorgenommen wurde - auch mit Chrome 91 demonstrieren. Den "Aufschrei" gibt es deshalb nicht, weil die erläuterte Windows-Konfiguration keine Default-Konfiguration ist, und weil selbst jene bei denen das wie von mir erläutert konfiguriert ist vermutlich den Zusammenhang tagelang/wochenlang gar nicht erkennen.
  19. gunnar
    Wie meinem aktualisierten Blog-Post zu entnehmen ist, wird basierend auf meinen Erkenntnissen nun Microsoft auch das Verhalten der Winsock-API anpassen. Davon unabhängig ist nun jedoch Magenta/Compal in der Pflicht den Firmware-Bug zu beheben und ein Update bereitzustellen. @Jonathan Dorian darf ich in der Sache um ein Status-Update ersuchen? Gibt es schon einen Zeithorizont hierfür seitens Compal?
  20. gunnar
    Danke @Jonathan Dorian für das Status-Update. Ich weiß zwar nicht, warum Magenta denkt ich wäre dafür zuständig das an die Browser-Hersteller zu reporten, aber weil ich ein guter Mensch bin habe ich den betreffenden Change im Chromium-Projekt für euch herausgesucht und Kontakt mit dem Entwickler hergestellt. Die Diskussion ist öffentlich im Chromium-Source-Code-Repo nachvollziehbar, der Link dorthin ist in meinem Blog-Post im Abschnitt Welcher Chromium-Change verursacht diese Verhaltensänderung? ergänzt.
  21. gunnar
    Also, Status-Update: Google Chrome 91.0.4472.77 ist nun dem Beta-Stadium entwachsen, wird seit 25.05.2021 21:00 als reguläres Google Chrome Online-Update verteilt. Problem damit - wie befürchtet - vorhanden. Könnte ab morgen also mehr Anwender geben, die mit dem Problem kämpfen. Microsoft Edge v91 ist auch noch für diese Woche angekündigt. Magenta hat sich heute bei mir gemeldet und mitgeteilt "wir schauen uns das an". Seitdem keine Rückmeldung mehr. Habe meinen Blog-Post mit den neuen Informationen aktualisiert.
  22. gunnar
    @Christian_E Deine Einschätzung zur Dringlichkeit und hinsichtlich der Auswirkungen teile ich nicht. 1. Es geht nicht nur um einen Browser, sondern um zwei (Google Chrome, Microsoft Edge) 2. Der Verbreitungsgrad dieser beiden Browser ist hoch. 3. Google Chrome v91 ist nicht mehr in einer frühen Beta-Phase, sondern v91 ist bereits finalisiert und wird am 25.05.2021 (also schon in wenigen Tagen!) per Auto-Update ausgerollt. Daran ist jetzt auch gar nichts mehr zu ändern. Ich prophezeie schon jetzt, dass die Magenta-Hotline dann vermutlich ein paar Anrufe zu verzeichnen haben wird.
  23. gunnar
    Es geht in diesem Thread hier nicht darum meine persönliche Situation zu lösen. Ich selbst kenne die Hintergründe ja mittlerweile und weiß mir zu helfen. Aber vielen anderen Kunden geht es möglicherweise nicht so wie mir, die können sich nicht selbst helfen, bemerken lediglich das ihr Modem rebootet und wissen nicht warum. Denen soll dieser Thread und mein Blog-Post Hilfestellung bieten zu prüfen, ob sie auch von dieser Problematik betroffen sind. Und wenn ja können sie mit dieser Anleitung eine geänderte Konfiguration herstellen um das Problem erst mal zu umgehen. Aber eigentlich ist Magenta jetzt am Zug und muss handeln und diesen Bug in der Firmware beheben (lassen).
  24. gunnar
    Danke @Christian_E für den Vorschlag, den ich aber freilich längst geprüft habe. Mit anderen Internet-Zugängen (Handy-Hotspots auf Android 11 oder iOS 14.5) tritt das Problem freilich nicht auf - es ist ein Modem-Firmware-Fehler der Connect-Box CH7465LG-LC. Getriggert - wie in meinem ausführlichen Blog-Post erläutert - durch die rasche Wieder-Verwendung von niedrigen (1024, 1025, ...) TCP-Source-Port-Nummern beim Aufbau von HTTPS-Verbindungen. Das Problem ist - wie ich am Ende meines Blog-Artikels zeige - auch mit einem kleinen Linux-Shell-Script gezielt demonstrierbar. Ich kann keinen Bug darin erkennen wenn man erstens Source-Ports ab 1024 wählt, und zweitens diese nach Abbau der TCP-Verbindung sofort für eine neue wiederverwendet, mir ist kein RFC bekannt dem dies widersprechen würde, bin aber für Hinweise diesbezüglich offen.
  25. gunnar
    Ich kann das Problem inzwischen auf beliebigen Windows-Geräten und auch unter Linux jederzeit zeigen, in meinem Blog-Beitrag beschreibe ich die Hintergründe und nötige Konfigurationsänderung: UPC/Magenta Connect-Box rebootet bei Aufruf von wetter.orf.at – Blog von Gunnar Haslinger (hitco.at)