Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[why_]

Sobald bei mir ein TC4400 mit OpenWRT/LEDE wieder läuft werde ich mal einen Feature Request einreichen (für AFTR Auflösung via DHCP)

Die Performance wird wohl wichtiger sein als das es automatisch geht. Bei der-tim gehen scheinbar auch nur 34 MBit/s durch den Tunnel, ich schaffe nicht mehr als 25 MBit/s durchsatz wenn der DS-Lite Tunnel via OpenWRT/Linux terminiert wird. MichaelBre hat leider noch nicht nachgereicht ob eine Fritzbox hinterm Modem mehr schaft.

 

[Andreas1969]

Woran kann man erkennen wieviele DS/US Kanäle wirklich geschaltet sind?

Kannst Du doch im Modem nachschauen :winken:
Das Modem synct mit allen verfügbaren Kanälen, die das CMTS hergibt (bis zu 32) :smile:

 

[Mr.Goodcat]

Woran kann man erkennen wieviele DS/US Kanäle wirklich geschaltet sind?

Kannst Du doch im Modem nachschauen :winken:
Das Modem synct mit allen verfügbaren Kanälen, die das CMTS hergibt (bis zu 32) :smile:

Genau das dachte ich auch, nur dann ergeben Einträge in der Tabelle wie dieser "22/5 von 34/10" keinen Sinn für mich.

 

[Andreas1969]

Genau das dachte ich auch, nur dann ergeben Einträge in der Tabelle wie dieser "22/5 von 34/10" keinen Sinn für mich.

Da ha'ste Recht.

 

[Andreas1969]

Bei der-tim gehen scheinbar auch nur 34 MBit/s durch den Tunnel, ich schaffe nicht mehr als 25 MBit/s durchsatz wenn der DS-Lite Tunnel via OpenWRT/Linux terminiert wird.

Sieht mir fast so aus, als wenn der MTU Wert für den Tunnel falsch ist. Das würde es erklären :nein:

 

[Samsungstory]

Die 34/10 sind ja nur das Maximum was das Modem kann. Kann man theoretisch auch weglassen. :winken:

 

[why_]

Bei der-tim gehen scheinbar auch nur 34 MBit/s durch den Tunnel, ich schaffe nicht mehr als 25 MBit/s durchsatz wenn der DS-Lite Tunnel via OpenWRT/Linux terminiert wird.

Sieht mir fast so aus, als wenn der MTU Wert für den Tunnel falsch ist. Das würde es erklären :nein:

Ich habe versucht das ganze per

ip route add 37.58.58.0/24 dev tun0 advmss 1412

zu umgehen. Leider bleibt der Speed gleich schlecht. Test Ziel war http://37.58.58.140/speedtest/10000mb.bin

root@debian:~# wget -4 -O /dev/null http://37.58.58.140/speedtest/100mb.bin
--2018-04-01 12:59:13-- http://37.58.58.140/speedtest/100mb.bin
Verbindungsaufbau zu 37.58.58.140:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 100000000 (95M) [application/octet-stream]
Wird in »»/dev/null«« gespeichert.
/dev/null 100%[=================================================>] 95,37M 1,64MB/s in 58s
2018-04-01 13:00:11 (1,63 MB/s) - »»/dev/null«« gespeichert [100000000/100000000]

Per Fritzbox DS-Lite Tunnel liefert das ziel 450 mbit/s.

 

[Mr.Goodcat]

Die 34/10 sind ja nur das Maximum was das Modem kann. Kann man theoretisch auch weglassen. :winken:

Danke für die Auflösung! :smile:

 

[Andreas1969]

Ich habe versucht das ganze per
CODE: ALLES AUSWÄHLEN
ip route add 37.58.58.0/24 dev tun0 advmss 1412
zu umgehen.

Das wird so nicht funktionieren.
Die Tunnel MTU muss auf 1460 stehen.
Der Tunnel liefert Brutto max. 1460 Bytes unfragmentiert
(1500-40) Bytes. :winken:

 

[MichaelBre]

Die 34/10 sind ja nur das Maximum was das Modem kann. Kann man theoretisch auch weglassen. :winken:

Danke für die Auflösung! :smile:

Man kann es auch in die Überschrift der Spalte packen.

 

[why_]

Das wird so nicht funktionieren.
Die Tunnel MTU muss auf 1460 stehen.
Der Tunnel liefert Brutto max. 1460 Bytes unfragmentiert
(1500-40) Bytes. :winken:

Die WAN MTU per IPv6 ist 1452 -40 (Ipv6) =1412.

 

[Andreas1969]

Die WAN MTU per IPv6 ist 1452 -40 (Ipv6) =1412.

Das ist falsch.
WAN MTU auf 1500
Tunnel MTU auf 1460

Dann sollte es tun.

 

[JPDribbler]

laut openwrt Doku steht es auf 1280 im Standard https://wiki.openwrt.org/doc/uci/network

Siehe Protocol "dslite" (Dual-Stack Lite)

Solte also vermutlich auf folgendes gesetzt werden (siehe Wert von Andreas):

<i>
</i>config 'interface' 'DSLITE INTERFACE' option 'mtu' '1460'

die mtu oben ist nicht für wan, sondern für den dslite tunnel

 

[why_]

Die WAN MTU per IPv6 ist 1452 -40 (Ipv6) =1412.

Das ist falsch.
WAN MTU auf 1500
Tunnel MTU auf 1460

Dann sollte es tun.

