• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Unitymedia UDP Packetloss 1-3%

Diskutiere UDP Packetloss 1-3% im Störungen im Kabelnetz Forum im Bereich Rund um Internet; Hallo, Seit ca. 2 Wochen oder ein bisschen länger habe ich einen UDP Packetloss. Das heißt, ich habe in Teamspeak (Ausgehend und Eingehend) einen...
  • UDP Packetloss 1-3% Beitrag #1

T0XiiC

Beiträge
8
Punkte Reaktionen
0
Hallo,

Seit ca. 2 Wochen oder ein bisschen länger habe ich einen UDP Packetloss. Das heißt, ich habe in Teamspeak (Ausgehend und Eingehend) einen Packetloss von 1-3%.
Unitymedia Support (über Facebook) sagte mir dass bei mir keine Störung vorliegt, das kann aber nicht sein da es 100% nicht an meinem PC liegt (Mit 2 Geräten getestet)
Das komische ist, der Paketverlust verschwindet sobald ich mehrmals im Router meine IP erneuere. Werkreset habe ich schon durchgeführt, Firewall ist auch keine an im Router.

Habs auch schon über OpenVPN (also anderes Routing) getestet, selbes Problem.

ping google.de -n 1000 (über CMD) ergab bei mir 0% Loss, einmal mit IPV4 und IPV6 getestet.

MTR zu heise und netcup (Habe einfach 2 Zufällige seiten genommen)
Code: 
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|HSI-KBW-85-216-127-204.hsi.kabel-badenwuerttemberg.de - 1 | 1033 | 1023 | 8 | 10 | 44 | 11 |
| 84.116.191.2 - 0 | 1071 | 1071 | 11 | 13 | 44 | 13 |
| de-fra04a-rc1-ae2-0.aorta.net - 0 | 1071 | 1071 | 11 | 21 | 87 | 14 |
| de-fra04a-rc1-ae2-0.aorta.net - 0 | 1071 | 1071 | 11 | 13 | 44 | 14 |
| te0-0-2-3.c350.f.de.plusline.net - 0 | 1071 | 1071 | 12 | 14 | 27 | 13 |
| 82.98.102.5 - 1 | 1064 | 1062 | 11 | 14 | 161 | 13 |
| 212.19.61.13 - 1 | 1045 | 1038 | 9 | 13 | 164 | 12 |
| www.heise.de - 1 | 1052 | 1047 | 11 | 13 | 27 | 13 |
|________________________________________________|______|______|______|______|______|______|

Code: 
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| HSI-KBW-085-216-125-206.hsi.kabelbw.de - 0 | 1060 | 1060 | 8 | 11 | 60 | 9 |
| 213.46.177.21 - 1 | 1056 | 1055 | 11 | 13 | 75 | 12 |
| 213.46.177.21 - 0 | 1060 | 1060 | 11 | 24 | 109 | 14 |
| de-fra01b-ri1-ae1-0.aorta.net - 0 | 1060 | 1060 | 11 | 14 | 65 | 11 |
| de-fra01a-ri2-xe-2-0-0.aorta.net - 0 | 1060 | 1060 | 11 | 13 | 31 | 14 |
| ae3-2003.nbg40.core-backbone.com - 0 | 1060 | 1060 | 14 | 16 | 50 | 15 |
| gw-cb40.nbg.netcup.net - 0 | 1060 | 1060 | 14 | 17 | 65 | 16 |
| www.netcup.de - 2 | 1006 | 992 | 14 | 16 | 58 | 17 |
|________________________________________________|______|______|______|______|______|______|



Modemwerte (Falls diese etwas ausmachen)

Upstream:
jUUTGqX.jpg


Downstream:
hOnX8Lx.jpg


Pingtest.net:
lfNljnd.jpg


Der Jitter (falls er wichtig ist) schwankt zwischen 0-3 je nach Server und Test.


Komme aus dem Raum Stuttgart. 100 / 5 Internet Vertrag. Beim Speedtest erreiche ich die normalen werte (106 Down, 4.95 UP)
 
  • UDP Packetloss 1-3% Beitrag #2
T0XiiC schrieb:
Seit ca. 2 Wochen oder ein bisschen länger habe ich einen UDP Packetloss.

MTR zu heise und netcup (Habe einfach 2 Zufällige seiten genommen)
Zum Vergrößern anklicken....

