TV: Kabelfernsehen wird Mietersache. Jetzt handeln!
Deine Störung ist nicht dabei? Dann nutz unseren Störungsfinder!
Aktuelle Eilmeldungen
1
Frage
2
Antwort
3
Lösung
- PLZ 8308x
- Red Internet Business 1000
- VF Station (Arris) im Bridgemode -> pfSense
- Anbindung LAN
- Verbindungsabrüche / Packetloss
- Bei Verbindungsabruch leuchted am Modem das rotes LED
Meine Erfahrungen mit dem technischen Support (Level 2?) will ich nicht kommentieren. Wenn die "Leitung" steht, sind die Modemwerte i.O. Es waren mind. 3 verschiedene Experten vor Ort die seit 2019 einpegelten. Im Down/Up habe ich im die 94x/54Mbit mit breitbandmessung.de
Anbei einige Screenshots von heute:
Das Problem zieht sich seit Ende April so dahin. Das gleiche Problem war schon mal Juli/Aug. 2020
Techniker war im Mai vor Ort, Dämpungsglied eingebaut, neu gepegelt. Lief bis Juni. Seither zwei neue VF Arris Router seit dem 11.6.21.
Der 2nd Level ist ratlos, sieht teilweise "Ausfälle", verortet aber das Problem bei mir (hüstl) da ich im Bridgemode bin. Der Leihrouter fällt definitiv aus, die LED Internetanzeige blinkt weiß oder rot. Das hat nichts mit der pfSense zu tun
Anschließent kommen die obligatorischen mails von der pfSense:
Notifications in this message: 4 ================================ 12:30:25 MONITOR: WAN_DHCP has high latency, omitting from routing group GW 188.192.160.254|188.192.160.xx|WAN_DHCP|503.348ms|1426.759ms|12%|down|highdelay 12:30:25 MONITOR: MULLVAD_VPNV4 has high latency, omitting from routing group GW 10.10.0.1|10.10.0.14|MULLVAD_VPNV4|533.388ms|1437.565ms|13%|down|highdelay 12:31:23 MONITOR: WAN_DHCP is available now, adding to routing group GW 188.192.160.254|188.192.160.xx|WAN_DHCP|46.003ms|178.074ms|7%|online|none 12:31:23 MONITOR: MULLVAD_VPNV4 is available now, adding to routing group GW 10.10.0.1|10.10.0.14|MULLVAD_VPNV4|63.349ms|177.439ms|7%|online|none
10 Minuten später bin ich vom Bridge im Router Modus, hää???
Notifications in this message: 3 ================================ 12:40:22 MONITOR: WAN_DHCP is available now, adding to routing group GW 192.168.100.254|192.168.100.197|WAN_DHCP|0ms|0ms|100%|online|none 12:40:23 MONITOR: WAN_DHCP has packet loss, omitting from routing group GW 192.168.100.254|192.168.100.197|WAN_DHCP|0ms|0ms|100%|down|highloss 12:40:25 MONITOR: WAN_DHCP is available now, adding to routing group GW 188.192.160.254|188.192.160.73|WAN_DHCP|21.286ms|14.189ms|0.0%|online|none
Liebe @Moni_GK kannst du da einen Mitarbeiter aus dem Kompetenzzentrum mit diesem Fall beauftragen?
Zugegeben nicht alle Störungen, aber die meisten sind innerhalb von Stunden lösbar. Aber auch da ist VF nicht in der Lage termingerecht zu "Entstören", Siehe mein Post.
Am Mi. 31.6.21 gemeldet für Do. den 1.7.21 einen Termin (schon mehr als 8h), Termin am 1.7.21 von Cableway versemmelt, nächster Termin am 5.7.21
Das alles bleibt folgenlos?
Kabelbruch, Brand etc. ist eine andere Baustelle.
Aber ein Monat ohne einer finalen Lösung ist schon ein starker Tobak.
Mehrfach habe ich darauf hingewiesen das ein Routertausch / einpegeln nicht zielführend sein wird.
Warum springt der UP im Pegel bis 10dBuV?
Warum steigt der ping std dev seit Mai?
Auch wurde die Frage nicht beantwortet warum
der std. dev bzw. ping steigt, oder der ping unter Belastung steigt?
Das Fehlerbild läßt sich m.M.n woanders verorten, jedenfalls nicht in meinem EFH. Gefühlt 10 Techniker haben das schon geprüft.
Nun zum Einsatz:
Achtung hörensagen: Die Technikerin rief ihren Support an. Dieser bemerkte ungewönhliches Werte im post error correction, damit ist wahrschein der FEC/CRC gemeint. Modem war im up auf allen 4 ID'S mit 64QAM syncronisiert. Straßenkabelverteiler kontroliert, Stecker etc. gezogen und wieder gesteckt. Einen Vergleich mit Nachbarn ist nicht durchführbar, bin der einzige. Das stimmt mich nachdenklich
Liebes VF Team: @Moni_GK @Tobias @Jana478 @Martin59 @Jens @Wallace @erfd
Könntet ihr bestätigen das der o.g. Fehler vorliegt?
Könnt für das Arris Modem ein FW update veranlaßen?
(Auf das Modem kann ich weder unter 192.16.0.1 noch 192.168.100.1 zugreifen.)
10 Minuten später erhielt ich eine neues Ticket "Netzstörung Ticket# blabla". das Ticket ist noch offen. Dies ist schon mal ein gutes Zeichen. Wahrscheinlich wird es lange dauern.
Das Entgeld für meinen Vertrag wird pünklich per Lastschrift eingezogen, das sollte auch für eine gewährte Entstörzeit von 8h gelten. Das ist nun das zweite mal das mir ein das widerfährt.
Gibt es da eine Kompensation?
Hier ein Trend
Das im "Backbone" was nicht stimmt habe ich nie dezidiert gesagt, aber es immer wieder zwischen den Zeilen darauf hingewiesen.
Den Fehler muß Cableway/VF schon selber finden, wobei der Grundsatz gilt: Korrelation ist nicht unbedingt Kausalität.
Auffälliig ist auch das die Spikes meist im Sommer auftreten.
Die Daten sind auf das Tagesmittel gerechnet, Kringel von mir, nicht schön aber erfüllt den Zweck.
Speedtest: Seit 1.7.21 im up zuwenig, sonst 54Mbit/s
Liebes VF Team: @Moni_GK @Tobias @Jana478 @Martin59 @Jens @Wallace @ERFD
So ein Angebot kann ich nicht ablehnen, ich bitte um eine Gutschrift 
Ein tadellos funktionierenden Anschluß wäre mir allerdings liebe.
Könnt für das Arris Modem ein FW update veranlaßen?
(bitte, bitte)
Die Modemwerte kann ich z.Z. nicht auslesen, da kein Zugriff auf die VF Station möglich ist.
Bei den alten VF Stations (Typ Arris) war das Webinterface unter 192.168.100.1 ansprechbar. Da ich weder meine Firewall / Router noch den PC modifiziert habe, liegt es eher an der Uralt FW der Arris aus 2018.
Aktueller FW Stand Arris:
Firmware-Version: 01.01.117.01.EURO
ING 192.168.100.1 (192.168.100.1) 56(84) Bytes Daten. ^C --- 192.168.100.1 ping statistics --- 6 Pakete übertragen, 0 empfangen, 100% Paketverlust, Zeit 5124ms thomas@ThinkPad-W520:~$ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) Bytes Daten. ^C --- 192.168.0.1 ping statistics --- 7 Pakete übertragen, 0 empfangen, 100% Paketverlust, Zeit 6125ms thomas@ThinkPad-W520:~$ ssh 192.168.0.1 ^C thomas@ThinkPad-W520:~$ ssh 192.168.100.1
Solange der std. dev unter dem Ping liegt bin ich fast wieder auf dem Niveau Mai 2021, jedoch bleibt es für mich unverständlich warum der std. dev bei Belastung der Leitung so wegdriftet. das 2sigma (95% aller Messerte) ist enorm. Gestern gegen 11:55 habe ich ein Weksreset durchgefürt, danach keine Packetlosses mehr. Um 21:30 springt der Ping, warum?
Mein dpinger setup ist 500ms, also 120 pings/Minute
Wird ein Speedtest durchgefüht geht der Ping (Durchschnitt) und std.dev (68.x% aller Messungen) nach oben. Nimmt man das 2sigma, also std.dev*2 (ca. 95% aller Messsungen) werden aus z.B. 40ms -> 80ms.
In der Industrie ist das Maß aller Dinge das 2sigma.
Um 9:57 10:00 und 10:13 wurden speedtest durchgeführt.
Die Quintessenz ist das der std. dev unterhalb des pings bleibt.
Liebes VF Team: @Moni_GK @Tobias @Jana478 @Martin59 @Jens @Wallace @ERFD
Nun habe ich - seit gestern abend - die aktuelle FW und kann auf das Modem zugreifen, ein voller Erfolg. Danke.
Die Werte sind im Vergleich zu gestern stabil. Der Kanal 2 ist um 2 dBµV gefallen. Speed ist OK
Was - wahrscheinlich - nicht OK ist sind die std.dev pings bei Belastung. Generell hat sich der Packetloss seit dem 6.7.21 signifikant verbessert und ist wieder auf dem Niveau vom 04/21
Hier ein Screenshot bei Belastung der Leitung, der Peak um 8:58 ist mir unerklärlich.
Liebes VF Team: @Moni_GK @Tobias @Jana478 @Martin59 @Jens @Wallace @ERFD
Zur Info, gestern abend gab es Starkregen. Heute morgen bekam ich drolf emails mit dem Inhalt Packetloss
Sehr schön zu sehen im 8h Trend.
Wäre eine Kabelfehlerortung sinnvoll?
Wie ist der Stand meiner Entstörung?
Die Selbstheilungskräfte der Up Werte sind beachtlich, das sind Welten im Vergleich zu gestern 0:00
Log aus dem Modem, wahrscheinliche reboots. Dargestellte Zeiten sind in UTC, für CEST es sind +2h hinzuzurechnen.
07/09/2021 04:35:10 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 04:35:10 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 04:08:58 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 04:08:58 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 03:54:47 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 03:54:47 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 03:38:47 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 03:38:47 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 02:35:35 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 02:35:35 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 01:48:40 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/09/2021 01:48:40 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/08/2021 23:59:53 Configuration Changed : Set Device.WiFi.AccessPoint.2.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully. WLAN 07/08/2021 23:59:53 Configuration Changed : Set Device.WiFi.AccessPoint.1.X_CISCO_COM_KickAssocDevices to true from CLIENTTOOL,old value is : false,result: Set successfully.
Zum Glück ist das Ticket noch aktiv
Liebes VF Team: @Moni_GK @Tobias @Jana478 @Martin59 @Jens @Wallace @ERFD
...und weiter geht es. Um 12:00 habe ich einen Router Neustart ausgelöst.
Nun 116dBµV
Arbeitet VF an der Leitung, CMTS oder was auch immer?
Der OFDM fehlt!
Downstream-Kanäle Kanal ID Kanaltyp Frequenz (MHz) Modulation Empf. Signalstärke (dBmV/dBµV) SNR/MER (dB) Lock Status 33 OFDM 167~324 256QAM 0.8/60.8 0 JA 2 SC-QAM 146 256QAM -0.2/59.8 35.8 JA 3 SC-QAM 154 256QAM 0.2/60.2 35.8 JA 4 SC-QAM 162 256QAM 0.3/60.3 35.6 JA 5 SC-QAM 602 256QAM 5.2/65.2 37.6 JA 6 SC-QAM 618 256QAM 6/66 38.6 JA 7 SC-QAM 626 256QAM 5.5/65.5 37.6 JA 8 SC-QAM 642 256QAM 6.6/66.6 39 JA 9 SC-QAM 650 256QAM 6.6/66.6 38.6 JA 10 SC-QAM 658 256QAM 7.1/67.1 39 JA 11 SC-QAM 666 256QAM 6.8/66.8 38.6 JA 12 SC-QAM 674 256QAM 6.8/66.8 39 JA 13 SC-QAM 682 256QAM 7.1/67.1 38.6 JA 14 SC-QAM 690 256QAM 7.2/67.2 38.6 JA 15 SC-QAM 698 64QAM 1.2/61.2 33.9 JA 16 SC-QAM 706 64QAM 1.4/61.4 33.9 JA 17 SC-QAM 714 64QAM 0.6/60.6 33.4 JA 18 SC-QAM 722 64QAM 1.4/61.4 33.8 JA 19 SC-QAM 730 64QAM 1/61 33.8 JA 20 SC-QAM 738 64QAM 3.3/63.3 34.9 JA 21 SC-QAM 746 64QAM 3.6/63.6 35 JA 22 SC-QAM 754 64QAM 3.4/63.4 34.9 JA 23 SC-QAM 762 64QAM 2.7/62.7 34.3 JA 24 SC-QAM 770 64QAM 2.4/62.4 34.9 JA 25 SC-QAM 778 64QAM 3.2/63.2 34.9 JA 26 SC-QAM 786 64QAM 3.2/63.2 35 JA 27 SC-QAM 794 64QAM 4.5/64.5 35 JA 28 SC-QAM 802 64QAM 4.4/64.4 34.9 JA 29 SC-QAM 810 64QAM 4.3/64.3 35 JA 30 SC-QAM 818 64QAM 3.5/63.5 34.9 JA 31 SC-QAM 826 64QAM 1.5/61.5 34.3 JA 32 SC-QAM 834 64QAM -0.1/59.9 32.9 JA 1 SC-QAM 138 256QAM 0.6/60.6 35.8 JA
Kanal ID Kanaltyp Frequenz (MHz) Modulation Send. Signalstärke (dBmV/dBµV) Ranging Status 4 SC-QAM 36 64QAM 56.3/116.3 Erfolgreich 1 SC-QAM 59 64QAM 56.3/116.3 Erfolgreich 3 SC-QAM 46 64QAM 56.3/116.3 Erfolgreich 2 SC-QAM 52 64QAM 54.3/114.3 Erfolgreich
Hallo VF Team @Jens @Martin59 @ERFD @Moni_GK @Claudia @Wallace
Aus mir unbekannten Grund ist das Ticket ist geschloßen worden.
Die Probleme besteht jedoch weiterhin. Heute Nacht gegen 0:15 für 1:30 Totalausfall.
Bitte beantwortet die Fragen welche in der Grafik gestellt worden sind. Besonders interessiert mich der "Kink" ab 0:30. Ein WAN ping mit 1ms ist via HFC nahezu ausgeschloßen.
Alle meine Störungen seit 2020 korrelieren recht gut mit der Niederschlagsmenge PLZ 83088 . Der zeitlicher Verzug wird wohl abhänig sein von der Bodenbeschaffenheit, Verlegetiefe des Kabels etc.
Auch sehe ich keine Gutschriften für Juni/Juli.
Die jetzige Gutschrift bezieht sich auf eine ungerechtfertigte Rechnung für einen Serviceeinsatz
Hier die erste Störung aus 2020
Tagesauflösung
Aktueller 15.7.21 Trend, hohe peaks in std.dev
