Beiträge von frank_m

Zitat von silo81

Was damals ging, MUSS auch heute gehen! Weil es Uhrschleim der untersten einfachsten Sorte ist.

"Früher musste es so gemacht werden. Was heute ist, weiß ich nicht und interessiert mich auch nicht, aber es funktioniert nicht! Skandal!"

Das ist Deine Ansicht meine nicht.

Wie war das mit den Widersprüchen?

Zitat von silo81

Wenn es früher kein Problem war, warum versucht AVM dann das Rad neu zu erfinden?

Weil Technologien nun mal nicht stehen bleiben. Analoges Fax oder ISDN will heute auch niemand mehr. Neue Technologien erfordern neue Herangehensweisen und neue Wege in der Einrichtung. Deine Ansicht ist da sicher nicht Maßstab für alle Kunden.

Zitat von silo81

Es geht nicht um gelungen oder nicht mit DHCP, wenn Clients dies nicht hergeben, weil es nicht möglich ist in der Software von denen, was soll man da machen?!

Genau das hab ich ja oben geschrieben. Die Clients geben es nicht her, und mit DHCP ist es unmöglich. Warum gibst du AVM dann die Schuld? Die können als Letztes was dafür.

Zitat von silo81

Kappierst Du es nicht, daß Theorie und Praxis zwei unterschiedliche paar Schuhe sind?

Doch. Aber die einen finden mit den theoretischen Kenntnissen eine einfache Lösung für die Praxis, und die anderen sagen "es geht nicht".

Zitat von silo81

Hast Du das Bild vom Repeater nicht deuten können?

Ich saß näher am Repeater und trotzdem war die Fritzbox schneller.

Bei mir beim ersten Mal auch. Also ARP Eintrag gelöscht und noch ein Versuch. Beim zweiten Mal wars dann der Repeater. Ist der Eintrag dann erst mal in der ARP Tabelle, dann hast du Zeit, damit zu arbeiten. Wo ist das Problem? Geht geschätzt mindestens 12x schneller, als ein Kabel ziehen. Theorie und Praxis halt.

Zitat von ConiKost

Notfall IP ist auch eine lustige Umschreibung für 169.254.*

Ist halt der Name aus der Doku. Ich versuche, mich diesbezüglich an die dokumentierten Begriffe zu halten, damit keine Missverständnisse aufkommen. Es könnte ja sein, dass die anderen mal reingesehen haben. Kommt selten vor, wie man sieht, aber ab und zu ...

Zitat von silo81

Es hat sich NIE etwas daran geändert.

[...]

Ich freue mich darüber, daß sie dort mal weitergekommen sind.

Innerhalb eines Beitrages widersprichst du dir selber.

Zitat von silo81

Wenn dann aber die einfachsten Dinge Macken machen, stellst Du nur die Dummheit der Leute in den Vordergrund.

Dann überlege mal, warum alle anderen kein Problem damit haben. Dummheit will ich nicht sagen, aber es hat definitiv einen Grund, warum du mehr Probleme hast, als andere.

Zitat von silo81

Warum soll ich das ignorieren und auf alten Dingen beharren?

Weiß ich auch nicht, verstehe ich auch nicht. Aber du schreibst ja, dass du es tut.

nur weiß ich wie es geht und "früher" das nie ein Problem bei denen war und auch so gemacht werden musste

"Früher musste es so gemacht werden. Was heute ist, weiß ich nicht und interessiert mich auch nicht, aber es funktioniert nicht mehr! Skandal!"

Zitat von silo81

Nur warum soll ich sowas nutzen, wenn ich hinterher eh einstellen muss (z.B. feste IP, Autokanal)?!

Die IP hat gar nichts mit der Einstellungsübernahme zu tun.

Du kannst die Einstellungen ja ändern, du solltest dir nur überlegen, wie du das am besten erreichst. Bei der Einrichtung deines 3000er Repeaters hast du dir nur selbst ins Knie geschossen. Und das hätte die Doku relativ einfach hergegeben. Aber da ist natürlich AVM schuld, weil deine verquere Herangehensweise nicht zum Ziel geführt hat.

