Frage
Antwort
Lösung
am 22.06.2021 13:05
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?
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
09.11.2021 12:42 - bearbeitet 09.11.2021 12:54
Hallo du bist ja auch einer der Leidensgenossen von Vodafone und ich verfolg ja deinen Thread weil ich es auch spannend finde was dann am Ende bei raus kommt.
Ich hab allerdings gestern eine sehr Interessante Beobachtung gemacht die ich mir absolut nicht Erklären kann und ich frag mich ob das bei dir auch so ist:
Wenn ich "iperf3 -c iperf.par2.as49434.net -p 9239 -b25m -t100 -V -u" ausführe und währenddessen z.B. 8.8.8.8 anping, dann ist mein Ping deutlich niedriger während ich mit 25Mbit/s hochlade. Mein Ping ist also niedriger, wenn meine Leitung ausgelastet ist (allerdings nicht am Maximum, dann wirds wieder sehr Spiky).
Roter Bereich = Mit iperf3 an
Blauer Breich = Ohne das iperf3 läuft
Der mindestwert mit dem ich eine Verbesserung erzielen konnte war 5 Mbit/s, ab 40 Mbit/s wurds dann wieder sehr schlecht.
Das ist total Absurd, normalerweise werden Pings schlechter wenn man die Leitung auslastet, nicht umgekehrt!
***************************************************************************************
Meine Antwort
Interessanter Ansatz. Ich habe eine 1000/50er Leitung und bin im Bridge Mode. Also reines IPv4 mit nachgelagerten pfsense Router. Zudem läuft bei mir permanent Smokeping, eine Änderung im Pink konnte ich bisher nicht feststellen.
Mir ist eines aufgefallen. Verwende ich einen die iperf3 Parameter -b1000m -t200 -P10 -u **piep**t die VF Gateway ab.
Wenn ich die GW runterziehe, dann sind m.M.n alle die am CMTS hängen davon betroffen.
Erster mit 10 parallelen Verbindungen und einer Dauer von 200sek.
iperf3 -c iperf.par2.as49434.net -p 9238 -b1000m -t10 -P10 -V -u
2ter Test mit einer Verbindung und einer Dauer von 200sek.
iperf3 -c iperf.par2.as49434.net -p 9238 -b1000m -t10 -P1 -V
Wenn die PL's da sind kann ich keine Website öffnen. ich bin m.M.n. ein "Rückwegstörer".
Hier die Ergebnisse. Lücken sind ein Totalausfall, no response.
3ter Test 11:28
iperf3 -c iperf.par2.as49434.net -p 9239 -b25m -t600 -V -u
Hast recht, kann ich bestätigen. Das sigma steigt leicht, in der pfsense ist die Änderung im ping nicht erkennbar.
Die Ursache des verbesserten ping sind in der VF GW zu suche. Der Fisch stinkt vom Kopf her.
Auch gut zu erkennen ist der PL währen der Belastung mit 25MBits. Bei @impi sieht es nach einer leichten Verbesserung aus.
Liebes VF Team.
Wie wie lautet die Erklärung für die Verbesserung im ping wenn diese mit 25MBits im up belastet wird?
Warum geht die GW in die Knie und betrifft das alle am CMTS oder nur mich?
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
10.11.2021 13:51 - bearbeitet 10.11.2021 13:52
Solangsam sollte man eine Lösung finden. Mit dem Hinweis das es ein Ticket gibt ist mir nicht geholfen.
4Mbits sind viel zu wenig.
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9236 -b10m -t10 -P1 -V iperf 3.7 Linux ThinkPad-P50 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 Control connection MSS 1448 Time: Wed, 10 Nov 2021 12:47:10 GMT Connecting to host iperf.par2.as49434.net, port 9236 Cookie: t6ywx436dqxslg6jx3v2423k7rimsibi3cf7 TCP MSS: 1448 (default) Target Bitrate: 10000000 [ 5] local 10.16.252.142 port 44880 connected to 193.177.162.41 port 9236 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.22 MBytes 10.3 Mbits/sec 5 35.4 KBytes [ 5] 1.00-2.00 sec 761 KBytes 6.24 Mbits/sec 12 12.7 KBytes [ 5] 2.00-3.00 sec 509 KBytes 4.17 Mbits/sec 3 11.3 KBytes [ 5] 3.00-4.00 sec 127 KBytes 1.04 Mbits/sec 8 9.90 KBytes [ 5] 4.00-5.00 sec 255 KBytes 2.09 Mbits/sec 5 9.90 KBytes [ 5] 5.00-6.00 sec 509 KBytes 4.17 Mbits/sec 7 14.1 KBytes [ 5] 6.00-7.00 sec 382 KBytes 3.13 Mbits/sec 7 12.7 KBytes [ 5] 7.00-8.00 sec 382 KBytes 3.13 Mbits/sec 5 18.4 KBytes [ 5] 8.00-9.00 sec 636 KBytes 5.21 Mbits/sec 5 15.6 KBytes [ 5] 9.00-10.00 sec 382 KBytes 3.13 Mbits/sec 4 12.7 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 5.08 MBytes 4.26 Mbits/sec 61 sender [ 5] 0.00-10.02 sec 4.86 MBytes 4.07 Mbits/sec receiver CPU Utilization: local/sender 3.5% (0.6%u/2.8%s), remote/receiver 0.5% (0.1%u/0.4%s) snd_tcp_congestion cubic rcv_tcp_congestion cubic
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
am 12.11.2021 10:53
Hallo Kieferer,
es gibt ja noch die Meldung ***126/21, die einem zentralen Auftrag angehängt ist, bei dem die Kollegen mögliche Probleme im Zusammenhang mit dem OFDMA-Kanal untersuchen. Eigentlich ist bei Deinem Router der Kanal laut Einstellungen deaktiviert, er wird aber weiterhin genutzt und fast der komplette Traffic läuft darüber. Ich habe daher den Router neu bei uns angemeldet, der Kanal ist aber immer noch da. Ich habe daher eine Meldung (***709/21) an den Folgebereich gegeben, damit die Kollegen sich das mal anschauen.
Viele Grüße,
Claudia
am 12.11.2021 11:06
Hast du den Router gegen 10:47 resetet?
Der Upload ist mit 6.5MBits immer noch erbärmlich.
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9236 -b10m -t10 -P1 -V
iperf 3.7
Linux ThinkPad-P50 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64
Control connection MSS 1448
Time: Fri, 12 Nov 2021 10:04:30 GMT
Connecting to host iperf.par2.as49434.net, port 9236
Cookie: znn5xqsncrrsb2t7utghiijc6qydtxrytdpm
TCP MSS: 1448 (default)
Target Bitrate: 10000000
[ 5] local 10.16.252.142 port 56370 connected to 193.177.162.41 port 9236
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 963 KBytes 7.89 Mbits/sec 14 32.5 KBytes
[ 5] 1.00-2.00 sec 768 KBytes 6.29 Mbits/sec 4 25.5 KBytes
[ 5] 2.00-3.00 sec 640 KBytes 5.24 Mbits/sec 4 17.0 KBytes
[ 5] 3.00-4.00 sec 1021 KBytes 8.36 Mbits/sec 0 41.0 KBytes
[ 5] 4.00-5.00 sec 636 KBytes 5.21 Mbits/sec 6 21.2 KBytes
[ 5] 5.00-6.00 sec 891 KBytes 7.30 Mbits/sec 1 31.1 KBytes
[ 5] 6.00-7.00 sec 636 KBytes 5.21 Mbits/sec 4 21.2 KBytes
[ 5] 7.00-8.00 sec 891 KBytes 7.30 Mbits/sec 0 38.2 KBytes
[ 5] 8.00-9.00 sec 891 KBytes 7.30 Mbits/sec 2 33.9 KBytes
[ 5] 9.00-10.00 sec 891 KBytes 7.30 Mbits/sec 5 29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 8.04 MBytes 6.74 Mbits/sec 40 sender
[ 5] 0.00-10.03 sec 7.74 MBytes 6.48 Mbits/sec receiver
CPU Utilization: local/sender 3.8% (1.4%u/2.4%s), remote/receiver 2.7% (0.2%u/2.5%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
iperf Done.
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
am 12.11.2021 11:14
Muß der OFDMA Pegel so hoch sein?
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
13.11.2021 23:45 - bearbeitet 14.11.2021 00:05
Das Ticket - OFDMA - 872/21 wurde geschloßen.
Das Ticket 709/21 - OFDMA Bypass - ist weiterhin offen.
Mein up bleibt mit 4.7MBits weiterhin grottig.
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9236 -b50m -t10 -P1 -V iperf 3.7 Linux ThinkPad-P50 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 Control connection MSS 1448 Time: Sat, 13 Nov 2021 22:32:48 GMT Connecting to host iperf.par2.as49434.net, port 9236 Cookie: ezq7aq3ojv6tsjhalya5vfjp6fppn6c5wjqj TCP MSS: 1448 (default) Target Bitrate: 50000000 [ 5] local 10.16.252.142 port 36648 connected to 193.177.162.41 port 9236 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 559 KBytes 4.57 Mbits/sec 25 15.6 KBytes [ 5] 1.00-2.00 sec 509 KBytes 4.17 Mbits/sec 8 15.6 KBytes [ 5] 2.00-3.00 sec 636 KBytes 5.21 Mbits/sec 5 21.2 KBytes [ 5] 3.00-4.00 sec 573 KBytes 4.69 Mbits/sec 4 24.0 KBytes [ 5] 4.00-5.00 sec 636 KBytes 5.21 Mbits/sec 4 29.7 KBytes [ 5] 5.00-6.00 sec 700 KBytes 5.73 Mbits/sec 6 22.6 KBytes [ 5] 6.00-7.00 sec 509 KBytes 4.17 Mbits/sec 4 24.0 KBytes [ 5] 7.00-8.00 sec 509 KBytes 4.17 Mbits/sec 5 22.6 KBytes [ 5] 8.00-9.00 sec 764 KBytes 6.26 Mbits/sec 2 26.9 KBytes [ 5] 9.00-10.00 sec 509 KBytes 4.17 Mbits/sec 6 18.4 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 5.77 MBytes 4.84 Mbits/sec 69 sender [ 5] 0.00-10.04 sec 5.61 MBytes 4.68 Mbits/sec receiver CPU Utilization: local/sender 3.4% (0.9%u/2.5%s), remote/receiver 1.3% (0.2%u/1.2%s) snd_tcp_congestion cubic rcv_tcp_congestion cubic
Pegelwerte nach heutigen restart. (13.11.21 14:29)
Downstream-Kanäle Kanal ID Kanaltyp Frequenz (MHz) Modulation Empf. Signalstärke (dBmV/dBµV) SNR/MER (dB) Lock Status 33 OFDM 151~324 1024QAM 9.2/69.2 42 JA 5 SC-QAM 602 256QAM 9.5/69.5 39 JA 2 SC-QAM 130 256QAM 8.5/68.5 39 JA 3 SC-QAM 138 256QAM 7.8/67.8 39 JA 4 SC-QAM 146 256QAM 7.8/67.8 39 JA 1 SC-QAM 114 256QAM 8.8/68.8 39 JA 6 SC-QAM 618 256QAM 10.1/70.1 38.6 JA 7 SC-QAM 626 256QAM 10.6/70.6 39 JA 8 SC-QAM 642 256QAM 11.3/71.3 38.6 JA 9 SC-QAM 650 256QAM 10.6/70.6 39 JA 10 SC-QAM 658 256QAM 10.4/70.4 39 JA 11 SC-QAM 666 256QAM 10.4/70.4 39 JA 12 SC-QAM 674 256QAM 10.2/70.2 38.6 JA 13 SC-QAM 682 256QAM 10.7/70.7 39 JA 14 SC-QAM 690 256QAM 10.9/70.9 39 JA 15 SC-QAM 698 64QAM 4.2/64.2 33.9 JA 16 SC-QAM 706 64QAM 4.7/64.7 34.3 JA 17 SC-QAM 714 64QAM 4.2/64.2 33.9 JA 18 SC-QAM 722 64QAM 4.4/64.4 33.8 JA 19 SC-QAM 730 64QAM 4.9/64.9 33.9 JA 20 SC-QAM 738 64QAM 5.2/65.2 33.9 JA 21 SC-QAM 746 64QAM 6/66 34.3 JA 22 SC-QAM 754 64QAM 6.1/66.1 34.3 JA 23 SC-QAM 762 64QAM 6/66 34.4 JA 24 SC-QAM 770 64QAM 6.6/66.6 35 JA 25 SC-QAM 778 64QAM 6.5/66.5 34.9 JA 26 SC-QAM 786 64QAM 6.4/66.4 35 JA 27 SC-QAM 794 64QAM 6.8/66.8 34.9 JA 28 SC-QAM 802 64QAM 6.1/66.1 34.9 JA 29 SC-QAM 810 64QAM 5.6/65.6 34.4 JA 30 SC-QAM 818 64QAM 3.4/63.4 33.3 JA 31 SC-QAM 826 64QAM 1.3/61.3 32.6 JA 32 SC-QAM 834 64QAM -0.2/59.8 31.9 JA Upstream-Kanäle Kanal ID Kanaltyp Frequenz (MHz) Modulation Send. Signalstärke (dBmV/dBµV) Ranging Status 9 OFDMA 29.8~64.8 16_QAM 43.5/103.5 Erfolgreich 1 SC-QAM 51 64QAM 45/105 Erfolgreich 4 SC-QAM 31 32QAM 45/105 Erfolgreich 3 SC-QAM 37 64QAM 47/107 Erfolgreich 2 SC-QAM 45 64QAM 47/107 Erfolgreich
Warum funktioniert der OFDMA nicht und warum wird nicht daran gearbeitet diesen zum arbeiten zu bringen?
Für mich bedeutet dass das der 3rd Level gar nicht an meinem Fall beschäftigt war, dieser die weiße Fahne gehisst hat und zurück rudert. Die Abschaltung des ODFAM's bekommt der 3rd Level auch nicht hin.
Für die Lösung des OFDMA Probems sind ca. 3 Monate für nichts vergeudet worden, dem Kunden jedoch vorgegaukelt worden das sich was bewegen wird. Starker Tobak
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
15.11.2021 15:04 - bearbeitet 15.11.2021 15:08
Huch, was für ein phänomenaler Upload
Test1 30sek. 14.1. Einen Fullspeed gibt es für 15sek.
Noch besser 15.11.21 für 300sek. upload. Fantastisch gut sind die Werte um 0.0 (Null, Null)
Für 235sek wird bei 3MBits umher gedümpelt.
Werden weiter Ziegen angestarrt, arbeitet jemand daran, wird auf eine göttliche Eingebung gewartet oder habe die paranormalen Kräfte der Damen & Herren die auf Ziegen starren versagt?
Wann wird das Casa D3.1 Problem gelöst?
Ich kann meine NAS nur eingeschränkt nutzen.
Eigentlich sollte ich von VF Schmerzenzgeld bekommen, stattdessen zahle ich für das Vergnügen.
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
am 16.11.2021 11:58
"Für die Lösung des OFDMA Probems sind ca. 3 Monate für nichts vergeudet worden, dem Kunden jedoch vorgegaukelt worden das sich was bewegen wird. Starker Tobak"
Man kann hier nur noch volle Absicht unterstellen. Siehe auch die aktuell letzten beiden Antworten von Claudia und mir in meinen Thread. Wieso würde man sonst fast 1500€ für die nächsten 1,5 Jahre ohne irgendeine Gegenwehr aufgeben? Offensichtlich weiß man, dass man nicht einfach zu reparierenden Schrott verkauft hat, wegen dem einen jeder Richter in einem Verfahren auslachen würde. Mit Unfähigkeit des ersten Wellenbrechers für Reklamationen ist das nicht mehr zu erklären. Und dafür sollte es von der Bundesnetzagentur mal gehörig eins auf den Deckel geben.
16.11.2021 16:49 - bearbeitet 16.11.2021 16:53
Da anscheinend noch länger auf Ziegen gestarrt wird und ein Ende des unbefriedigenden Zustands nicht absehbar ist, unterbreite ich den Vorschlag damit ich meine NAS nutzen kann:
VF stellt einen kostenlosen DSL Anschluss mit DSL 40MBit Upload. Damit kann ich durch Policy based Routing mein NAS von extern wieder von extern nutzen.
Nach Beendigung der erfolgreichen Entstörung mit anschließender Prüfung meinerseits wird der DSL Anschluss gekündigt.
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team
am 17.11.2021 14:31
Auf und nieder immer wieder, fantastisch
Upload tcp Test für 300sek.
@Claudia @Tobias @Jana478 @Martin59
Zudem wurde ich heute angehalten einen Techniker ins Haus zu lassen. Das ist doch ein schlechter Scherz?
Eine mehrfach geprüfte Leitung wieder pegeln? Oder soll was anderes gemacht werden?
Downstream-Kanäle Kanal ID Kanaltyp Frequenz (MHz) Modulation Empf. Signalstärke (dBmV/dBµV) SNR/MER (dB) Lock Status 33 OFDM 151~324 1024QAM 9.3/69.3 42 JA 5 SC-QAM 602 256QAM 9.6/69.6 39 JA 2 SC-QAM 130 256QAM 8.6/68.6 39 JA 3 SC-QAM 138 256QAM 7.8/67.8 39 JA 4 SC-QAM 146 256QAM 7.8/67.8 38.6 JA 1 SC-QAM 114 256QAM 8.8/68.8 38.6 JA 6 SC-QAM 618 256QAM 10.2/70.2 39 JA 7 SC-QAM 626 256QAM 10.7/70.7 39 JA 8 SC-QAM 642 256QAM 11.5/71.5 39 JA 9 SC-QAM 650 256QAM 10.7/70.7 39 JA 10 SC-QAM 658 256QAM 10.5/70.5 38.6 JA 11 SC-QAM 666 256QAM 10.4/70.4 39 JA 12 SC-QAM 674 256QAM 10.3/70.3 38.6 JA 13 SC-QAM 682 256QAM 10.8/70.8 39 JA 14 SC-QAM 690 256QAM 11.1/71.1 39 JA 15 SC-QAM 698 64QAM 4.5/64.5 33.9 JA 16 SC-QAM 706 64QAM 5/65 34.3 JA 17 SC-QAM 714 64QAM 4.4/64.4 33.9 JA 18 SC-QAM 722 64QAM 4.7/64.7 33.9 JA 19 SC-QAM 730 64QAM 5.3/65.3 33.9 JA 20 SC-QAM 738 64QAM 5.5/65.5 33.9 JA 21 SC-QAM 746 64QAM 6.3/66.3 34.4 JA 22 SC-QAM 754 64QAM 6.4/66.4 34.4 JA 23 SC-QAM 762 64QAM 6.3/66.3 34.4 JA 24 SC-QAM 770 64QAM 6.9/66.9 35 JA 25 SC-QAM 778 64QAM 6.9/66.9 35 JA 26 SC-QAM 786 64QAM 6.8/66.8 35 JA 27 SC-QAM 794 64QAM 7.1/67.1 34.9 JA 28 SC-QAM 802 64QAM 6.3/66.3 34.9 JA 29 SC-QAM 810 64QAM 5.8/65.8 34.4 JA 30 SC-QAM 818 64QAM 3.7/63.7 33.3 JA 31 SC-QAM 826 64QAM 1.7/61.7 32.6 JA 32 SC-QAM 834 64QAM 0.1/60.1 31.9 JA Upstream-Kanäle Kanal ID Kanaltyp Frequenz (MHz) Modulation Send. Signalstärke (dBmV/dBµV) Ranging Status 9 OFDMA 29.8~64.8 16_QAM 43.2/103.2 Erfolgreich 1 SC-QAM 51 64QAM 45/105 Erfolgreich 4 SC-QAM 31 64QAM 47/107 Erfolgreich 3 SC-QAM 37 64QAM 47/107 Erfolgreich 2 SC-QAM 45 64QAM 47/107 Erfolgreich
Was soll das, dieses Ticket war doch dem OFDMA Bypass zugeordnet, oder?
Liebes VF Team, ihr habt den Überblick verloren?
Das an mir zu zahlende Schmerzenzgeld ist gar nicht mal eine so schlechte Idee.
Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team