Evtl. liegt es am ttl.
Bei mtr mit udp wird der ttl beim Senden der udp-Pakete, von 1 bis max. 15 erhöht bzw. auch der udp-dst-Port geändert, und wenn vom Ziel bis dann keine Antwort kommt, dann gibt mtr auf (d. h. "packet loss"). Die meisten Ziele antworten nicht, wenn per udp auf einen nicht lauschenden udp-Port gescannt wird. Hier z. B. eine Antwort per icmp (, dass der "udp port 33014 unreachable" ist), nach einer ttl von 7:
Code: 
<i>
</i>09:59:38.579364 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 1, id 29279, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33008: [no cksum] UDP, length 36
09:59:38.829253 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 2, id 29291, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33009: [no cksum] UDP, length 36
09:59:39.079523 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 3, id 29310, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33010: [no cksum] UDP, length 36
09:59:39.329809 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 4, id 29321, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33011: [no cksum] UDP, length 36
09:59:39.580110 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 5, id 29325, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33012: [no cksum] UDP, length 36
09:59:39.830381 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 6, id 29333, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33013: [no cksum] UDP, length 36
09:59:40.080668 Out ##:##:##:xx:xx:xx ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 7, id 29335, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33014: [no cksum] UDP, length 36
09:59:40.096372 In 00:xx:xx:xx:xx:xx ethertype IPv4 (0x0800), length 72: (tos 0xc0, ttl 247, id 9369, offset 0, flags [none], proto ICMP (1), length 56) 82.98.102.5 > yx.yxx.xx5.yx: ICMP 82.98.102.5 udp port 33014 unreachable, length 36	(tos 0x3,CE, ttl 1, id 29335, offset 0, flags [none], proto UDP (17), length 64) yx.yxx.xx5.yx.10274 > 82.98.102.5.33014: [no cksum] UDP, length 36
Die hier gesendeten und nicht beantworteten udp-Pakete mit der ttl von 1 bis 6, werden von mtr nicht als "packet loss" betrachtet, denn auf das nachfolgende gesendete udp-Paket mit der ttl7 ist ja eine Antwort gekommen. BTW: Ausgehend hat evtl. UM das ECN-Bit (tos 0x3,CE) für die udp-Pakete gesetzt (... siehe oben in der icmp-Antwort mit einer ttl von 247).

Der mtr mit udp war so:
Code: 
<i>
</i> ~ $ mtr -4nur -c 2 -i 2 82.98.102.5
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- 46.###.###.## 0.0% 2 10.9 9.9 8.9 10.9 1.4 2.|-- 172.30.10.77 0.0% 2 21.7 15.6 9.5 21.7 8.6 3.|-- 84.116.190.129 0.0% 2 8.9 9.7 8.9 10.5 1.2 4.|-- 78.42.40.4 0.0% 2 7.2 8.1 7.2 9.0 1.3 5.|-- 84.116.140.209 0.0% 2 12.0 14.0 12.0 16.0 2.9 6.|-- 80.81.193.132 0.0% 2 14.3 15.4 14.3 16.5 1.5 7.|-- 82.98.102.5 0.0% 2 15.9 16.6 15.9 17.2 0.9
Der mtr mit udp zu http://www.heise.de ist so:
Code: 
<i>
</i> ~ $ mtr -4nur -c 10 -i 2 www.heise.de
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- 46.###.###.## 0.0% 10 9.8 9.5 8.1 15.7 2.2 2.|-- 172.30.10.77 0.0% 10 8.6 9.9 7.4 14.5 2.4 3.|-- 84.116.190.129 0.0% 10 13.6 11.5 8.0 23.0 4.4 4.|-- 78.42.40.4 0.0% 10 9.9 10.3 8.2 12.9 1.8 5.|-- 84.116.190.2 0.0% 10 10.8 12.2 10.5 14.7 1.7 | `|-- 84.116.140.209 6.|-- 80.81.193.132 0.0% 10 12.5 13.0 11.3 15.0 1.0 7.|-- 82.98.102.5 0.0% 10 13.9 13.3 12.1 14.8 0.9 8.|-- 212.19.61.13 80.0% 10 14.9 14.8 14.8 14.9 0.1 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- 212.19.61.13 80.0% 10 16.3 15.4 14.4 16.3 1.3 11.|-- 212.19.61.13 70.0% 10 14.3 13.9 13.2 14.3 0.6 12.|-- 212.19.61.13 90.0% 10 13.6 13.6 13.6 13.6 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- 212.19.61.13 90.0% 10 12.8 12.8 12.8 12.8 0.0 15.|-- 212.19.61.13 66.7% 9 12.3 11.8 11.4 12.3 0.4 16.|-- 212.19.61.13 87.5% 8 12.4 12.4 12.4 12.4 0.0 17.|-- 212.19.61.13 87.5% 8 15.5 15.5 15.5 15.5 0.0 18.|-- ??? 100.0 6 0.0 0.0 0.0 0.0 0.0 19.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 20.|-- ??? 100.0 4 0.0 0.0 0.0 0.0 0.0 21.|-- ??? 100.0 4 0.0 0.0 0.0 0.0 0.0 22.|-- 212.19.61.13 66.7% 3 10.4 10.4 10.4 10.4 0.0 23.|-- ??? 0.0% 0 0.0 0.0 0.0 0.0 0.0
BTW: Auch Raum Stuttgart.
 
  • UDP Packetloss 1-3% Beitrag #3