"Früher musste es so gemacht werden. Was heute ist, weiß ich nicht und interessiert mich auch nicht, aber es funktioniert nicht! Skandal!"

Zitat von silo81

Ich will keine DHCP IP´s bei den Geräten, die immer gleich bleiben. Verstehst Du das nicht?

Doch. Hab ich ja sogar empfohlen. Aber offenbar ist es dir nicht gelungen, die DHCP Clients in den betroffenen Geräten wirklich gründlich und nachhaltig zu deaktivieren.

Zitat von silo81

Wenn man von AVM mehrere Geräte verbunden hat, die alle die selbe Notfall IP haben, landet man IMMER auf der Fritzbox. Hör auf zu Zaubern.

Das ist schon theoretisch nicht richtig. Man landet auf dem Gerät, dass den ARP Request zuerst beantwortet. Spätestens nach einigen Versuchen gelingt der Zugriff.

Zitat von silo81

Das ist nicht unter meiner Würde, nur weiß ich wie es geht und "früher" das nie ein Problem bei denen war und auch so gemacht werden musste.

Ich glaube, genau in diesem Satz manifestiert sich die ganze Problematik. "Ich weiß wie es geht, weil es früher schon so war".

Du ignorierst jeden Fortschritt und jede aktuelle Entwicklung in den Produkten. Du hältst an Vorgehensweisen aus dem letzten Jahrtausend fest (die vielleicht mal für Freifunk funktioniert haben). Dinge, die durch deine Konfigurationsänderung ausgelöst wurden (egal ob auf Anweisung, oder nicht), werden als Bug oder Fehlfunktion interpretiert, anstatt sie einfach wieder rückgängig zu machen. Offensichtliche Randbedingungen oder Tatsachen (DHCP, Notfall-IP) werden einfach abgestritten (=> "alternative Fakten").

Wenn du mit deinen Methoden und Anschauungen in der Steinzeit bleibst, dann darfst du dich nicht wundern, wenn du mit modernen Geräten nicht zurecht kommst.

Zitat von silo81

Nein, man landet dann immer auf der Fritzbox.

Landet man nicht.

Zitat von silo81

Die Anleitung sagt Knöpfchen drücken und Knöpchen drücken. Also für Endkunden.

Und was ist daran schlimm? Ist das unter deiner Würde, einer Anleitung für Endkunden zu folgen? Weil du es selber besser kannst? Hmm. War wohl nur so semi erfolgreich.

Zitat von silo81

Wie kommst Du da drauf? Gab nie Probleme mit DNS oder der Gleichen.

Das hat ja auch gar nichts mit der Einstellungsübernahme zu tun. Da geht es um Passwörter, Kanäle etc. - also alles das, was relevant ist, damit Endgeräte nahtlos zwischen den APs wechseln können. Ohne Einstellungsübernahme riskierst du essentielle Features vom Mesh (802.11k, 802.11v) - oder du musst es akribisch selber einstellen.

Zitat von silo81

Die Notfall IP funzt da nicht, wenn das Ding im Wlan ist.

Unsinn. Natürlich geht die, solange eine physikalische Verbindung besteht.

Zitat von silo81

Xbox von Sohnemann. feste IP vergeben und Portweiterleitung nach ausschalten und später am Tag wieder einschalten, steht sie 2x drin die IP mit xxx.xxx.xxx.xxx (1) und weiterleitungen gehen nicht.

Die Geräte machen dann keine DHCP Anfragen mehr!

Da kannst du Geld drauf wetten, dass da eine DHCP Anfrage war. Schau einfach in die üblichen Foren.

Zitat von silo81

Ja, weil es laut denen nichts ausmacht!

Macht es ja auch nicht. Du schreibst ja selber, dass das Log nach 4 Tagen abgeschnitten wird. Es kann also nicht mehr zu voll laufen. Aber wenn dich statt dessen stört, dass die Logmeldungen verschwinden, dann deaktiviere es.

Zitat von silo81

Das ist doch Mist sowas.

