Unitymedia Intel Puma Plattform

[F-orced-customer]

Ich auch aber nicht mehr so schlimm um die Zeit, tcp ohne retries:

<i>
</i>$ iperf3 -c ping.online.net -p 5209 -u -R -P10
[SUM] 0.00-10.00 sec 12.6 MBytes 10.6 Mbits/sec 21.589 ms 38/1605 (2.4%)
$ iperf3 -c ping.online.net -p 5209 -R
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 64.1 MBytes 53.8 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 62.8 MBytes 52.7 Mbits/sec receiver

 

[xymox]

Sorry for Google translation Sorry für die Google Übersetzung

Ich bin der Typ, der mit der Presse, ISPs, Intel, Arris und anderen auf dem Intel Puma arbeitet. Ich habe die DSLRports.com Puma Threads gestartet.

Mit einer großen Auswahl an Netzwerkprofis aus allen Bereichen führen wir umfangreiche Tests auf der Intel Puma Plattform durch.

Intel hat die Probleme, die wir über Monate haben, bestätigt. JEDE Intel Puma-basierte Geräte hat überall auf der Welt die gleichen Probleme. Es gibt ZERO-Ausnahmen.

Das Problem wirkt sich in hohem Maße auf Latenz und Jitter aus.

Intel hat das Problem von ICMP versteckt und Sie können ICMP Ping nicht verwenden, um das Problem zu erkennen. Sie müssen TCP oder UDP oder ARP verwenden.

Dieses Diagramm wurde auf Kundenseite generiert. Dieses Gerät wurde an den Puma6Fail DoS-Angriff geschickt. Es wurde sehr schnell offline geschaltet und zeigt die erforderliche Bandbreite an. https://github.com/nallar/Puma6Fail/releases

Die Probleme werden alle von Intel bestätigt Google https://translate.google.com/translate?sl=auto&tl=de&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.theregister.co.uk%2F2017%2F08%2F09%2Fintel_puma_modem_woes%2F&edit-text=&act=url English https://www.theregister.co.uk/2017/08/09/intel_puma_modem_woes/

Iperf

Broadcom VS Puma

 

[F-orced-customer]

Iperf

http://www.badmodems.com/modem/iperf/
http://www.badmodems.com/modem/iperf/6190dn.gif
http://www.badmodems.com/modem/iperf/8200up.gif
http://www.badmodems.com/modem/iperf/8200dn.gif

Da bin ich nicht mit einverstanden, bei -f und -k fehlen die Parameter, -b misst nur mit einem stream statt -P, Jitter ist aber erst interessant bei Auslastung mit mehreren Streams (gaming, VoIP RTP), -l 1k -b 2m hängt bei mir den client bei ping.online.net auf nach 8 sek, bei -R verhindert -l 1k allerdings die out-of-order fehler.

Die Begrenzung der udp grösse mit -l 1K ist mir auch nicht klar,
https://www.dslreports.com/forum/r31658318-
die meisten udp anwendungen dürften grösser sein und das schönt doch das Ergebnis:

$ iperf3 -c bouygues.iperf.fr -p 5209 -u -4 -b2m
Connecting to host bouygues.iperf.fr, port 5209
[ 4] local 192.168.0.105 port 50863 connected to 194.158.119.190 port 5209
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 232 KBytes 1.90 Mbits/sec 29
[ 4] 1.00-2.00 sec 240 KBytes 1.97 Mbits/sec 30
[ 4] 2.00-3.00 sec 248 KBytes 2.03 Mbits/sec 31
[ 4] 3.00-4.00 sec 248 KBytes 2.03 Mbits/sec 31
[ 4] 4.00-5.00 sec 240 KBytes 1.97 Mbits/sec 30
[ 4] 5.00-6.00 sec 248 KBytes 2.03 Mbits/sec 31
[ 4] 6.00-7.00 sec 240 KBytes 1.97 Mbits/sec 30
[ 4] 7.00-8.00 sec 248 KBytes 2.03 Mbits/sec 31
[ 4] 8.00-9.00 sec 240 KBytes 1.97 Mbits/sec 30
[ 4] 9.00-10.00 sec 248 KBytes 2.03 Mbits/sec 31
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 2.38 MBytes 1.99 Mbits/sec 34.648 ms 0/303 (0%)
[ 4] Sent 303 datagrams
iperf Done.
$ iperf3 -c bouygues.iperf.fr -p 5209 -u -4 -b2m -l1k
Connecting to host bouygues.iperf.fr, port 5209
[ 4] local 192.168.0.105 port 52231 connected to 194.158.119.190 port 5209
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 221 KBytes 1.81 Mbits/sec 221
[ 4] 1.00-2.00 sec 245 KBytes 2.01 Mbits/sec 245
[ 4] 2.00-3.00 sec 244 KBytes 2.00 Mbits/sec 244
[ 4] 3.00-4.00 sec 244 KBytes 2.00 Mbits/sec 244
[ 4] 4.00-5.00 sec 244 KBytes 2.00 Mbits/sec 244
[ 4] 5.00-6.00 sec 244 KBytes 2.00 Mbits/sec 244
[ 4] 6.00-7.00 sec 244 KBytes 2.00 Mbits/sec 244
[ 4] 7.00-8.00 sec 244 KBytes 2.00 Mbits/sec 244
[ 4] 8.00-9.00 sec 245 KBytes 2.01 Mbits/sec 245
[ 4] 9.00-10.00 sec 244 KBytes 2.00 Mbits/sec 244
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 2.36 MBytes 1.98 Mbits/sec 6.761 ms 0/2419 (0%)
[ 4] Sent 2419 datagrams
iperf Done.
$ iperf3 -c ping.online.net -p 5209 -u -R -b50m
Connecting to host ping.online.net, port 5209
Reverse mode, remote host ping.online.net is sending
[ 4] local 192.168.0.105 port 58793 connected to 62.210.18.40 port 5209
iperf3: OUT OF ORDER - incoming packet = 189 and received packet = 192 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 515 and received packet = 532 AND SP = 4
...
iperf3: OUT OF ORDER - incoming packet = 7478 and received packet = 7482 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7553 and received packet = 7561 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7555 and received packet = 7564 AND SP = 4
[ 4] 9.00-10.00 sec 3.98 MBytes 33.4 Mbits/sec 3.870 ms 239/734 (33%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 2.567 ms 2200/7626 (29%)
[ 4] Sent 7626 datagrams
[SUM] 0.0-10.0 sec 77 datagrams received out-of-order
iperf Done.
$ iperf3 -c ping.online.net -p5209 -u -R -b50m -l1k
Connecting to host ping.online.net, port 5209
Reverse mode, remote host ping.online.net is sending
[ 4] local 192.168.0.105 port 34816 connected to 62.210.18.40 port 5209
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 5.42 MBytes 45.5 Mbits/sec 0.641 ms 1/5550 (0.018%)
[ 4] 1.00-2.00 sec 5.96 MBytes 50.0 Mbits/sec 0.595 ms 0/6104 (0%)
[ 4] 2.00-3.00 sec 5.96 MBytes 50.0 Mbits/sec 0.598 ms 0/6102 (0%)
[ 4] 3.00-4.00 sec 5.96 MBytes 50.0 Mbits/sec 0.534 ms 0/6106 (0%)
[ 4] 4.00-5.00 sec 5.96 MBytes 50.0 Mbits/sec 0.530 ms 0/6104 (0%)
[ 4] 5.00-6.00 sec 5.96 MBytes 50.0 Mbits/sec 0.641 ms 0/6099 (0%)
[ 4] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 0.561 ms 0/6106 (0%)
[ 4] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 0.592 ms 0/6103 (0%)
[ 4] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 0.592 ms 0/6103 (0%)
[ 4] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 0.593 ms 0/6104 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 0.145 ms 1/61051 (0.0016%)
[ 4] Sent 61051 datagrams
iperf Done.

 

[xymox]

311/5000
1) Das Gerät sollte NIEMALS Pakete mit JEDER Paketgröße oder Geschwindigkeit bis zu seinen Grenzen verlieren. So versagt der Puma an diesem Punkt. Es sind keine weiteren Tests erforderlich. Der Chip ist fehlgeschlagen.

2) Mehr Streams führen zu einem schnelleren Fehler

3) Dieses Problem bezieht sich auf Paket pro Sekunde, sodass kleinere Pakete das Problem leichter zu erkennen sind.

DIESE AUSGABE WURDE VON INTEL GETESTET UND ÜBERPRÜFT UND IN EINER PRESSE-STORY BESTÄTIGT. DIES WIRD ALLE PUMA-GERÄTE BEEINTRÄCHTIGT.

Es gibt keine Notwendigkeit, die Frage zu debattieren.

ES IST EINE VON INTEL BESTÄTIGTE TATSACHE.

English, sorry
https://www.youtube.com/watch?time_continue=1&v=15cJ400yR_E