Willkommen im Club, geht mir auch so Raum Wesel/Duisburg

*edit* nur geht es nicht per ip reset weg.

http://www.unitymediaforum.de/viewtopic.php?f=77&t=32355
 
  • UDP Packetloss 1-3% Beitrag #4
T0XiiC schrieb:
... UDP Packetloss. ...
Zum Vergrößern anklicken....

Ein tool mit dem man lauschende udp-Ports pingen kann, ist z. B. nping:
Code: 
<i>
</i>$ sudo nping --udp --ttl 72 --data-length 60 -c 10 -g 56333 -p 53 82.212.62.62
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2015-12-18 16:25 CET
SENT (0.0375s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (0.0477s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23055 iplen=40
SENT (1.0380s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (1.0503s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55276 iplen=40
SENT (2.0394s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (2.0515s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23056 iplen=40
SENT (3.0416s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (3.0518s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55277 iplen=40
SENT (4.0439s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (4.0539s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=19166 iplen=40
SENT (5.0460s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (5.0576s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55278 iplen=40
SENT (6.0477s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (6.0603s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55279 iplen=40
SENT (7.0494s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (7.0845s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23057 iplen=40
SENT (8.0517s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (8.0637s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23058 iplen=40
SENT (9.0538s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (9.0637s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55280 iplen=40
Max rtt: 34.957ms | Min rtt: 9.767ms | Avg rtt: 13.426ms
Raw packets sent: 10 (880B) | Rcvd: 10 (400B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 9.11 seconds
 
  • UDP Packetloss 1-3% Beitrag #5
tq1199 schrieb:
T0XiiC schrieb:
... UDP Packetloss. ...
Zum Vergrößern anklicken....

Ein tool mit dem man lauschende udp-Ports pingen kann, ist z. B. nping:
Code: 
<i>
</i>$ sudo nping --udp --ttl 72 --data-length 60 -c 10 -g 56333 -p 53 82.212.62.62
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2015-12-18 16:25 CET
SENT (0.0375s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (0.0477s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23055 iplen=40
SENT (1.0380s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (1.0503s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55276 iplen=40
SENT (2.0394s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (2.0515s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23056 iplen=40
SENT (3.0416s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (3.0518s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55277 iplen=40
SENT (4.0439s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (4.0539s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=19166 iplen=40
SENT (5.0460s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (5.0576s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55278 iplen=40
SENT (6.0477s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (6.0603s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55279 iplen=40
SENT (7.0494s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (7.0845s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23057 iplen=40
SENT (8.0517s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (8.0637s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=23058 iplen=40
SENT (9.0538s) UDP 192.168.178.21:56333 > 82.212.62.62:53 ttl=72 id=14204 iplen=88
RCVD (9.0637s) UDP 82.212.62.62:53 > 192.168.178.21:56333 ttl=58 id=55280 iplen=40
Max rtt: 34.957ms | Min rtt: 9.767ms | Avg rtt: 13.426ms
Raw packets sent: 10 (880B) | Rcvd: 10 (400B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 9.11 seconds
Zum Vergrößern anklicken....


Soll ich mir auch mal nping runterladen und schauen was ich für werte bekomme?

Edit: Bekomme es unter WIndows irgendwie nicht zum laufen :(
Datacrash schrieb:
Willkommen im Club, geht mir auch so Raum Wesel/Duisburg

*edit* nur geht es nicht per ip reset weg.

http://www.unitymediaforum.de/viewtopic.php?f=77&t=32355
Zum Vergrößern anklicken....


Ich weiß selbst nicht warum er Packetloss dann verschwindet, das ist verdammt komisch..
 
  • UDP Packetloss 1-3% Beitrag #6
T0XiiC schrieb:
Soll ich mir auch mal nping runterladen und schauen was ich für werte bekomme?

Edit: Bekomme es unter WIndows irgendwie nicht zum laufen :(
Zum Vergrößern anklicken....

Was funktioniert unter Windows nicht, mit nping?

Manche OS's/Router erkennen, von einem Client initiierte und eingehende UDP-Verbindungen an den Clienten, nicht als RELATED (Antwort) an. Abhilfe schafft dann eine Freigabe im Router, für den udp-source-Port (-g) der von nping genutzt wird und das blocken von icmp-Antworten vom Client (nping) an den (UDP-)Server/IP-Adresse. Der Client will dem Server per ICMP mitteilen, dass der udp-source-Port nicht erreichbar ist ... und diese ICMP-Mitteilung seitens des Clienten ist nicht erforderlich (keine NEW-Verbindung) bzw. kann den Server irritieren (vor allem, wenn es ein DNS-Server ist).
 
  • UDP Packetloss 1-3% Beitrag #7
tq1199 schrieb:
T0XiiC schrieb:
Soll ich mir auch mal nping runterladen und schauen was ich für werte bekomme?

Edit: Bekomme es unter WIndows irgendwie nicht zum laufen :(
Zum Vergrößern anklicken....

Was funktioniert unter Windows nicht, mit nping?

Manche OS's/Router erkennen, von einem Client initiierte und eingehende UDP-Verbindungen an den Clienten, nicht als RELATED (Antwort) an. Abhilfe schafft dann eine Freigabe im Router, für den udp-source-Port (-g) der von nping genutzt wird und das blocken von icmp-Antworten vom Client (nping) an den (UDP-)Server/IP-Adresse. Der Client will dem Server per ICMP mitteilen, dass der udp-source-Port nicht erreichbar ist ... und diese ICMP-Mitteilung seitens des Clienten ist nicht erforderlich (keine NEW-Verbindung) bzw. kann den Server irritieren (vor allem, wenn es ein DNS-Server ist).
Zum Vergrößern anklicken....

Lässt sich nicht starten, oder muss ich dann alles so wie bei linux über die Konsole (also CMD) mit "nping XXXX (IP etc.)" machen?

Freigabe im Router wird nicht gehen, DSLITE + TC 7200 = beste was man bekommen kann :lovingeyes:
Ich bin schon seit Ende 2013 bei Unitymedia (bzw. damals halt KabelBW) habe das Problem aber erst seit ca. 2 Wochen ohne dass ich irgendetwas umgestellt habe.

Könnte vielleicht auch am TC7200 defekt sein? Denke eher nicht wenn Speed etc. normal ist aber man weiß ja nie.
 
  • UDP Packetloss 1-3% Beitrag #8
  • UDP Packetloss 1-3% Beitrag #9
tq1199 schrieb:
T0XiiC schrieb:
... über die Konsole (also CMD) mit "nping XXXX (IP etc.)" machen?
Zum Vergrößern anklicken....

Ja, versuch mal so, ... und wenn das auch nicht geht, dann versuch mal mit einer Linux-Live-CD/DVD.
Zum Vergrößern anklicken....
über nping in CMD gehts, was muss ich da jetzt einstellen um es zu testen :D ?

Edit:

Habe jetzt mal dein Pingtest (nping --udp --ttl 72 --data-length 60 -c 100 -g 56333 -p 53 82.212.62.62 ) übernommen und folgendes rausbekommen:

Max rtt: 69.000ms | Min rtt: 9.000ms | Avg rtt: 14.236ms
Raw packets sent: 100 (10.200KB) | Rcvd: 100 (4.600KB) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 99.13 seconds
 
  • UDP Packetloss 1-3% Beitrag #10
T0XiiC schrieb:
Habe jetzt mal dein Pingtest (
Code: 
<i>
</i>nping --udp --ttl 72 --data-length 60 -c 100 -g 56333 -p 53 82.212.62.62
) übernommen und folgendes rausbekommen:

Max rtt: 69.000ms | Min rtt: 9.000ms | Avg rtt: 14.236ms
Raw packets sent: 100 (10.200KB) | Rcvd: 100 (4.600KB) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 99.13 seconds
Zum Vergrößern anklicken....

Nicht schlecht ..., 100 udp-Pakete gesendet und kein packet loss.
 
  • UDP Packetloss 1-3% Beitrag #11
tq1199 schrieb:
T0XiiC schrieb:
Habe jetzt mal dein Pingtest (
Code: 
<i>
</i>nping --udp --ttl 72 --data-length 60 -c 100 -g 56333 -p 53 82.212.62.62
) übernommen und folgendes rausbekommen:

Max rtt: 69.000ms | Min rtt: 9.000ms | Avg rtt: 14.236ms
Raw packets sent: 100 (10.200KB) | Rcvd: 100 (4.600KB) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 99.13 seconds
Zum Vergrößern anklicken....

Nicht schlecht ..., 100 udp-Pakete gesendet und kein packet loss.
Zum Vergrößern anklicken....
Ich verstehe jetzt aber dann nicht warum ich im Teamspeak Packetloss habe. Teamspeak verwendet UDP.

Nochmal ein Test (gleiche IP aber mit 1000 Paketen)
Code: 
Max rtt: 3636.000ms | Min rtt: 7.000ms | Avg rtt: 18.706ms
Raw packets sent: 1000 (102.000KB) | Rcvd: 1000 (46.000KB) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1005.66 seconds
 
  • UDP Packetloss 1-3% Beitrag #12
T0XiiC schrieb:
Ich verstehe jetzt aber dann nicht warum ich im Teamspeak Packetloss habe. Teamspeak verwendet UDP.

Nochmal ein Test (gleiche IP aber mit 1000 Paketen)
Code: 
Max rtt: 3636.000ms | Min rtt: 7.000ms | Avg rtt: 18.706ms
Raw packets sent: 1000 (102.000KB) | Rcvd: 1000 (46.000KB) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1005.66 seconds
Zum Vergrößern anklicken....

Für die udp-Pakete zum UM-DNS-Server, sind von deinem UM-Anschluss, wahrscheinlich optimale bzw. beste Voraussetzungen vorhanden. Das wird für den Weg der udp-Pakete, zum bzw. vom TS-Server evtl. nicht der Fall sein.

Kannst Du evtl. auf dem TS-Server mit tcpdump (oder gleichwertig, z. B. wireshark) und dem entsprechenden Filter nach schauen, was an udp-Paketen am lauschenden udp-Port dort ankommt, wenn Du diesen Port mit nping (per udp) erreichen willst/kannst?
 
  • UDP Packetloss 1-3% Beitrag #13
Für die udp-Pakete zum UM-DNS-Server, sind von deinem UM-Anschluss, wahrscheinlich optimale bzw. beste Voraussetzungen vorhanden. Das wird für den Weg der udp-Pakete, zum bzw. vom TS-Server evtl. nicht der Fall sein.

Kannst Du evtl. auf dem TS-Server mit tcpdump (oder gleichwertig, z. B. wireshark) und dem entsprechenden Filter nach schauen, was an udp-Paketen am lauschenden udp-Port dort ankommt, wenn Du diesen Port mit nping (per udp) erreichen willst/kannst?
Zum Vergrößern anklicken....


Das Problem ist auf jedem Server, egal ob es mein Server ist oder von jemand anderem.
Jetzt zurzeit tritt es nur auf sobald ich auf mehreren TS gleichzeitig bin, also auf dem Hauptserver (Welcher laut Clientinfo ca. 6-10 Pakete pro Sekunde sendet) und dann noch gleichzeitig auf einem anderen. Der Paketverlust ist dann beim zweiten Server. Manchmal funktioniert es aber auch ohne irgend ein loss, das ist immer unterschiedlich.

Könnte es vielleicht sein dass der Router Teamspeak als einen UDP Flood?
 
Thema:

UDP Packetloss 1-3%

UDP Packetloss 1-3% - Ähnliche Themen

Routing probleme?seiten lassen sich nicht öffnen

Routing probleme?seiten lassen sich nicht öffnen: Guten morgen allerseits, seit 2 tagen kann ich bestimmte seiten booking . com z.b joyn .de nicht öffnen bei booking kommt cloudfare seite. bei...
Unitymedia

FB6591 Werte OK?

Unitymedia FB6591 Werte OK?: Hallo Zusammen, hab hier ständig Probs mit meinem Upload. Waren auch schon 5 Techniker da. Was sagt ihr zu den Werten? Es ist so schlimm das es...
Unitymedia

Neue Routingerscheinungen

Unitymedia Neue Routingerscheinungen: vorne weg, negativ ist mir das alles nicht aufgefallen. Aber scheinbar gabs wenige veränderungen beim routing zu google taucht ein mir bislang...
Unitymedia

Massiv unkorrigierbare Fehler auf einem Kanal?

Unitymedia Massiv unkorrigierbare Fehler auf einem Kanal?: Hallo Freunde. Ich habe nun seit ca. 2 Wochen mein Kabelinternet, jedoch fallen mir immer wieder unkorrigierbare Fehler ins Auge, und extreme...
Unitymedia

aorta.net

Unitymedia aorta.net: Hallo, wie andere Nutzer hier habe ich seit Tagen Probleme mit dem Internet. Webseite laden extrem lange oder garnicht, teilereise aber sofort...
Oben