Warum richtest du es nicht einfach nach Anleitung ein? Warum nutzt du Kabel für die Einrichtung, wenn das Gerät als WLAN Repeater arbeiten soll? Dir ist klar, dass MESH auf Dauer nur mit Einstellungsübernahme geht? Das steht auch so in der Anleitung?

Und warum ziehst du immer wild Kabel? Greif doch über die Notfall-IP drauf zu. Die bleibt immer gleich.

Man kann sich das Leben auch absichtlich schwer machen.

Zitat von silo81

Ich habe zusammengefasst bei den vielen über die Jahre gesendeten Supportmeldungen an AVM und das nicht explizit auf dieses Thema bezogen. Du wolltest einen Nachweis und dieser war die letzte Kommunikation mit AVM, mehr nicht.

4 Tage Ereignisse ... das haben sie geändert!! Da hatte ich mich damals noch bei 6.xx darüber an AVM gewandt, daß die sich voll swappen.

Du widersprichst dir immer mehr. Deine letzte Kommunikation drehte sich um die vollaufenden Logs, die du oben gepostet hast? Das ist aber schon längst kein Thema mehr, weil es inzwischen eine maximale Log Größe gibt? Hier schreibst du plötzlich, dass du zu 6.x Zeiten mit AVM zu den Logs geschrieben hast? Und nun stört dich die Begrenzung des Logs?

Zitat von silo81

Und genau die feste IP interessiert die Fritzbox nicht, die ich natürlich selbstverständlich im Endgerät eingestellt habe. Die IP schon, aber die Portweiterleitungen machen dann Mucken.

Das Problem ist bekannt. Es tritt immer dann auf, wenn Leute eine feste IP und DHCP in einem Gerät eingestellt haben. Die Portweiterleitungen sind dem Gerät zugeordnet. Wenn von dort ein DHCP Request kommt, landen die auf der Adresse. Schau dich mal in anderen Foren um, davon wird öfter berichtet. Lösung: Nur feste IPs verwenden, nicht beides gleichzeitig. Besonders gern passiert das, wenn Leute versuchen, die dhcpcd Konfiguration so anzupassen, dass der DHCP Client lokal eine feste IP einstellt, z.B. in Raspis oder ähnlichen embedded Linux Geräten.

Zitat von silo81

Warum gehts dann nach dem Neustart für ein paar Tage? (Nicht bei mir, sondern in viel frequentierten Umgebungen). Bei mir funzt es auch wochenlang anstandslos.

Was geht? Das hast du immer noch nicht konkret beschrieben.

Zitat von silo81

AVM wollte leider immer zur Analyse die An/Abmeldevorgänge mit haben. Musste ich dann immer extra einschalten und wieder ein paar Tage laufen lassen, nun bleiben sie einfach an.

Jetzt wird kurios. AVM wollte die Aktivierung der Anmeldelogs. Du aktivierst es, und beklagst dich dann bei AVM, dass dein Log volläuft? Warum hast du es nach Absenden der Logs an AVM nicht einfach wieder deaktiviert?

Zitat von silo81

Leider kam von dort wirklich immer das Selbe, was ich oben schon mal geschrieben habe ... ist so gewollt von AVM als Antwort.

Bei dem, was du oben schreibst, hättest du die Antwort auch von mir bekommen. Die Forderungen sind nämlich einfach nur Unsinn.

Zitat von silo81

Ich kann in den Ereignissen nur noch 4 Tage zurück schauen. Davor ging dies wochenlang.

Jetzt widersprichst du dir selber. Zum einen beklagst du dich, dass die Geräte langsam werden, weil das Log vollläuft, und dann beklagst du dich, dass es einen automatischen Aurfräummechanismus gibt, der verhindert, dass die Geräte langsam werden, weil das Log vollläuft.

Wann wirst du verstehen, dass nicht die Log-Meldungen das Problem sind, sondern das, was die Log-Meldungen auslöst?

Zitat von silo81

Feste IPs wurden einfach übergangen und die Geräte waren/sind nicht mehr erreichbar, weil die Fritzbox zusätzlich noch eine andere IP vergeben hatte und die Anfragen dann ins leere liefen.