Zumindest meine Fritzbox macht keine 1500 auf der WAN Schnittstelle per IPv6, im LAN sind die kein Problem.
Zwischen 1000-1500 nichts liefert schnelleren Speed. Lediglich der Tunnel funktioniert wenn die Tunnel MTU zu hoch ist nicht mehr (was bei 1452 erreicht ist).

 

[Andreas1969]

Zumindest meine Fritzbox macht keine 1500 auf der WAN Schnittstelle

Meine macht das aber, zwar per IPV4, aber das sollte bei IPV6 nicht anders sein.

 

[why_]

Zumindest meine Fritzbox macht keine 1500 auf der WAN Schnittstelle

Meine macht das aber, zwar per IPV4, aber das sollte bei IPV6 nicht anders sein.

Das Ding ist nunmal Zugenagelt und Zaubern kann ich nicht.

13:38:11.270117 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 1, length 1240
13:38:12.271523 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 2, length 1240
13:38:13.272800 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 3, length 1240
13:38:18.674874 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 1, length 1241
13:38:19.676176 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 2, length 1241
13:38:20.677664 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 3, length 1241
13:38:21.679410 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 4, length 1241
13:38:26.927627 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (0|1448) ICMP6, echo request, seq 1, length 1448
13:38:26.927697 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (1448|60)
13:38:27.929354 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (0|1448) ICMP6, echo request, seq 2, length 1448
13:38:27.929460 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (1448|60)
13:38:28.931496 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (0|1448) ICMP6, echo request, seq 3, length 1448
13:38:28.931622 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (1448|60)
13:38:38.607311 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 1, length 1456
13:38:39.609535 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 2, length 1456
13:38:40.610891 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 3, length 1456
13:38:41.612803 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 4, length 1456
13:38:46.818065 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 1, length 1457
13:38:47.820008 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 2, length 1457
13:38:48.822271 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 3, length 1457
13:38:55.307672 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (0|1448) ICMP6, echo request, seq 1, length 1448
13:38:55.307710 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (1448|13)
13:38:56.309691 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (0|1448) ICMP6, echo request, seq 2, length 1448
13:38:56.309783 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: frag (1448|13)
13:39:00.627451 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 1, length 1460
13:39:01.628988 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 2, length 1460
13:39:02.630255 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 3, length 1460
13:39:03.631752 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 4, length 1460
13:39:04.633245 IP6 2a02:8070:xxxx:xxxx:xxxx:xxxx:xxxx > 2a00:c98:2030:a034::21: ICMP6, echo request, seq 5, length 1460

 

[why_]

Quark. Ethernet 1500 - IPv6 1460 - IPIP6 Tunnel Header 1452. Tunnel MTU ist dann effektiv 1452 und - 20 Byte IPv4 Header ergibt im Tunnel können Daten mit einer MTU von 1432 Transportiert werden.
Die Erkenntnis ändert aber auch nichts daran das die Daten nur durchtröpfeln obwohl die MTU voll ausgeschöpft wird. Das Krankt irgendwo anders.

 

[pokemon20021]

Ich habe versucht das ganze per

ip route add 37.58.58.0/24 dev tun0 advmss 1412

zu umgehen. Leider bleibt der Speed gleich schlecht. Test Ziel war http://37.58.58.140/speedtest/10000mb.bin

root@debian:~# wget -4 -O /dev/null http://37.58.58.140/speedtest/100mb.bin
--2018-04-01 12:59:13-- http://37.58.58.140/speedtest/100mb.bin
Verbindungsaufbau zu 37.58.58.140:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 100000000 (95M) [application/octet-stream]
Wird in »»/dev/null«« gespeichert.
/dev/null 100%[=================================================>] 95,37M 1,64MB/s in 58s
2018-04-01 13:00:11 (1,63 MB/s) - »»/dev/null«« gespeichert [100000000/100000000]

Per Fritzbox DS-Lite Tunnel liefert das ziel 450 mbit/s.

Bei Speedmessung mittels wget-download hat eigentlich der Sende-MSS-Wert (Zwangssetzen mittels "advmss 1412") keinen wesentlichen Einfluß auf die Messung, dieser Wert hat eigentlich Einfluß auf Upload Upload.

was sagt denn der "ifconfig" output bzgl. MTU bei debian-Rechner ?

 

[why_]

was sagt denn der "ifconfig" output bzgl. MTU bei debian-Rechner ?

tun0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1452

 

[MichaelBre]

Danke für den MTU test, leider bringt der speedtest bei wieistmeineip nichts, da die per ipv6 testen.
Der Speedtest hier http://ipv6-test.com/speedtest/ schlüsselt den Speed per Protokol auf, könntest du da bitte noch kurz testen?
Danke

Frankreich:

Niederlande:

IPv6-Test:

 

[rv112]

Bei dem Speedtest komme ich bei IPv4 kaum über 100 MBit/s hinaus und das mit nativem IPv4. Von daher eher nicht zu gebrauchen.

 

[why_]

Gut dann muss nur noch raus gefunden werden woran der IPIP6 Tunnel unter Linux/Openwrt krankt, die Fritzboxen können es ja auch hinterm Modem.

 

[rv112]

Was ist denn das Problem? Bei mir läuft IPv6 sauber mit pfSense was ja auch auf FreeBSD basiert.

(Mehr als 50 MBit/s kommen hier leider nicht via LTE rein)

 

[why_]

Was ist denn das Problem? Bei mir läuft IPv6 sauber mit pfSense was ja auch auf FreeBSD basiert.

Das via IPv4 nur 20-30 MBit/s durchkommen wenn das via DS-Lite unter Linux realisiert wird.

 

[rv112]

Oh achso, hm das kann ich wohl nicht gegentesten.