Hallo in die Runde,kurz eines vorweg, habe zu diesem Thema schon den ein oder anderen Beitrag gelesen, bin daraus aber nicht so richtig schlau geworden. Habe hier einen VVDSL100 mit FB 7590. Magenta TV lief bis vor kurzem eigentlich relativ stabil, dann kam es aber immer öfter vor das es Standbild gab, mit der Meldung 'Wiedergabe nicht möglich'.Beim Umschalten gab es während Unicast keine Problem, nach dem switch auf Multicast dann aber wieder extreme Ruckler und kein Ton.Dachte mir natürlich es liegt an meinem nicht IGMP fähigen Switch (obwohl es bislang, seit Einführung Entertain TV, gut lief) an dem der MR 401 hängt, also den Receiver direkt an LAN1 der FB angeschlossen und alles brav neugestartet. Lief kurz, dann wieder der gleiche Fehler.Anschließend habe ich alles, außer meinen PC, von den LAN Ports der FB abgezogen und wieder probiert, Fehler bleibt. Dachte also mein PC ist der Übeltäter. Wireshark gestartet und wirklich merkwürdige Einträge gesehen.Der Receiver sendet, warum auch immer, IGMPv2 Leave Group Messages, anschließend kommen von der Source IP 0.0.0.0 Membership Querys, das ganze sieht sich die FB wohl eine gewisse Zeit an (mal haben 6 Messages gereicht, mal 200), anschließend Standbild und Fehler 'IGMPv2 multicast router 0.0.0.0 ignored' im Log der FB .Lösen konnte ich das ganze bisher, indem ich den MR einfach mal zurückgesetzt hab, seitdem läuft er wunderbar und nicht ein einziges IGMPv2 Paket, alles nur v3. Nun aber die Frage. Wie kommt es zu diesen IGMPv2 Verhalten am MR , kann dies durch den nicht IGMPv3 fähigen Switch kommen an dem der Receiver hängt und wenn ja, warum war der Fehler dann immer noch da wenn ich den MR direkt an die FB anschließe und beides zusammen neu starte? Habe bei anderen Beiträgen immer wieder den Begriff IGMP Störer gelesen, kann mir darauf aber keinen Reim machen, warum sollte der meinen MR 'stören' und zum Rückfall auf v2 zwingen. Bei der Fehlersuche nach so einem 'Störer' wird es eh schwierig, da in diesem Netzwerk extrem viele Geräte hängen, paar IP Kameras, Repeater, Richtfunk-WLAN inkl. zusätzlichem AP in meinem Nebengebäude, 5 Rechner, unzählige Geräte per WLAN, PV Anlage, Energie Manager usw. Könnt mich mit Fachbegriffen bombardieren, komme aus der Netzwerkwelt. Nur das Verhalten hier kann ich mir bisher nicht erklären Zur ersten Fehlereingrenzung lasse ich den MR einfach mal dauerhaft laufen solange alles geht und dazu Wireshark auf meinem Server, der sollte dann ja sehen wenn ein 'Störer' zuschlägt. Bin für jeden weiteren Tipp dankbar. Das ich den Switch, an dem der MR hängt tausche, habe ich mir übrigens fest vorgenommen, nur das Verhalten würde ich eben gerne aus technischer Sicht und auf Protokollebene verstehen.Gleichzeitg würde es mir vermutlich wenig bringen diesen Switch zu tauschen, wenn es dann auch noch von anderen Quellen Einflüsse geben könnte. Grundsätzlich habe ich aber an jedem anderem Gerät (AP, Switches) IGMP Snooping deaktiviert, soweit dies einstellbar war. So, sorry für den langen Text, aber kurz lässt sich sowas schwer zusammenfassen

Es reicht nicht, wenn die FB die Queries ignoriert - was sie laut Logmeldung ja sogar durchaus macht.Der/Die/Das v2 Query darf bei keinem anderen Multicast-Teilnehmer ankommen. Denn der Standard schreibt einem IGMPv3 Gerät vor bei Eintreffen eines v2 Pakets auf IGMPv2 runter zu gehen. Deshalb wird manchmal von einem 'Störer' gesprochen. Ein v1 oder v2 Gerät im Netz reicht aus um das ganze Netz 'runterzuziehen' und das ganze Netz muss nach Abschalten des Störers zurückgesetzt werden, damit es sich wieder traut v3 zu sprechen.Normalerweise ist das Verhalten auch eher unkritisch. Im Fall von IPTV ist es aber problematisch weil IGMPv2 die SSM -Option nicht mehr hat und die ist mittlerweile Pflicht. Ohne SSM wird an vielen Anschlüssen der Multicast nicht mehr zum Router geliefert und dann hat der selbst gar nichts zum Weiterleiten, selbst wenn er gar nicht aktiv blockt.