Wenn ein Gerät eine feste IP hat, dann fragt es die Fritzbox gar nicht mehr per DHCP. Die Box kann also gar keine andere IP verteilen. Und wen würde es auch interessieren? Die IP ist ja im Gerät eingestellt.

Komm jetzt nicht mit "feste IP im DHCP Server eingestellt". Jeder, der sich auch nur mit den Grundlagen von DHCP beschäftigt hat, weiß, dass man die State Machine von DHCP durch harte Reboots einfach aus dem Tritt bringt, und dann gibts andere IPs, weil das Lease nicht frei ist. Das macht jeder DHCP Server so, nicht nur die Fritzbox. An der Stelle ist jedes weitere Argument zwecklos. Willst du eine feste IP, dann stell sie im Endgerät ein. Punkt. Diskussion beendet, in dem Zusammenhang werde ich auch definitiv kein anderes Argument zulassen.

Zitat von silo81

Also bleibt mir nichts anderes übrig, denen Symptome und Supportdaten zu geben. Selbst in einem 0815 Netzwerk zu Hause mit FB, Repeater, 2 Lan Verbindungen und 3-4 Wlanclients kann man das beobachten.

Ich hab zu Hause ein Netz mit FB, 2 Repeatern, insgesamt ca. 30 Clients, davon 18 per WLAN, und nach 160 Tagen Uptime ist mein Log nicht voll, und die Geräte sind nicht langsam. Vielleicht solltest du mal deaktivieren, dass die An- und Abmeldevorgänge mitgeloggt werden, wenn dich die Datenmenge so stört?

Für die WLAN Randbedingungen kann AVM nichts. Viele Störer oder bauliche Einschränkungen sind dein Problem. Vielleicht sind andere Kanäle oder andere Aufstellorte eine Lösung. Aber bestimmt nicht das Löschen des Logs.

Zitat von silo81

Ob das nun am Log liegt oder nicht, weiß leider nur AVM. Danach funktioniert es aber immer wieder mit den Geräten, also ist da was faul. Oder siehst Du das anders?!? Aber was es ist, verraten sie ja auch nicht.

Zusammenfassend lese ich hier zwei Probleme:

- Zum einen Probleme in der DHCP Adresszuordnung. Klare Ansage: Wer eine feste IP will, der stellt sie im Endgerät ein

- Dann die volllaufenden Logs, wo man zwischen den Zeilen rauslesen kann, dass häufige Mesh-Wechsel den Hauptanteil ausmachen. Diese Meldungen kann man explizit separat deaktivieren. Da ich mir kaum vorstellen kann, dass du die wirklich für die Analyse benötigst: Stell sie ab. Von daher hat AVM Recht: Das ist so gewollt, weil sie sogar eine extra Option eingebaut haben, um diese Meldungen zu aktivieren. Zuerst die ausführlichen Meldungen zu aktivieren und dann nach einem händischen Mechanismus zu rufen, sie zu entfernen, ist .... sagen wir mal, merkwürdig.

Insgesamt ist die Ursache für die vielen Mesh Wechsel aber eher in der Funkversorgung zu suchen. Wenn du eine Lösung willst, dann mach dich da dran. Alles andere sind Symptome.

Er hat die gleichen Symptome. Ob es das gleiche Problem ist, können wir nicht mit Sicherheit sagen.

Der Weg über Frankfurt - egal ob der trace bis zum Ende läuft oder nicht - jedenfalls kein Hinweis darauf, dass es nicht funktioniert.

Ich hab jetzt gerade noch mal ein paar Versuche gemacht:

Ein Traceroute aus den Heise Netzwerktools:

Kommt in Frankfurt bei der Telekom an, allerdings aus dem Plusnet Netz. Der Telekom Server wird im Trace erreicht.

Dann hab ich einen Traceroute von meinem Netcup VPS in Nürnberg gemacht:

