- Offizieller Beitrag
Ich würde es mit iPerf3 versuchen. iPerf(2) will wohl noch manuell auf IPv6 gestellt werden (Option -V auf Server und Client).
Ich würde es mit iPerf3 versuchen. iPerf(2) will wohl noch manuell auf IPv6 gestellt werden (Option -V auf Server und Client).
Das funktioniert. Mit jperf habe ich es dann auch hinbekommen und es liefert vergleichbare Ergebnisse. Mit IPv6 steht wohl nur die halbe Bandbreite zur Verfügung. Mehr wäre natürlich schöner, aber da mein Anschluss "nur" für 300 MBit/s konfiguriert ist, ist das hoffentlich keine Einschränkung. D.h., wenn die Daten mit Unterbrechnungen und immer 1 GBit/s übertragen werden, dann würde es auch jetzt schon bremsen. Das müsste sich mit einem iperf-Server im Internet testen lassen.
Während des iperf3-Tests steigt die Anzeige der Leistungsaufnahme des Routers von begrüßenswerten 2,4 auf 2,9 W (WLAN ist ausgeschaltet). Der ONT von Nokia ist mit 4,5 W wesentlich gefräßiger.
~ $ iperf3 -c fd01::3 -V
iperf 3.0.11
Linux TestPC 4.15.0-72-generic #81~16.04.1-Ubuntu SMP Tue Nov 26 16:34:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Time: Sat, 14 Dec 2019 15:31:17 GMT
Connecting to host fd01::3, port 5201
Cookie: TestPC.1576337477.894633.7d9f88cb38f
TCP MSS: 1428 (default)
[ 4] local fd02::2 port 44030 connected to fd01::3 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 56.4 MBytes 473 Mbits/sec 0 2.70 MBytes
[ 4] 1.00-2.00 sec 55.0 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 2.00-3.00 sec 55.0 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 3.00-4.00 sec 55.0 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 4.00-5.00 sec 54.9 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 5.00-6.00 sec 54.9 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 6.00-7.00 sec 54.9 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 7.00-8.00 sec 54.9 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 8.00-9.00 sec 55.0 MBytes 461 Mbits/sec 0 3.05 MBytes
[ 4] 9.00-10.00 sec 55.0 MBytes 461 Mbits/sec 0 3.05 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 551 MBytes 462 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 550 MBytes 461 Mbits/sec receiver
CPU Utilization: local/sender 5.1% (0.3%u/4.8%s), remote/receiver 25.4% (1.4%u/24.0%s)
iperf Done.
Alles anzeigen
~ $ iperf3 -s -V
iperf 3.0.11
Linux TestPC 4.15.0-72-generic #81~16.04.1-Ubuntu SMP Tue Nov 26 16:34:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Sat, 14 Dec 2019 15:31:17 GMT
Accepted connection from fd02::2, port 44028
Cookie: TestPC.1576337477.894633.7d9f88cb38f
TCP MSS: 1428 (default)
[ 5] local fd01::3 port 5201 connected to fd02::2 port 44030
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 53.0 MBytes 444 Mbits/sec
[ 5] 1.00-2.00 sec 55.0 MBytes 461 Mbits/sec
[ 5] 2.00-3.00 sec 54.7 MBytes 459 Mbits/sec
[ 5] 3.00-4.00 sec 55.3 MBytes 464 Mbits/sec
[ 5] 4.00-5.00 sec 54.2 MBytes 454 Mbits/sec
[ 5] 5.00-6.00 sec 55.1 MBytes 462 Mbits/sec
[ 5] 6.00-7.00 sec 55.0 MBytes 461 Mbits/sec
[ 5] 7.00-8.00 sec 54.7 MBytes 459 Mbits/sec
[ 5] 8.00-9.00 sec 55.2 MBytes 463 Mbits/sec
[ 5] 9.00-10.00 sec 54.8 MBytes 460 Mbits/sec
[ 5] 10.00-10.06 sec 2.98 MBytes 443 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.06 sec 551 MBytes 460 Mbits/sec 0 sender
[ 5] 0.00-10.06 sec 550 MBytes 459 Mbits/sec receiver
CPU Utilization: local/receiver 25.4% (1.4%u/24.0%s), remote/sender 5.1% (0.3%u/4.8%s)
iperf 3.0.11
Linux TestPC 4.15.0-72-generic #81~16.04.1-Ubuntu SMP Tue Nov 26 16:34:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated
Alles anzeigen
Gibt es noch etwas Anderes zu testen? Ansonsten würde ich den Router umkonfigurieren und an den Glasfaseranschluss anschließen.
BTW: Von der WAN-Seite aus kann ich nicht auf das Webinterface des Router zugreifen, zumindest nicht einfach über die IP-Adresse. Ich hoffe, dass das auch nicht mit irgendwelchen Tricks geht.
Vielen Dank für die Tests. Dieses Ergebnis habe ich dann doch erwartet. Für meinen Anschluss wäre der also nichts...
Diese Durchläufe testen übrigens die Uploadrichtung. Für die umkehrte Richtung wäre noch ein -R anzuhängen. Das sollte aber keinen großen Unterschied machen.
Du könntest noch die Firewall testen, indem du den Server auf der LAN-Seite und den Client auf der WAN-Seite startest. Das sollte nicht funktionieren, bis du den LAN-seitigen Server in der Firewall des Routers freischaltest. Würde ich für den ruhigen Schlaf prüfen, wenn das mein Router zum Internet hin wäre.
Die andere Richtung ist ja schnell getestet iperf3 -R liefert hier 630 MBit/s, also deutlich mehr als die 450 MBit/s in Senderichtung. Die Netzwerkchronik im Taskmanager von Mint Cinnamon bestätigt den Unterschied.
Wenn ich den iperf3-Server auf der LAN-Seite laufen lasse, kann ich diesen von der WAN-Seite aus mit IPv4 nicht erreichen, aber mit IPv6 geht es mit 630 MBit/s. Kann das an den verwendeten IP-Adressen liegen, bzw. genauer daran, dass auf der WAN-Seite die Adresse mit "fd" anfängt, was vielleicht nur für lokale Adressen verwendet werden soll?
Schau mal in der Anleitung nach, ob man die Firewall evtl. erst einschalten muss. Welche Adressen auf der WAN-Seite verwendet werden, darf die Firewall nicht beeinflussen. Die Seite hast du ja im Normalfall nicht unter deiner Kontrolle. Typische SPI-Firewalls haben eine Regel, die Pakete vom WAN-Interface nur reinlässt, wenn sie zu einer bestehenden Verbindung gehören. Dafür braucht man keine Adressen zu testen.
Ich habe den Router noch mal auf die Werkseinstellung zurückgesetzt, um sicher zu sein, dass ich keinen Murks eingegeben habe, aber nachdem ich die statischen Adressen eingetragen habe, konnte ich wieder von WAN auf LAN zugreifen.
In der Anleitung steht auf Seite 252:
Your device has built in advanced Security features that protect
your network by blocking unwanted traffic from the Internet.
Eine Möglichkeit das Verhalten der Firewall grundsätzlich zu ändern, finde ich nicht. Die IPv4-Adressen werden auch so geblocked, wie man es von einem Router gewohnt ist, sodass es merkwürdig wäre, wenn man das auf IPv6-Seite erst aktivieren müsste.
Die mögliche IP- und Port-Filterung unterscheidet nicht nach eingehend und ausgehend. Ich könnte dort also keine Filterregel definieren, die nur eine Richtung blockt.
Die installierte Firmware ist die aktuellste.
Im Moment sieht das für mich nach einem fehlerhaften Verhalten aus, was nicht so schön ist.
Das Handbuch ist ziemlich abenteuerlich. Lang, ausführlich, aber mit reichlich Fehlern. Auf der Seite 237 über "Port Filtering" stehen so bedenkliche Sätze wie "Enable/Disable the WAN packet filter. Default setting is Disable." und "Enter the port range to be filtered for both Outbound and Inbound packet". Es hat den Anschein, dass die Firewallfunktionen alle symmetrisch sind, also unabhängig von der Richtung WAN2LAN und LAN2WAN gleich sperren. So kann man natürlich nichts wirklich ausfiltern, weil man sonst vom Client auch keine Verbindungen aufbauen kann. Mit IPv4 scheitern die Verbindungen wahrscheinlich nur an NAT, was kein vollständiger Schutz ist.
Level1 hat eine Support-Email-Adresse ins Handbuch geschrieben. Vielleicht können die erklären, wie man den Router sicher konfiguriert.
Level1 hat eine Support-Email-Adresse ins Handbuch geschrieben. Vielleicht können die erklären, wie man den Router sicher konfiguriert.
Dort werde ich nachfragen, denn ich sehe sonst keine Möglichkeit, das Gerät sinnvoll als Internetrouter zu verwenden. Ansonsten wäre das Ding nur noch als Accesspoint im LAN brauchbar.
Ich werde berichten.