Ich empfehle, Pingplotter zu verwenden und das Intervall so schnell wie möglich einzustellen. Wie 0,01 100 Tests pro Sekunde. 30 pro Sekunde ist genug.

Setze Pingplotter auf TCP, indem du winpcap installierst

Suchen Sie ein TCP-Ziel, das nahe ist, vielleicht google.com und Port 80 verwenden.

Das Problem wird deutlich sichtbar.

In den USA kann ich Modems in wenigen Minuten austauschen. Also habe ich viele Tests gemacht, die ein direktes AB machen.

Die Leistung von Intel Puma ist schrecklich im Vergleich zu einem 12 Jahre alten DOCSIS 2 Modem.

 

[xymox]

beachte das Datum in diesem Artikel. Intel bestätigte dieses Problem im Artikel

https://translate.google.com/translate?sl=auto&tl=de&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.theregister.co.uk%2F2016%2F12%2F03%2Fintel_puma_chipset_firmware_fix%2F&edit-text=&act=url

 

[xymox]

Das Problem wurde von Netzwerkspezialisten getestet, die bei Intel Networking-Chips herstellen. Meine Testergebnisse wurden von Intel, Arris und zahlreichen Leuten am DSLR-Thread bestätigt. Wir haben alle ein breites Werkzeugspektrum in einer Vielzahl von Umgebungen eingesetzt. Eine große Auswahl an ISP hat das Problem ebenfalls bestätigt.

 

[F-orced-customer]

3) Dieses Problem bezieht sich auf Paket pro Sekunde, sodass kleinere Pakete das Problem leichter zu erkennen sind.

DIESE AUSGABE WURDE VON INTEL GETESTET UND ÜBERPRÜFT UND IN EINER PRESSE-STORY BESTÄTIGT. DIES WIRD ALLE PUMA-GERÄTE BEEINTRÄCHTIGT.

That's copied, we're just discussing iperf3 in general now, thanks:
https://www.dslreports.com/forum/r31658342-

 

[Edding]