root@serv1:~# traceroute 62.157.140.200
traceroute to 62.157.140.200 (62.157.140.200), 30 hops max, 60 byte packets
 1  XX.XX.XX.XX (XX.XX.XX.XX)  0.215 ms  0.152 ms  0.165 ms
 2  ae3-4018.bbr01.anx84.nue.de.anexia-it.net (144.208.211.30)  4.207 ms  4.191 ms  4.307 ms
 3  ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141)  3.988 ms  4.048 ms  4.169 ms
 4  80.156.161.185 (80.156.161.185)  4.021 ms  4.024 ms  4.047 ms
 5  f-eb12-i.F.DE.NET.DTAG.DE (217.5.89.170)  3.903 ms  3.929 ms f-eb12-i.F.DE.NET.DTAG.DE (217.5.89.106)  3.833 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *

Kommt ebenfalls in Frankfurt bei der Telekom an, aber der Login Server wird nicht erreicht. Dennoch kann ich auf dem VPS in einem Browser problemlos die Telekom Login Seite aufrufen.

Ich bleibe dabei: Das ist ein lokales Problem.

Zitat von alfalfa

Kannst du https://accounts.login.idm.telekom.com/ aufrufen?

Ja, problemlos. Hier läuft auch grade Magenta TV auf einem Samsung TV nebenbei.

Genau. Die DG ist raus. Sie routen die Pakete weiter. Wenn es ein Netzwerkproblem ist, liegt es im Telekom Netz. Aber da Millionen gerade Fußball schauen, ist das auch unwahrscheinlich.

Nutzt ihr Pihole oder sowas?

Nachtrag: Mein Trace:

PS C:\Users\> tracert -4 accounts.login.idm.telekom.com

Routenverfolgung zu accounts.login.idm.telekom.com [62.157.140.200]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.175.1]
  2     3 ms     2 ms     2 ms  100.68.12.1
  3     6 ms     5 ms     5 ms  100.127.1.131
  4     7 ms     6 ms     6 ms  100.127.1.132
  5     8 ms     7 ms     7 ms  185.22.46.145
  6     8 ms     7 ms     7 ms  ddf-b2-link.ip.twelve99.net [62.115.38.12]
  7     6 ms     6 ms     6 ms  dtag-ic363481-ddf-b2.ip.twelve99-cust.net [80.239.132.145]
  8     8 ms     8 ms     8 ms  d-eb9-i.D.DE.NET.DTAG.DE [217.5.71.66]
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11    17 ms    16 ms    16 ms  193.159.167.250
 12    16 ms    15 ms    15 ms  accounts.login.idm.telekom.com [62.157.140.200]

Ich komme bei der Telekom in Düsseldorf an, du offenbar in Frankfurt. Von Düsseldorf aus gehts weiter, von Frankfurt aus scheinbar nicht. Wie gesagt, wenn es ein Netzwerkproblem ist, dann eines im Telekom Netz.

Zitat von silo81

Es steht NICHTS von reset.

Ja, ok, das war ungenau. Neustart ist richtig. Sorry. Ändert aber nur wenig, denn unsinnig ist es immer noch.

Zitat von silo81

Du musst mir mal bitte erklären, wie man vom Programmieren auf Dächer klettern kommen kann.

Das hab ich mich auch gefragt, aber du hast oben geschrieben, dass du die Programmierer Studenten nennen darfst, weil du auf zig Dächern warst. Ich bin auf zig Dächern gewesen und habe in der Großstadt dafür gesorgt, das Internet allen zur Verfügung steht. Von daher erlaube ich mir zu sagen, das die Programmierer Studenten sind.

Zitat von silo81

Und von Log Meldungen über Master und Repeater geht es überhaupt nicht. Das ist Dein vermeintliches Verständnis.

Ich zitiere dich noch mal:

Bitte die Möglichkeit einer Zeitschaltuhr in die Firmware einbringen, die nach Zeitplan einen automatischen Neustart ermöglicht. Die Geräte swappen sich so dermaßen mit Ereignisprotokolleinträgen zu, daß sie sehr langsam werden.

