Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Altes Betriebssystem und alter Browser haben mit Portweiterleitung oder Paketverlusten nichts zu tun? Ich weiß, dass das grafische Zeugs damit nicht funktioniert, egal, und was schade ist "System > Ereignisse" auch nicht.
Wohl allgemein bekannt und zu guter Letzt der Hinweis: In FritzOS-Labor 08.10-124223 der 4050 sind diese Menüpunkte derzeit (noch) unbenutzbar mit älterem Browser. Es erfolgt keine Anzeige, nur dauerhaft ein Rädchen:
System > Ereignisse
Internet > Online-Monitor > Online-Monitor
Weißt du worum es hier in diesem Forum geht? So viele Zahlen und Nummern im Haus oder im Labor? Wo bin ich? Hat das irgendwas zu bedeuten? Gibt es einen Zusammenhang? Reicht zum Verstehen NI oder braucht es AI? Dann bin ich raus. Du kannst perfekt shouten. SPO für alle oder doch SDP? Gibst du auch Antworten? Ich frage für einen Freund, weil ich noch nicht so lange hier bin und nicht weiß wer sich hier so alles verstecken mag.
Portfreigaben scheitern (noch) und erzeugen eine falsche Quittung: "Es ist ein Fehler aufgetreten. Fehlerbeschreibung: Die MAC-Adresse muss in der Form 00:11:22:33:44:55 oder 00-11-22-33-44-55 angegeben werden." Wer das braucht bekommt es hin.
Die gelben RJ45-Anschlüsse einer Fritzbox sind Hub-Anschlüsse (LAN-Ports).
Paketverluste auf dem FritzBox-HUB (Lan1-Lan3) zeigen sich mit allen bekannten multiping-Tools (PingInfoView, pingplotter, vmPing, fping) mit ähnlichen Prozentzahlen dauerhaft im Monitoring. Kommen die Pakete über WAN/VPN auf die Bridge, geht nichts verloren.
(von 0xr2)$ fping -D -l -s -p30000 -r5 -f fping.txt ### aus dem LAN in die Bridge
[1761567969.92764] 10.42.0.1 : [364], 64 bytes, 1.12 ms (1.04 avg, 0% loss)
[1761567969.93737] 10.42.0.9 : [364], 64 bytes, 0.674 ms (0.644 avg, 0% loss)
[1761567969.94784] 10.42.0.238 : [364], 64 bytes, 0.806 ms (0.920 avg, 0% loss)
[1761567969.95840] 10.42.0.2 Aruba1930_2_BRIDGE: [364], 64 bytes, 1.22 ms (2.87 avg, 22% loss)
[1761567969.96832] 10.42.0.51 ap7490____3_BRIDGE: [364], 64 bytes, 0.650 ms (0.942 avg, 30% loss)
[1761567969.99631] 8.8.8.8 : [364], 64 bytes, 8.13 ms (8.25 avg, 0% loss)
[1761567970.00082] 1.1.1.1 : [364], 64 bytes, 23.0 ms (23.0 avg, 0% loss)
[1761567969.99917] s------.selfhost.eu : [364], 64 bytes, 0.857 ms (1.00 avg, 0% loss)
[1761567970.00953] 0xr2------------.myfritz.net : [364], 64 bytes, 1.03 ms (1.08 avg, 0% loss)
[1761567970.04577] bgca------------.myfritz.net : [364], 64 bytes, 16.7 ms (16.9 avg, 2% loss)
[1761567970.02509] o8g7------------.myfritz.net : [364], 64 bytes, 6.19 ms (6.20 avg, 2% loss)
[1761567970.05225] z--------.selfhost.co : [364], 64 bytes, 12.8 ms (14.3 avg, 7% loss)
[1761567970.06261] r----.dynv6.net : [364], 64 bytes, 13.0 ms (12.9 avg, 7% loss)
[1761567970.07313] e----.dynv6.net : [364], 64 bytes, 13.4 ms (13.0 avg, 37% loss)
[1761567970.09542] n------.dynv6.net : [364], 64 bytes, 25.5 ms (25.7 avg, 0% loss)
Sieht für mich nach einem alten (bisher unerkannten) Problem aus. Jahrzehnte alte Überlieferungen (sind die mündliche Weitergabe von Wissen und Geschichten) lassen mich das vermuten, z.B. 2016 Netzwerkpraxis: Zu viele Switches verderben den Brei. 2023 und heute noch gilt, salopp gesagt: "An der Fritte sollte man nie Geräte direkt stecken, sondern immer nur ein Switch, der dann auf alles andere verteilt."administrator.de Höchstseltsam, dass sich bisher nicht ein Experte gefragt hat, wie diese (eigentlich unsinnige) Erfahrungsregel entstanden ist. Entstanden zu einer Zeit als 10/100 Mbit/s am Switch Standard waren, aber am WAN gerade DSL 768 kbit/s aufgekommen ist und Rechenleistung immer knapp war. Gut, es könnte am Aruba1930-Switch liegen, z.B. an so modernem Zeugs wie EEE. Deshalb hängt und läuft er nun hinter Lan1 - übrigens völlig problemlos!
23% Paketverlust auf Lan2 mit 7490_07.60 IP-Client
[UpDATE 27.] An der 4050-BRIDGE / Lan2 / Lan3 hängen nun zwei 7490_07.60 als WiFi-Accessspoint. Die FritzBox7490 an Lan3 bleibt zur Komplexitätsverringerung ausgeschaltet.
Im reinen AVM-Universum das gleiche Ergebnis
- heftiger PL zw. LAN1-LAN2-LAN3.
Habe ich womöglich eine FritzBox-4050 mit Hardwaredefekt erwischt? Oder liegt es daran, dass kein AVM-MESH erzeugt wird? Das zentrale Management erfolgt durch die eigene Organisation, auch wenn es @Gordon bei Min.13:00 mit einer FritzBox7490 automagisch ginge.
FRITZ!Box Support:
Testweise ausgeschaltet, nach jedem Update prüfen.
Stellt sich gerne zurück, z.B. nach (stromlos)Reset.
Der Unterschied zw. WiFi-Repeater und WiFi-Accesspoint wird mit AVM-Marketingbegriffen nicht klarer. Ein FRITZ!Repeater mit LAN-Kabel verbunden (_#83_automagisch oder _002_manuell_) ist ein WiFi-Accesspoint. Im AVM-Mesh-Neusprech heißt das "LAN-Brücke". "Eine AVM LAN-Brücke verbindet einen FRITZ!Repeater per LAN-Kabel direkt mit dem Router (z. B. einer FRITZ!Box)."
Paketverluste im WAN der Telekom zwischen Kundenanschlüssen (*.myfritz.net u.a. dynDNS) zeigen sich besonders hübsch mit pingplotter.com (zumindest in der 14 Tage Testphase, danach nur mit 2 hosts). Mit PingInfoView lassen sich zwei Dinge eindrucksvoll zeigen. In einem VPN over Telekom tritt kein packet loss zwischen Kundenanschlüssen auf, dafür ist dann Rechenpower erforderlich, was zu geringeren Geschwindigkeitsgrenzen führt, zumindest hier https://www.ip-phone-forum.de/threads/7490-vpn-auf-20-mbit-sec-limitiert.271140/#post-2611624 auf ca. 10 Mbit/s. Gelegentlich scheitert ein ping-ICMP bereits an der dynDNS-Auflösung.
Paketverluste im WAN der Telekom zwischen Kundenanschlüssen *)
PL auch auf der Bridge
*) off topic: Trotz Störungsticket bleibt der PL im besten Netz der Telekom beharrlich zwischen, über dynDNS verbundenen, Kundenanschlüssen bestehen. [UpDATE 29.] Der Netzbetreiber arbeitet offensichtlich am Theme, langsam wird die PL-rate geringer. Die letzten 12h zw. <3 % und <15 %. [/UpDATE] Mit einer Überprovisionierung der verkauften Datenraten wird das technische Problem kaufmännisch entkräftet. Ticket erledigt, passt doch alles.
Entweder passt es im Telekomnetz technisch nicht oder es ist kaufmännische Strategie der Telekom ggü. Verbrauchern. Netzpolitik bzw. Netzneutralität, bekannt beim Peering? Wäre dann was für die BNetzA. Die TKMV (wird von der BNetzA überwacht), gilt für die Netzbetreiber, spricht von max. 150ms Latenz. Wie hoch ist die Latenz eines verlorenen Pakets, das niemals ankommen wird? Nur die angeforderte Kopie kann ankommen. Bei der Verbaucherzentrale geht es nur um die Raten im Dn/Upload, bisher nicht um die Latenz.
Schau' mir mal alternative ISP für den Zugang zum TK/IT-Netz an. Eine Wechselwirkung mit dem Thema PL auf der Bridge schließe ich eigentlich aus, denn zu den Großen im Internet (die vermeintlich für Peering bezahlen) gibt es 0,0% PL.
Beiden technischen Paketverlusten ist gemeinsam: Kommen die Pakete über WAN mit VPN auf die LAN-Bridge, geht nichts verloren.
Gehen die Pakete über VPN durchs WAN zum dynDNS-Partner geht nichts verloren.
Hängt PL im Telekomnetz doch mit Paketverlusten auf der Bridge zusammen?
[UpDATE 28.] Die webGUI der 7490 an Lan2 ist nur über extern/VPN erreichbar, von Lan1 aus geht es nicht.
Monitoring sucht Mitmacher, sowohl im LAN auf der Bridge der FritzBox als auch im WAN mit dynDNS zu Kundenanschlüssen im besten Netz der Telekom. Kann jemand diese Beobachtungen / Fragen / Probleme bestätigen?