iperf3 -c bouygues.iperf.fr -p 5200 -u -l 1k -b 500000k -w 510M -t 30 -i 1 -R -f -k -V --get-server-output
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-30.00 sec 1.75 GBytes 500 Mbits/sec 0.021 ms 329123/1832493 (18%)
[ 4] Sent 1832493 datagrams
[SUM] 0.0-30.0 sec 858 datagrams received out-of-order
CPU Utilization: local/receiver 49.5% (18.0%u/31.5%s), remote/sender 0.4% (0.0%u/0.4%s)
[ 4] 29.00-30.00 sec 51.4 MBytes 431 Mbits/sec 0.017 ms 8439/61043 (14%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Server output:
Accepted connection from XXX, port 3982
[ 5] local 194.158.119.190 port 5200 connected to XXX port 60913
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 55.0 MBytes 461 Mbits/sec 56275
[ 5] 1.00-2.00 sec 59.6 MBytes 500 Mbits/sec 61034
[ 5] 2.00-3.00 sec 59.6 MBytes 500 Mbits/sec 61074
[ 5] 3.00-4.00 sec 59.6 MBytes 500 Mbits/sec 60993
[ 5] 4.00-5.00 sec 59.6 MBytes 500 Mbits/sec 61054
[ 5] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec 61036
[ 5] 6.00-7.00 sec 59.6 MBytes 500 Mbits/sec 61071
[ 5] 7.00-8.00 sec 59.6 MBytes 500 Mbits/sec 60990
[ 5] 8.00-9.00 sec 59.6 MBytes 500 Mbits/sec 61037
[ 5] 9.00-10.00 sec 59.6 MBytes 500 Mbits/sec 61040
[ 5] 10.00-11.00 sec 59.6 MBytes 500 Mbits/sec 61046
[ 5] 11.00-12.00 sec 59.6 MBytes 500 Mbits/sec 61029
[ 5] 12.00-13.00 sec 59.6 MBytes 500 Mbits/sec 61029
[ 5] 13.00-14.00 sec 59.6 MBytes 500 Mbits/sec 61040
[ 5] 14.00-15.00 sec 59.9 MBytes 503 Mbits/sec 61377
[ 5] 15.00-16.00 sec 59.3 MBytes 497 Mbits/sec 60714
[ 5] 16.00-17.00 sec 59.9 MBytes 503 Mbits/sec 61377
[ 5] 17.00-18.00 sec 59.6 MBytes 500 Mbits/sec 61042
[ 5] 18.00-19.00 sec 59.6 MBytes 500 Mbits/sec 61016
[ 5] 19.00-20.00 sec 59.6 MBytes 500 Mbits/sec 61031
[ 5] 20.00-21.00 sec 59.5 MBytes 499 Mbits/sec 60899
[ 5] 21.00-22.00 sec 59.7 MBytes 501 Mbits/sec 61180
[ 5] 22.00-23.00 sec 59.6 MBytes 500 Mbits/sec 61001
[ 5] 23.00-24.00 sec 59.6 MBytes 500 Mbits/sec 61008
[ 5] 24.00-25.00 sec 59.6 MBytes 500 Mbits/sec 61057
[ 5] 25.00-26.00 sec 59.6 MBytes 500 Mbits/sec 61037
[ 5] 26.00-27.00 sec 59.6 MBytes 500 Mbits/sec 61003
[ 5] 27.00-28.00 sec 59.6 MBytes 500 Mbits/sec 61004
[ 5] 28.00-29.00 sec 59.4 MBytes 498 Mbits/sec 60796
[ 5] 29.00-30.00 sec 59.7 MBytes 501 Mbits/sec 61132
[ 5] 30.00-30.07 sec 5.95 MBytes 725 Mbits/sec 6095
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-30.07 sec 1.75 GBytes 499 Mbits/sec 0.000 ms 0/1832517 (0%)

 

[F-orced-customer]

iperf3 -c bouygues.iperf.fr -p 5200 -u -l 1k -b 500000k -w 510M -t 30 -i 1 -R -f -k -V --get-server-output
[SUM] 0.0-30.0 sec 858 datagrams received out-of-order

Da stimmt was nicht und wie kommst Du auf -w 510M?

...

Und soviel zum vermuteten Puma fix in der AVM 64/6590 6.84:
https://www.dslreports.com/forum/r31658415-

 

[addicted]

xymox: Please post in english. It will be easier to understand for most of the people active in this thread, since GTranslate won't mess up sentence structure. We will translate to german ourselves if any forum member doesn't understand english well enough.

Also, and you MUST know this: Telling people that verification of an issue is not necessary sounds like you're advocating a religion. Please don't do that. I understand that you have invested a lot of time in this issue and are reluctant to explain the basic facts again and again, but please don't waste your credibility over a little thing like a proper argument.

 

[Edding]

iperf3 -c bouygues.iperf.fr -p 5200 -u -l 1k -b 500000k -w 510M -t 30 -i 1 -R -f -k -V --get-server-output
[SUM] 0.0-30.0 sec 858 datagrams received out-of-order

Da stimmt was nicht und wie kommst Du auf -w 510M?

...

Und soviel zum vermuteten Puma fix in der AVM 64/6590 6.84:
https://www.dslreports.com/forum/r31658415-

das iperf cmd ist von hir
https://www.dslreports.com/forum/r31658342-

 

[F-orced-customer]

Der hat ne 900er -Leitung, Du musst -b an Deine anpassen :zwinker:

 

[nts]

Also, and you MUST know this: Telling people that verification of an issue is not necessary sounds like you're advocating a religion. Please don't do that

Womöglich wäre es trotzdem besser die ganzen Testergebnisse hier in einen eigenen Thread auszulagern? Endlose Diskussionen über die richtigen iperf Parameter und täglich wiederholte Tests, nur um etwas zu zeigen, was der Rest der Welt schon weiß, tun bis zum nächsten Firmwarerelease oder Statement von Intel doch gar nichts mehr zur Sache.

 

[F-orced-customer]

Also ich fänds interessant das zu reproduzieren :smile:

Leider haben wir Seitenweise invalide PING Tests anstatt Pingplotter, der bei mir auf Linux leider nicht läuft :traurig:
http://badmodems.com/PinrplotterInstructions.htm

Der misst aber keinen Jitter und was geeigneteres als iperf3 fällt mir dafür nicht ein und was ja auch xymox verwendet hat:

vgl.
http://www.badmodems.com/modem/iperf/6190up.gif
http://www.badmodems.com/modem/iperf/6190dn.gif
mit
http://www.badmodems.com/modem/iperf/8200dn.gif
http://www.badmodems.com/modem/iperf/8200up.gif

 

[nts]

Jo klar. Aber für jemanden, der hier nur unregelmäßig reinschaut, sind halt die interessanten Infos unter haufenweise Testergebnissen versteckt. Spricht ja nichts dagegen diese von der allgemeinen Diskussion, News und euren Kontaktversuchen mit Presse/BSI zu trennen, oder?

Leider haben wir Seitenweise invalide PING Tests anstatt Pingplotter, der bei mir auf Linux leider nicht läuft :traurig:
http://badmodems.com/PinrplotterInstructions.htm

Der misst aber keinen Jitter

Den Jitter solltest du als Abweichung der individuellen Paketlaufzeiten im Plot ablesen können.

 

[F-orced-customer]

Klar, noch mit Lineal und Bleistift oder wie

 

[nts]

Sicher, und schön ordentlich bitte

Ich hab übrigens die Tage mal mit hping herumgespielt, soviel zum Testergebnisse Spam :bäh:

 $ sudo hping -S -i u100000 -c 100 -p 80 google.de | grep -Po '(?<=rtt=)[0-9]+' | sort -n | uniq -c | awk '{printf "%sms: %s\n", $2, $1}'
--- google.de hping statistic ---
100 packets tramitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 25.8/36.0/69.8 ms
25ms: 1
26ms: 1
27ms: 4
28ms: 6
29ms: 7
30ms: 4
31ms: 8
32ms: 10
33ms: 7
34ms: 7
35ms: 5
36ms: 8
37ms: 7
38ms: 7
39ms: 1
40ms: 5
41ms: 2
47ms: 1
48ms: 1
49ms: 1
52ms: 1
53ms: 1
56ms: 2
65ms: 2
69ms: 1

Die Ausgabe sollte so mit dem DSL Reports Test vergleichbar sein, ist dann aber nicht mehr vom Browser abhängig. Windows Nutzer könnten bei PsPing mit der -h Option direkt eine entsprechende Ausgabe erhalten, hab ich aber nicht ausprobiert.

 

[F-orced-customer]

Jo das kommt hin, gute Arbeit :smile:

# hping3 -S -i u100000 -c 200 -p 80 google.de | grep -Po '(?<=rtt=)[0-9]+' | sort -n | uniq -c | awk '{printf "%sms: %s\n", $2, $1}'
--- google.de hping statistic ---
200 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max = 16.5/34.2/1017.6 ms
16ms: 2
17ms: 6
18ms: 7
19ms: 10
20ms: 7
21ms: 12
22ms: 17
23ms: 20
24ms: 22
25ms: 12
26ms: 15
27ms: 12
28ms: 10
29ms: 6
30ms: 5
31ms: 4
32ms: 5
34ms: 1
35ms: 4
36ms: 2
38ms: 1
41ms: 1
43ms: 1
44ms: 1
45ms: 1
46ms: 2
48ms: 1
57ms: 1
63ms: 2
66ms: 1
71ms: 1
73ms: 1
85ms: 1
99ms: 1
102ms: 1
106ms: 1
111ms: 1
132ms: 1
1017ms: 1

Connect Box Puma 6, 50/2

 

[MartinP_Do]

Ich habe keine Ausreißer > 100 ms

6490 UM FW 6.50, 2Play 100

<i>
</i> sudo hping3 -S -i u100000 -c 100 -p 80 google.de | grep -Po '(?<=rtt=)[0-9]+' | sort -n | uniq -c | awk '{printf "%sms: %s\n", $2, $1}'
--- google.de hping statistic ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 15.5/20.8/43.0 ms
15ms: 1
16ms: 6
17ms: 19
18ms: 15
19ms: 22
20ms: 6
21ms: 4
22ms: 3
23ms: 5
24ms: 6
26ms: 3
27ms: 2
28ms: 1
29ms: 1
30ms: 2
31ms: 2
33ms: 1
43ms: 1

 

[nts]

Hm, versucht es mal mit einem kürzeren Intervall, xymox empfiehlt weiter oben ja 30-100 Pakete pro Sekunde

$ sudo hping -S -i u10000 -c 1000 -p 80 google.de | grep -Po '(?<=rtt=)[0-9]+' | sort -n | uniq -c | awk '{printf "%sms: %s\n", $2, $1}'
--- google.de hping statistic ---
1000 packets tramitted, 1000 packets received, 0% packet loss
round-trip min/avg/max = 13.8/24.3/1018.9 ms
13ms: 2
14ms: 22
15ms: 70
16ms: 106
17ms: 122
18ms: 136
19ms: 124
20ms: 143
21ms: 93
22ms: 61
23ms: 23
24ms: 10
25ms: 8
26ms: 7
27ms: 4
28ms: 2
29ms: 8
30ms: 5
31ms: 4
32ms: 8
33ms: 5
34ms: 3
35ms: 4
36ms: 4
39ms: 1
40ms: 1
42ms: 1
44ms: 1
46ms: 5
47ms: 2
48ms: 2
49ms: 3
50ms: 2
51ms: 2
52ms: 1
54ms: 1
1016ms: 1
1018ms: 3

EPC3212, also nicht betroffen

 

[F-orced-customer]

man hping3

-i --interval
Wait the specified number of seconds or micro seconds between sending each packet. --interval X set wait to X seconds, --interval uX set
wait to X micro seconds. The default is to wait one second between each packet. Using hping3 to transfer files tune this option is really
important in order to increase transfer rate. Even using hping3 to perform idle/spoofing scanning you should tune this option, see
HPING3-HOWTO for more information.

# hping3 -S -i u50000 -c 200 -p 80 google.de | grep -Po '(?<=rtt=)[0-9]+' | sort -n | uniq -c | awk '{printf "%sms: %s\n", $2, $1}'
--- google.de hping statistic ---
200 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max = 15.7/31.1/124.5 ms
15ms: 1
17ms: 2
18ms: 5
19ms: 3
20ms: 15
21ms: 9
22ms: 15
23ms: 20
24ms: 14
25ms: 21
26ms: 14
27ms: 15
28ms: 9
29ms: 7
30ms: 7
31ms: 6
32ms: 5
33ms: 1
34ms: 3
35ms: 4
36ms: 3
38ms: 1
40ms: 1
44ms: 1
47ms: 1
53ms: 2
64ms: 2
69ms: 1
70ms: 1
74ms: 1
77ms: 1
79ms: 1
91ms: 1
94ms: 1
102ms: 1
112ms: 1
113ms: 1
118ms: 1
121ms: 1
124ms: 1

 

[nts]

-i u10000 (also 100 pro Sekunde) sollten schon drin sein. -n muss man dann halt anpassen, damit der Test wieder etwas länger läuft

 

[JPDribbler]

Sicher, und schön ordentlich bitte

Ich hab übrigens die Tage mal mit hping herumgespielt, soviel zum Testergebnisse Spam :bäh:
$ sudo hping -S -i u100000 -c 100 -p 80 google.de | grep -Po '(?<=rtt=)[0-9]+' | sort -n | uniq -c | awk '{printf "%sms: %s\n", $2, $1}'

Die Ausgabe sollte so mit dem DSL Reports Test vergleichbar sein, ist dann aber nicht mehr vom Browser abhängig. Windows Nutzer könnten bei PsPing mit der -h Option direkt eine entsprechende Ausgabe erhalten, hab ich aber nicht ausprobiert.

Sehr gut. Vielen Dank dafür, das ist sehr hilfreich. :super: Na dann schick ich mal meine Kündigung an Unitymedia los (mit Verweis auf den Puma Bug.)

 

[Andreas1969]

Sehr gut. Vielen Dank dafür, das ist sehr hilfreich. Na dann schick ich mal meine Kündigung an Unitymedia los (mit Verweis auf den Puma Bug.)

Da bin ich mal gespannt, ob sie den Dropps lutschen :kratz:
Halt uns mal auf dem Laufenden.

 

[JPDribbler]

Sehr gut. Vielen Dank dafür, das ist sehr hilfreich. Na dann schick ich mal meine Kündigung an Unitymedia los (mit Verweis auf den Puma Bug.)

Da bin ich mal gespannt, ob sie den Dropps lutschen :kratz:
Halt uns mal auf dem Laufenden.

Da wird nichts passieren. Aber vllt. liest sich ja einer den Grund der Kündigung durch...

Weiss jemand welche Modems Kabel Deutschland / Vodafone einsetzt? Gerne würde ich einen Vodafone Kunden dazu bringen sich zu beschweren. Umso mehr Druck, umso besser.

Hat jemand zudem bereits AVM wegen der Fritzbox kontaktiert? Auch die sollten hier drauf aufmerksam gemacht werden.

Zudem überlege ich auch noch mal die EU zu kontaktieren, kann nicht schaden:

https://www.first.org/members/teams/cert-eu

Team Name CERT-EU
Official Team Name Computer Emergency Response Team (CERT-EU) for the EU institutions, agencies and bodies
Date of Approval 2014-07-17
Host Organization European Commission
Country of Team Belgium BE
Other Countries of Team Europe EU
Date of Establishment 2011-01-06
Website cert.europa.eu

https://www.kdgforum.de/viewtopic.php?f=69&t=38504