Aber ich stimme zu: Es geht eigentlich nicht um die Logmeldungen, da die nur Symptome sind, und keine Ursachen. Aber worum geht es? Genau das will ich doch die ganze Zeit von dir wissen. Was ist das Problem der Boxen? Was muss gelöst werden, damit man die Geräte auch ohne Zeitschaltuhr betreiben kann?

Zitat von silo81

Freifunk hat bei uns einwandfrei funktioniert.

Bei vielen anderen war es eine einzige Katastrophe. Oft konnte man relativ einfach was dagegen tun, wenn man sich damit befasst hat und das Setup optimiert hat. Es lag tatsächlich eher an den individuellen Randbedingungen.

Moment. Das hatten wir schon, oder? Ach nee, da ging es um AVM ...

Zitat von silo81

Von daher erlaube ich mir zu sagen, das die Programmierer Studenten sind.

Weil du auf Dächer klettern kannst? Hmm. Aber: Was hat Freifunk mit dem Problem zu tun? Wie dem auch sei: Beim Freifunk hat auch nicht alles stabil funktioniert (vor allem das Meshing), und es wurden auch nicht alle abstrusen Nutzerwünsche umgesetzt.

Zitat von silo81

Was möchtest du für Details wissen?

Naja, in dem Fall von oben. Wo du schreibst, dass sich Master und Repeater gegenseitig mit Logmeldungen fluten, und du dann willst, dass die Boxen zeitgesteuert resettet werden können. Was genau ist da das Problem? Warum sollen sich die Boxen resetten? Und was sind das für Logmeldungen?

In Foren nennt man sowas "XY Problem". Du hast Problem X und glaubst, dass Y dafür Lösung ist. Also fragst du nach Y, dabei solltest du X lösen, um Ruhe zu haben, weil Y sich damit von allein erledigt. Wenn nun jemand nachhakt, was dahinter steckt, und nach X zu suchen beginnt, ist er doof, Student oder hat keine Ahnung.

Du schreibst nur, dass sich die Boxen automatisch resetten sollen, und erwartest, dass wir das unmittelbar als der Weisheit letzter Schluss verstehen. Dabei ist das das Schlimmste, was man tun kann, da man ausschließlich Symptome bekämpft. Beim Freifunk wärst du für den Lösungsvorschlag rausgeworfen worden. Auf die Idee würde kein Student kommen, und erst recht keiner, der sein Studium abgeschlossen hat. AVM offenbar auch nicht, Gott sei Dank. Das spricht für sie.

Darüber läuft der Traffic bei mir auch, sowohl IPv4 als auch IPv6. Hab ich gerade mal mit mtr getestet.

Wobei, die Situation ist geradezu klassisch.

Du stellst fest, dass sich Mesh Master und Repeater mit Logmeldungen fluten und scheinst damit Probleme in Verbindung zu bringen (welche eigentlich?). Als Lösung machst du fest, dass die Geräte sich zeitgesteuert neu starten zu müssen, um den Log zu leeren. AVM setzt das nicht umgehend um, sondern interessiert sich für die Ursache der Logmeldungen. Also ist der Support Scheiße, alles nur Dilettanten, da sie deine weitsichtige und nachhaltige Lösungsstrategie nicht nachvollziehen können.

Millionen andere haben dieses Problem nicht. Dass die Meldungen also eine Ursache haben müssen, die in deinen ganz individuellen Randbedingungen zu suchen sein müssen, spielt in deinen Erwägungen überhaupt keine Rolle. Kein Gedanke daran, das mal zu untersuchen oder gar zu beheben. Stattdessen gibt es abstruse Forderungen für das Bekämpfen von Symptomen, und wenn jemand die Sache analysieren möchte, dann wird ihm unterstellt, dass "nur noch Studenten [...] Programmieren". Ja nee, ist klar.

Oben hatten wir schon die Wand mit den vielen Löschern, die du gebohrt hast. Ich hoffe, die Wand ist noch stabil genug, dass du einmal ordentlich mit der Stirn dagegen schlagen kannst. Es wäre an der Zeit.

Zitat von silo81

Hoffe Du kannst dies nachvollziehen bzw. es reicht Dir als Antwort.