Muss diesen alten Beitrag mal aktualisieren.Mittlerweile wurde mir vom Hersteller des Energie Managers eine Beta-Firmware bereitgestellt die das IGMPv2 Problem löst.Firmware läuft 1a und es treten keinerlei Störungen mehr auf. Wer also Probleme mit einem B-control EM 300 (hat den überhaupt einer ) hat, dem kann geholfen werden. Muss die Firma B-Control bzw. TQ-Automation hier auch mal lobend erwähnen, erlebt man wohl eher selten das soetwas in dann doch so 'relativ' kurzer Zeit behoben wird.

Guten Tag, wir haben im Büro eine Digibox Premium, diese soll als VPN Server für externe Zugriffe genutzt werden, und eine VPN Verbindung mit einem MacBook Pro konnte mittels dieser Anleitung auch eingerichtet werden (ich musste allerdings die IKEv1 Settings auf IKEv2 hinbiegen) http://www.bintec-elmeg.com/portal/downloadcenter/dateien/workshops/current_de/ws_be_IP_html_de_HTML/ws_beip_iphone.html ABER: Seit Änderung der local + remote ID in der Digibox Oberfläche lässt sich die VPN Verbindung jetzt nicht mehr herstellen, und die Verbindung wird permanent als 'Blockiert' angezeigt, auch nach Löschung der VPN Verbindung und kompletter Neueingabe aller Daten. Wie entsteht diese Blockierung und wie lässt sich die Blockierung wieder aufheben? Finde das nirgends in der Anleitung. Oder muss man (aus irgendwelchen Gründen) den VPN Namen und die IDs der bintec Anleitung verwenden ?! Das interne Protokoll zeigt : IKE_SA: peer 0 () sa 44 (R): failed id No Id <- ip xxx.xxx.xxx.238 ((null)) obwohl local / remote ID in der Digibox / im MacBook (wie vorher, wo es funktionierte) identisch eingestellt sind Unabhängig davon ist übrigens als zweites Problem die Digibox auch nicht mehr über ihre IP zu erreichen (https Adminzugang über DTAG Internet wurde aktiviert). Auch nach Neustart nicht. Freue mich über hilfreiche Hinweise; die Benutzeroberfläche und Dokumentation der Digibox / be.ip plus hier ist für Nahezu-Laien wie mich eh eine kleine Katastrophe. Danke!

Meine Befürchtung: Sie haben irgendwas 'kaputt-konfiguriert'. Denn normalerweise kann jeder VPN - Zugang den Sie über den VPN - Assistenten anlegen und entsprechend der bintec Anleitung auf den Mac anpassen, immer wieder gelöscht und neu angelegt werden.

Hallo zusammen, WordPress Permalinks auf Beitragsname umstellen nicht möglich.Habe schon einige Tipps zu dem Thema hier im Forum gefunden und auch nachvollzogen. z.B. Anpassung der .htaccess oder httpd.confLeider bisher immer noch ohne Erfolg.Elementor lässt sich nur starten, wenn Permalink auf 'einfach' gesetzt ist. Bei allen anderen Optionen lässt sich Elementor nicht starten.Eine Seite ohne Elementor zu erstellen bringt den Fehler 'Veröffentlichung fehlgeschlagen. Die Antwort ist keine gültige JSON-Antwort'Nach Änderung der Permalink-Einstellungen ist die Datei .htaccess leer (nur noch Kommentarzeilen bleiben erhalten) Bitte um Hilfe

Hallo Reipar, vielen Dank für Deinen Beitrag. Jetzt funktionieren die Permalinks = Beitragsname auch auf meiner Homepage mit WordpressSeiten werden mit Namen in der Url angezeigt !Bearbeitung mit Elementor funktioniert einwandfrei ! LösungDas Verzeichnis etc mit der Datei httpd.conf muss direkt im Rootverzeichnis der Homepage liegen. Danke auch an alle, die mir mit ihren Beiträgen weitergeholfen haben (Bernd, Ingo ..) Jochen

Hallo @jochen.hansen ,wenn du dich an diese Anleitung hältst, sollte es klappen.https://homepagecenter.telekom.de/index.php?id=581MfG. Bernd

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Arifee1

2 Sterne Mitglied

Zusammenfassung

Registriert seit

vor 4 Jahren

Letzter Besuch

Gepostete Beiträge

Akzeptierte Lösungen

Erhaltene Likes

Highlights

Beste Beiträge

Neue Leitung plus neue APL - trotzdem die gleichen Werte wie vorher

Angesagte Themen

Neue Leitung plus neue APL - trotzdem die gleichen Werte wie vorher

2113

Häufigste Likes von

Häufigste Likes für

Social Media

Impressum Datenschutz AGB Produktinformationsblatt Verbraucherinformationen Jugendschutz Kündigung Nutzungsbedingungen Netiquette