Sagen wir mal so: Es ist exakt das, was ich erwartet habe. Das, was in Post #30 steht, ist polemisches Gebashe und keinesfalls eine konkrete Erfahrung. Millionen andere haben diese Probleme nicht - das würde mir an deiner Stelle zu denken geben.

Ich glaube sogar, dass du mit dem AVM Support in Kontakt warst. Aber wenn die Antwort war "Its not a Bug, its a Feature", dann ist auch klar, welcher Natur die Anfragen waren.

Wenn da wirklich was dran ist, dann nenn uns nur einen konkreten Bug, um den es geht. Ich will gar nicht die Mail Kommunikation mit AVM sehen. Ich will einfach nur einmal präzise hören, was schief geht. Wie ist die Installation, wie die Konfiguration, was sind die Anwendungsfälle, und was geht schief. Nur ein Mal. Ich versuche es seit 20 Jahren, in so einer Situation nur ein einziges Mal eine konkrete Beschreibung geliefert zu bekommen. Vergeblich. Was würdest du denken?

Klar, du kannst davon ausgehen, dass dein Anliegen hier direkt in der Luft auseinander genommen wird. Da es - wie du ja selber schreibst - von AVM so vorgesehen ist, gibt es mit Sicherheit relativ einfache Möglichkeiten, das Ding zu umschiffen oder anders zu lösen. Das willst du dir ersparen, deshalb veröffentlichst du die Fälle gar nicht erst.

Aber was sagt das über die Qualität des AVM Supports über die Fähigkeiten von deren Entwicklern aus? Genau.

//Nachtrag zum 2. Beitrag: : Sorry, das sind keine Bugs, das sind Feature Requests. In der Situation würde ich mir ansehen, was die Einträge erzeugt, denn es wird ja einen Grund dafür geben. Die Boxen zeitgesteuert zu resetten, ist Bekämpfen von Symptomen, aber nicht von Ursachen.

Mal ehrlich: Warum sollte die DG ausgerechnet einen Dienst sperren? Und wie sollten sie das technisch überhaupt machen? Nee, das ist ein anderes Problem.

Zitat von Stingray1983

Und die Einstellungen am Rechner erklären auch nicht, warum ich die V4 Adresse nicht pingen kann.

Ich kenne die Einstellungen nicht. Von daher kann ich das nicht beurteilen.

Ich nehme an, ihr habt keine Aufzeichnungen darüber, über welche öffentliche IPv4 Adresse eure CGNAT Adresse geroutet wurde? Wenn die sich geändert hat, wäre das ein Hinweis. Welche öffentliche IP nutzt der Anschluss deines Vaters im Moment?

Zitat von Stingray1983

Bei v6 funktioniert die Namensauflösung am Rechner meines Vaters irgendwie nicht.

Dann weißt du ja nun, wo du ansetzen musst. Wenn da irgendwas so halb faul ist in eurem IPv6 Setup, dann ist das der sicherste Grund, warum es nicht funktioniert. Dann wird es via IPv6 versucht, es klappt aus irgendwelchen Gründen nicht, und Feierabend.

Ja. Weil: Sowas hab ich schon hunderte Male gehört. Auf konkrete Nachfrage war dann aber immer Ende. IMMER. Und immer mit so Sprüchen "Für mich ist der Thread hier zu Ende". Das hat sich in 20 Jahren AVM Nutzung nicht geändert.

So ein Zufall.

Was passiert denn, wenn du die Box per LAN hinter den ONT hängst? Kannst du dann 2 PVCs konfigurieren? Nicht, dass der ONT eine Umsetzung der VLANs oder sowas macht.

Bei mir wird accounts.login.idm.telekom.com zu IPv6 Adressen aufgelöst. Auch Fußball auf meinem Samsung Smart TV läuft gerade komplett via IPv6, ich habe einen DG Anschluss. Versucht es mal mit IPv6. Das dürfte am DG Anschluss ja kein Problem sein.

Ich könnte mir da so ein Geo-Blocking Problem mit alten IPv4 Adressen konstruieren.